3 ms·

> Outside of a special-case like certain CS students, this question is likely to give very inconsistent results, and those results are going to be dominated by

> Outside of a special-case like certain CS students, this question is likely to give very inconsistent results, and those results are going to be dominated by a candidate’s recent familiarity with the underlying problem, rather than their coding skills. > In most cases, that makes for a bad interview question. Well, I'm going to have to disagree there. Asking the question and expecting full knowledge of the theoretics behind it, yes. But real-world "practical" software engineering often requires writing parsers, and yes, parsers for context-free languages (whether the parser-writer realizes that or not). A simple, hand-rolled recursive descent parser would suffice for this language. > But what if someone hasn’t seen this stuff in a decade? Or learned to program without going through a formal CS education? Is it reasonable to expect them to work out the ideas in an interview? Someone, in a decade of SWE experience, has never needed to implement a parser? Parsing, as a category of things to talk about, has stuff that someone with a theoretical background should know, but it is also so imminently practical that someone without the degree should have hit it and be able to answer it. I'm not asking that they realize this is a deterministic context free language, or that a PDA is the appropriate machine to parse such a language. The point of balanced-parens as an interview question is not to get you to recreate the entire history and hierarchy of languages. It's to get you to write a for loop that requires a moderately involved data structure (a stack) to see if you have any ability to reason and to code. (I also dislike asking the single-variant form of this question, as you can solve it w/ a simple counter. If you involve a second type of matched character, e.g., {}s, then it should require a PDA.) Are other engineering disciplines so readily accepting of folks w/o training in the field in which they're applying a job to? If not this, then what? "They might not have run into this!" is why we (should…) ask more than one question in an interview. But I feel like this refrain gets used to justify never asking any question which might reveal that half the candidates that apply for "Senior Software Engineer" positions cannot express proficiency in any programming language…

braythwayt 8y ago
Where I work, we track statistics on our interview questions. We are retiring this one because we believe that the results are strongly skewed by whether the candidate has had exposure to the theory behind it. We only use this for people at the beginning of their career, mind you. We have completely different expectations of someone with ten years of experience than we do of someone applying for a CAP (aka "work-term") or SDE I (aka "entry-level") position. It's not that good people can't work it out from first principles, but it's clearly a lot more work for those who have to figure it out from first principles than for those who know immediately that a stack is involved and apply their focus to the loop and the stack and handling follow-up questions. The ideal question or problem from our perspective is is one that is equally challenging for everyone, that way when we're having a candidate review, we won't need a lot of, "...But then again, the candidate clearly knew nothing about parsing, so they actually did quite well, considering."
- thaumasiotes 8y ago
  > The ideal question or problem from our perspective is is one that is equally challenging for everyone It seems like you could solve this by asking a question no one has ever been exposed to before, or by exposing each candidate to the theory relevant to the question yourself. Except that the first strategy is guaranteed to fail some of the time, because there are no questions like that. Why not go the other way?
  - braythwayt 8y ago
    There is an interesting communication problem here. If I could guarantee that every candidate would read my blog, I'd happily point them to an essay like this, and then in the interview we could work on something meaty, like pattern matching. That would suit your second recommended strategy. But I wouldn't want to write an essay like this, and then favour those candidates who like to read Hacker News or follow me on Twitter. We're trying to select for talent, not for membership in a tribe :-) So we're retiring this question, and we already have a few replacements that we use for many candidates. But I won't blog about them, in an attempt to hew closely to the first strategy you suggest.
    - thaumasiotes 8y ago
      I think you could pretty easily guarantee that every candidate will read email from you (where "you" are their point of contact with the company) prior to the interview. Why do you need to direct them to the essay from your blog?

braythwayt 8y ago

Where I work, we track statistics on our interview questions. We are retiring this one because we believe that the results are strongly skewed by whether the candidate has had exposure to the theory behind it. We only use this for people at the beginning of their career, mind you. We have completely different expectations of someone with ten years of experience than we do of someone applying for a CAP (aka "work-term") or SDE I (aka "entry-level") position. It's not that good people can't work it out from first principles, but it's clearly a lot more work for those who have to figure it out from first principles than for those who know immediately that a stack is involved and apply their focus to the loop and the stack and handling follow-up questions. The ideal question or problem from our perspective is is one that is equally challenging for everyone, that way when we're having a candidate review, we won't need a lot of, "...But then again, the candidate clearly knew nothing about parsing, so they actually did quite well, considering."

thaumasiotes 8y ago
> The ideal question or problem from our perspective is is one that is equally challenging for everyone It seems like you could solve this by asking a question no one has ever been exposed to before, or by exposing each candidate to the theory relevant to the question yourself. Except that the first strategy is guaranteed to fail some of the time, because there are no questions like that. Why not go the other way?
- braythwayt 8y ago
  There is an interesting communication problem here. If I could guarantee that every candidate would read my blog, I'd happily point them to an essay like this, and then in the interview we could work on something meaty, like pattern matching. That would suit your second recommended strategy. But I wouldn't want to write an essay like this, and then favour those candidates who like to read Hacker News or follow me on Twitter. We're trying to select for talent, not for membership in a tribe :-) So we're retiring this question, and we already have a few replacements that we use for many candidates. But I won't blog about them, in an attempt to hew closely to the first strategy you suggest.
  - thaumasiotes 8y ago
    I think you could pretty easily guarantee that every candidate will read email from you (where "you" are their point of contact with the company) prior to the interview. Why do you need to direct them to the essay from your blog?