[13of40]

Not to say asking puzzle coding questions is an ideal approach, but I think the motivation is somewhat opposite: If you base your hiring decision on how awesome the applicant tells you they are, a certain number of the people you say "hire" for are going to be bullshit artists who can't code. When the interview is over, the interviewer is judged either explicitly or implicitly on how well they conducted the interview, and there's probably nothing worse they could do than say "hire" to someone and have the next interviewer find out they're lacking basic coding skills. So they have to ask some kind of coding question, and it has to be something with some meat to it, but you probably can't make it too OS or framework specific, so you're left asking about overlapping rectangles.

[collyw]

Why not just ask applicants to bring in some code they have written to discuss?

If they have written it they should be able to discuss it and answer questions easily.

If someone else wrote it and they have understood it enough to discuss it, you probably have an even better developer, especially if the job involves working with some legacy code.

[wgerard]

> Why not just ask applicants to bring in some code they have written to discuss?

That can be really difficult for a lot of candidates. It's predicated on the idea that they've written code they:

a) Feel comfortable sharing (not just a one-off weekend hack project)

b) Are allowed to share, legally. This is usually the real problem for most developers.

The truth about hiring: There really isn't any one-size-fits-all that works for everyone. Any hiring process you come up with is going to be an incredible obstacle for a sizable minority of people.

[arethuza]

But why the fixation on algorithmic trivia questions - why not at least come up with examples that are relevant to the role?

[wgerard]

I mean, I agree with you.

Honestly? Because companies view those kinds of questions as proxies for IQ tests (which are mostly illegal to use as a hiring method). Notice the defense of them largely revolves around "seeing how you solve a problem" and "how you communicate your problem-solving ability". They're seen as measures of your intelligence, which is what they're actually interested in--not your experience or expertise (outside of specific areas).

Those interviews are, of course, something you can easily (with a serious time commitment, but fairly easily nonetheless) prepare for and game, which of course makes them bad proxies for intelligence. And of course, I don't think algorithm questions necessarily measure someone's actual intelligence at all. And of course, it's unclear how highly intelligence is correlated with your ability to succeed as a software engineer.

But that's why. I have little doubt that they would actually try IQ tests if they thought they could get away with it. I'm fairly certain at least one major company tried asking candidates for SAT scores.

[dempseye]

> Those interviews are, of course, something you can easily (with a serious time commitment, but fairly easily nonetheless) prepare for and game

Assuming a certain level of intelligence, that is.

[arethuza]

Thanks, for what it is worth I also have problems with the idea of IQ tests! ;-)

[13of40]

Let's say the actual role involves, for example, writing a health and monitoring system for a Windows-based service, and you're hiring for a long term FTE position. Do you ask something Windows+C# specific and eliminate the very talented guy who's been focusing on Linux+C for the last few years?

[pytester]

>If you base your hiring decision on how awesome the applicant tells you they are, a certain number of the people you say "hire" for are going to be bullshit artists who can't code.

If you base your hiring decision on how awesome they are at leetcode hackerrank style algorithm questions you're selecting for bullshit artists who memorized "cracking the coding interview".

There's a systematic industry-wide bias against realism in developer tests. It's depressing how many people think realism either isn't necessary or isn't possible within typical interview time constraints.