Software Engineer Interview Experience Decoding Encoded Strings

Got asked this question for an interview: ``` """ Given an encoded string, return its decoded string. The encoding rule is: k[encodedstring], where the encodedstring inside the square brackets is bein

Got asked this question for an interview: """ Given an encoded string, return its decoded string. The encoding rule is: k[encodedstring], where the encodedstring inside the square brackets is being repeated exactly k times. Note that k is guaranteed to be a positive integer. ex: Example 1: Input: s = "3[a]2[bc]" Output: "aaabcbc" Example 2: Input: s = "3[a2[c]]" Output: "accaccacc" Example 3: Input: s = "2[abc]3[cd]ef" Output: "abcabccdcdcdef" """ Since I was used to standard OOP/OOD for my interviews, got a bit caught off guard that this problem seemed like a leetcode problem. So I ended up needing to ask clarifying questions about the requirements and reason from first principles ## What I did * Clarify if the encoded string to decode will be a valid input? Luckily we don't need to handle that * Pick a test case that is small but generalizable. Some good examples already provided * Walk through how I would do the task as a human. Certain patterns emerged which led to a recursive approach ## Implementation * I was able to get some of the boilerplate interfaces scoped * Carefully went through edge cases as I was scanning the string to build the decoding * Had the most trouble with how to persist the state of the decoded string when doing the recursive part and combining with the current stack's output * Minor but subtle bug took time for me to reason about ## What was the outcome * I was just in the nick of time able to get a working implementation that passes the provided test cases * Interviewer needed to provide some hints in terms of debugging the recursion implementation. We ran through the debugging like a pair programming exercise * Recruiter followed up and said that I passed. Interviewer really liked how I "systematically thought through the edge cases in my implementation" Key takeaway is that it's not over until it's over. You might think you "bombed the interview", but maybe you actually passed. Little things like being systematic on your edge case walkthrough, asking clarifying questions, good interface design do shift the outcome despite not 100% solving all the parts in the allotted time