3 ms·

The purposes of these interviews is not (usually) to see if you know the answer. It's to see how you problem solve. If you knew the correct answer to e.g. the

The purposes of these interviews is not (usually) to see if you know the answer. It's to see how you problem solve. If you knew the correct answer to e.g. the BFS algorithm, you'll get thrown another question that they hope you don't know. When interviewing, the thing I want to see most is how someone works through a problem: can they solve from first principles? do they go via trial and error? do they ask for a computer to google things up/a book? Picking raw CS problems is an easy option, as its something that you should be able to solve, and it means I don't have to require you to know Angular/React/Flavour of the month (new tools are easy to teach the right candidate). You're not going to immediately know the answer to everything that comes up in your job; so evaluating how you solve the unfamiliar is very important.

odonnellryan 11y ago
That's cool, but it's understood that it's a very complex process to "figure out something you don't know." It absolutely includes talking to people. But not people you don't know, in a very high stress situation, under the pressure to solve the problem in thirty minutes :) That is sometimes required, definitely. But I'd say that situation only applies to the .01% of real-life programming situations.
pjlegato 11y ago
That sounds nicer than what 95% of programming interviewers actually do, which is something rather different. Almost all are simply playing "programming trivia." They name an algorithm or a data structure, and then evaluate whether you can recite it from memory. That's it. There is no problem-solving element involved. It is purely a test of whether you can memorize and recite. This requires a lot less effort on the part of the interviewer than the style you describe, and also bolsters their ego and makes them feel clever when they find a candidate who can't recite properly.
- daurnimator 11y ago
  I'd say that VPs of engineering and CTOs have what I described in mind, but the execution faulters.
- infinite8s 11y ago
  If that's the case, is that really a company you'd want to work at?
  - radnor 11y ago
    When it's the case with nearly every company around you, and you really need a job right now, what choice do you have?

odonnellryan 11y ago

That's cool, but it's understood that it's a very complex process to "figure out something you don't know." It absolutely includes talking to people. But not people you don't know, in a very high stress situation, under the pressure to solve the problem in thirty minutes :) That is sometimes required, definitely. But I'd say that situation only applies to the .01% of real-life programming situations.

pjlegato 11y ago

That sounds nicer than what 95% of programming interviewers actually do, which is something rather different. Almost all are simply playing "programming trivia." They name an algorithm or a data structure, and then evaluate whether you can recite it from memory. That's it. There is no problem-solving element involved. It is purely a test of whether you can memorize and recite. This requires a lot less effort on the part of the interviewer than the style you describe, and also bolsters their ego and makes them feel clever when they find a candidate who can't recite properly.

daurnimator 11y ago
I'd say that VPs of engineering and CTOs have what I described in mind, but the execution faulters.
infinite8s 11y ago
If that's the case, is that really a company you'd want to work at?
- radnor 11y ago
  When it's the case with nearly every company around you, and you really need a job right now, what choice do you have?