3 ms·

Matching parenthesis is a puzzle question. Either the candidate knows to use a stack, or he's gonna spend one hour to figure it out.

deathanatos 8y ago
I disagree that it's a puzzle. A reasonable person could look at it, and go, okay, so a parenthesized string is made up of some sequence of ( <more balanced parens> ) possibly repeated, to get things like "()()()". i.e., do that check in a loop. That is, for whatever position you're at, check that the first character is "(". Check that at position+1 there is a balanced parentheses string. Check that at position+1+len(the balanced paren string) there is a ")". Consume as many of those as you can in your loop; return the consumed data as the "balanced string". Now, this function has to return the string (since our use of it above needs the length to know where the inner string ends). It stops after it can't consume anything further. The whole string is balanced if we consumed everything. That's it. The stack is implicit here. Yeah, you have to know recursion, but that's the thing about interview questions: at some point you have to know something. I asked elsewhere, and it hasn't been answered in this thread: if this is a bad question, what would make it a good one? I would love to see what the author's idea of a good question is. For the real-world applicability of this: I deal primarily w/ HTTP APIs. Sometimes, that requires me to make use of certain HTTP headers, and a great deal of web "frameworks" out there do not parse HTTP headers; they just give you back the raw key-value map as strings or somesuch. Several of HTTP's headers are context-free. (They require at least a stack to parse.)
- user5994461 8y ago
  It's a bad interview question IMO because it's a puzzle question. Either you know the magic trick to use a stack and you'll be done in a few minutes, or you could spend an hour to come up with a solution struggling to cover the basic edge cases. As the interviewer, all you can do is watch the developer suffers for a while, without being able to give help or shift to a different problem. That doesn't give you any indication of the ability to code or solve problems.
  - deathanatos 8y ago
    > It's a bad interview question IMO because it's a puzzle question. You asserted this in your first message. The point of my reply is to show that it's not a "puzzle", and that a reasonable line of thinking and reasoning can guide you through the problem to an answer. The naïve answer one might get here is fairly "undisciplined", in that there's no rigor in language theory, no deep discussion, but the question is still answerable. > the magic trick to use a stack My suggested line of reasoning does not use a stack, beyond function calling. If using the actual stack is a "magic trick", again, I think we have removed so much material from consideration as to not be able to ask anything of use. Again, if we simply dismiss any line of reasoning that a candidate might not see as a "puzzle", then every question is a puzzle, and nothing can be asked in an interview. Simply repeating your thesis that it's a puzzle does not advance this discussion: do you not think the line of reasoning I laid out is reasonably obtainable in an interview? And if not (since I think it's a fairly minimal one), then what types/sorts of questions should an interview ask, since it would seem like I'm left with only things that are dead obvious (b/c if it wasn't, it's now a magic trick puzzle), and that leaves me with nothing to screen candidates with. As an interviewer, I want to see you struggle with something you might not fully understand, and I want to know your reasoning and thinking as you go along with it. The real job is not going to come with a manual, after all.
    - deleted 8y ago
      [deleted]
    - user5994461 8y ago
      Incrementing on parenthesis and decrementing on closing parenthesis is trivial. You can surely agree that it's more of an ahah moment to get there, than a long reasoning that may or may not have lead to it. What do you do if the candidate cannot come up with the solution in 10 minutes? I've been there and find it embarrassing. It doesn't indicate aptitude or lack of aptitude. I find that system design, performance optimization or sometimes code review have the great advantage of being progressive. The candidate can go in multiple directions. The interviewer has the opportunity to lead to find strengths and match with experiences on the resume, while it's also possible to assist or to pull away from any particular aspect. For coding questions, either stay on simple problems with straightforward solutions, could be as stupid as printing numbers from one to ten, to test the ability to actually write code. Or a progressive exercise that must have both trivial solutions and optimized solutions and then can be integrated into a bigger function.
kerkeslager 8y ago
The solution I posted doesn't use a stack, or any other data structures for that matter.
- user5994461 8y ago
  It's easier with a stack and it avoids common mistakes from other algorithms. Also easier to generalize to follow up problems like multiple characters. Push on opening parenthesis. Pop on closing parenthesis. Trivial.

