Quality Assurance (QA) engineer. I do QA Tools specifically but still need to be on top of most QA stuff. Other QA engineers exist in the company for in depth QA.
My initial question starts with: "build a function that takes a string and produces an integer". About 30% of candidates fail to get anywhere. 50% produce an incorrect implementation. 20% produce an implementation that is mostly correct. 9% produce an implementation that is mostly correct and well tested. 1% actually produce a complete and correct response. Which, as of right now, translates to exactly 1 candidate in 2 years. Who was rejected due to culture fit. A complete and correct answer is not required to pass the screen. ;-)
The reason this question is so effective is due to how the question is asked and the details of the solution. There is a lot more than just the initial problem statement. The full script assess: the candidates ability to determine requirements; ability to produce complete set of unit tests; ability to handle the boundary conditions.
There is a sharp division that occurs between QA engineers and non-QA engineers on the requirements gathering. All but 1 non-QA engineer I've interviewed assumed they had all the requirements before writing code. A clever solution is almost useless if it solves the wrong problem. Sometimes even worse than useless if the code adds a maintenance cost for no value.
Covering all the critical cases in testing is the next part that most candidates fail at. Even if the requirements they assumed are correct, none of the non-QA engineers have succeeded in writing a complete and good set of tests. Many add too many tests.
After those two the other parts are just seeing how close they can get to building the correct implementation. The candidates typically pass if they do well in all parts; perfection is not required. Still, I think it's interesting to note that almost nobody has ever written a 100% correct solution. Even if they are given all the requirements in detail.
This question does not asses algorithm design ability. At all really. Well, I suppose there was somebody who immediately proposed "binary search!" and really wanted to stick with that idea. No clue why...
That would match the initial specification. The point is for the candidate to note that the initial specification is too ambiguous and determine what they do about it.
If they gave that answer and then said "which is why the specification is weak" then great! If they gave that answer and called it done... well... not so good.
My initial question starts with: "build a function that takes a string and produces an integer". About 30% of candidates fail to get anywhere. 50% produce an incorrect implementation. 20% produce an implementation that is mostly correct. 9% produce an implementation that is mostly correct and well tested. 1% actually produce a complete and correct response. Which, as of right now, translates to exactly 1 candidate in 2 years. Who was rejected due to culture fit. A complete and correct answer is not required to pass the screen. ;-)
The reason this question is so effective is due to how the question is asked and the details of the solution. There is a lot more than just the initial problem statement. The full script assess: the candidates ability to determine requirements; ability to produce complete set of unit tests; ability to handle the boundary conditions.
There is a sharp division that occurs between QA engineers and non-QA engineers on the requirements gathering. All but 1 non-QA engineer I've interviewed assumed they had all the requirements before writing code. A clever solution is almost useless if it solves the wrong problem. Sometimes even worse than useless if the code adds a maintenance cost for no value.
Covering all the critical cases in testing is the next part that most candidates fail at. Even if the requirements they assumed are correct, none of the non-QA engineers have succeeded in writing a complete and good set of tests. Many add too many tests.
After those two the other parts are just seeing how close they can get to building the correct implementation. The candidates typically pass if they do well in all parts; perfection is not required. Still, I think it's interesting to note that almost nobody has ever written a 100% correct solution. Even if they are given all the requirements in detail.
This question does not asses algorithm design ability. At all really. Well, I suppose there was somebody who immediately proposed "binary search!" and really wanted to stick with that idea. No clue why...