People suck at technical interviews

A response of "I'm not sure; I always rely on === and explicit conversions to avoid the ambiguity. My guess would be (doesn't matter) though" is not only answering that question, it's scoring an 11/10 of the possible points (were it pointed).

M-x ispell

Not one company has invited you to come onsite for a day-long interview to code alongside the team?

You should be upfront with the employer. "I think the best way for me to showcase my skills would be to come onsite for a day, and tackle whatever projects you're working on currently. After 8 hours, you'll have a good assessment as to whether or not it's a fit, and vice-versa."

One can learn facts. In fact, it is incredibly trivial to do so if you are smart. I need to do it dozens of times a day to do my job, as does any programmer.

I don't program javascript at all, but am vaguely aware of the terrible implicit conversions it does. Isn't that the important part? I do not have memorized that

   false == 'false'    // false, yet
   false == '0'        // true

Why would I (I had to google that, took 5 seconds, btw)? It is ugly, terrible code. Sure, if I spend my days in a terrible code base I might be forced to learn those conversion rules, but that isn't exactly the mark of a hirable person - it is just the employment history of that person.

Now, if somebody who claimed they knew javascript was writing 'j := 0' for assignment I'd be concerned - but probably they've just been writing a lot of Go lately.

I can see a question like this being asked as part of a lead in to a more general discussion about types, type conversion, how different languages manage it and the trade offs thereof. But, most of the nit-picky questions I have ever been asked in an interview were just nit-picky. What is the output of the obfuscated C? What happens if you abuse the syntax like so? Just pointless questions compared to the real thing you should be measuring - can I produce high quality code on schedule and budget that adds value to the organization without making everyone around me wish they were dead rather than talk to me again? Can I recognize inefficieces in the company and improve things? Can I step up and lead a team or a project? If asked to do something outside of my comfort zone, like go on a sales call, can I do it? Will I complain bitterly if asked to fix bugs for awhile? Will I skip off to a new job just as I start becoming productive at your company? Can I mentor junior people? Can I converse with the CEO and tell him difficult facts if necessary? Can others read my code, modify and extend it without undue problems? Can I untangle other people's spaghetti code?

Measure that stuff, not whether I know if 0 == 'false'.

Oh how I agree with this post. And I've been the asshole on the hiring end before - but I (hope) have learned my lesson.

I recently interviewed with a consultancy (role was UK-based) that is desperate (quite literally) to hire experienced developers in the technical area I have experience in. I came highly recommended by a recent senior hire of theirs (he had been my manager).

The technical filter question in the face-to-face interview was (paraphrased and simplified): "write an algorithm on the whiteboard to check for mismatched braces".

I described an approximate solution aloud, but did not complete the solution in the interview.

As it happens I solved it in my sleep the following night - but of course they will never, ever know that.

Now everyone will have their pet theories as to why this is a good or bad question, but these are frankly moot because I am confident the hiring developer had no idea what he was testing for with it. He may have a vague "I know the answer, so he should too" mindset, but not much more.

What does this question, presented verbally in an interview really test? A recursive solution sprung to mind, but I can recall implementing recursive solutions in production code only a few tens of times over a ten year career. The question does not test for experience with the technology they are hiring for. It certainly filters out developers who cannot come up with an algorithm while standing at a whiteboard infront of a hostile audience. I could go on, but the biases implicit in this question are as numerous as they are irrelevant.

After a few years in the industry you typically get to work direct with these so-called "top end" consultancies anyway, so you get to know what these kind of questions don't filter for. I can say with confidence and from experience they don't filter for ability to create high quality software.

The thing is, this 'clever' 'does he know recursion?!' question is almost insultingly trivial when compared to the type of problems most development teams face.

Like the fact that although "Joe" has an IQ of 150, he speaks in sentences so impossibly convoluted he may as well be mute. Or "Alice" the sole domain expert, who begrudges her position in some way and will only communicate after you have negotiated the massive chip on her shoulder.

Hell, most organisations can't even provision accurate testing environments and force their developers to run underpowered Windows laptops.

Let's walk before we can run yeah?