deathanatos 8y ago

I disagree that it's a puzzle. A reasonable person could look at it, and go, okay, so a parenthesized string is made up of some sequence of ( <more balanced parens> ) possibly repeated, to get things like "()()()". i.e., do that check in a loop. That is, for whatever position you're at, check that the first character is "(". Check that at position+1 there is a balanced parentheses string. Check that at position+1+len(the balanced paren string) there is a ")". Consume as many of those as you can in your loop; return the consumed data as the "balanced string". Now, this function has to return the string (since our use of it above needs the length to know where the inner string ends). It stops after it can't consume anything further. The whole string is balanced if we consumed everything. That's it. The stack is implicit here. Yeah, you have to know recursion, but that's the thing about interview questions: at some point you have to know something. I asked elsewhere, and it hasn't been answered in this thread: if this is a bad question, what would make it a good one? I would love to see what the author's idea of a good question is. For the real-world applicability of this: I deal primarily w/ HTTP APIs. Sometimes, that requires me to make use of certain HTTP headers, and a great deal of web "frameworks" out there do not parse HTTP headers; they just give you back the raw key-value map as strings or somesuch. Several of HTTP's headers are context-free. (They require at least a stack to parse.)

user5994461 8y ago
It's a bad interview question IMO because it's a puzzle question. Either you know the magic trick to use a stack and you'll be done in a few minutes, or you could spend an hour to come up with a solution struggling to cover the basic edge cases. As the interviewer, all you can do is watch the developer suffers for a while, without being able to give help or shift to a different problem. That doesn't give you any indication of the ability to code or solve problems.
- deathanatos 8y ago
  > It's a bad interview question IMO because it's a puzzle question. You asserted this in your first message. The point of my reply is to show that it's not a "puzzle", and that a reasonable line of thinking and reasoning can guide you through the problem to an answer. The naïve answer one might get here is fairly "undisciplined", in that there's no rigor in language theory, no deep discussion, but the question is still answerable. > the magic trick to use a stack My suggested line of reasoning does not use a stack, beyond function calling. If using the actual stack is a "magic trick", again, I think we have removed so much material from consideration as to not be able to ask anything of use. Again, if we simply dismiss any line of reasoning that a candidate might not see as a "puzzle", then every question is a puzzle, and nothing can be asked in an interview. Simply repeating your thesis that it's a puzzle does not advance this discussion: do you not think the line of reasoning I laid out is reasonably obtainable in an interview? And if not (since I think it's a fairly minimal one), then what types/sorts of questions should an interview ask, since it would seem like I'm left with only things that are dead obvious (b/c if it wasn't, it's now a magic trick puzzle), and that leaves me with nothing to screen candidates with. As an interviewer, I want to see you struggle with something you might not fully understand, and I want to know your reasoning and thinking as you go along with it. The real job is not going to come with a manual, after all.
  - deleted 8y ago
    [deleted]
  - user5994461 8y ago
    Incrementing on parenthesis and decrementing on closing parenthesis is trivial. You can surely agree that it's more of an ahah moment to get there, than a long reasoning that may or may not have lead to it. What do you do if the candidate cannot come up with the solution in 10 minutes? I've been there and find it embarrassing. It doesn't indicate aptitude or lack of aptitude. I find that system design, performance optimization or sometimes code review have the great advantage of being progressive. The candidate can go in multiple directions. The interviewer has the opportunity to lead to find strengths and match with experiences on the resume, while it's also possible to assist or to pull away from any particular aspect. For coding questions, either stay on simple problems with straightforward solutions, could be as stupid as printing numbers from one to ten, to test the ability to actually write code. Or a progressive exercise that must have both trivial solutions and optimized solutions and then can be integrated into a bigger function.

kerkeslager 8y ago

The solution I posted doesn't use a stack, or any other data structures for that matter.

user5994461 8y ago
It's easier with a stack and it avoids common mistakes from other algorithms. Also easier to generalize to follow up problems like multiple characters. Push on opening parenthesis. Pop on closing parenthesis. Trivial.