[neilk]

OP has the wrong assumptions. The live technical interview is already well-known to be flawed, because qualified people often fail. However, only qualified people can pass.

However, it's true that coding exercises that can be completed in an interview are arbitrary and abstract (by necessity, since you have no context.) In my opinion one should use live coding exercises to test fluency -- can you code at the level you are claiming? Debugging something might be a better test. Then pair that up with a short (short!) take home exam to test problem-solving.

The one thing that really has to go is whiteboard coding. Ask the candidate to bring a laptop or give them a used one.

OP also thinks that high-pressure situations don't occur with programming. But if you work on the web, sooner or later you will be debugging a tricky issue that's costing that company $X per hour while your all your managers up to the CEO hover behind your desk. Being able to communicate with non-technical people and inspire their confidence is also very important. Often more important than coding ability.

[venomsnake]

The assumption that only qualified people can pass a technical interview is somewhat wrong.

I have had my fair share of false positives. And probably I have been one or two times the false positive. And this is something that everyone can relate I suppose.

Sometimes you just need luck - like the gotcha question being something you have debugged soon in a language you are not that competent at.

[neilk]

Yeah. I didn't want to get into that, because it's a deeper question. But I think you can eliminate complete bozos.

[danielweber]

Complete bozos is what FizzBuzz is for, right?

[kasey_junk]

"However, only qualified people can pass."

If only this were true. There is a whole class of people out there who are stellar face to face and not great for your specific technical/business situation.

[neilk]

Yeah. To be honest, there are cases where I've been that guy.

But past a certain level, it's your job to explain your own weaknesses too. I just had a technical interview the other week and they relied way too much on definitions and whether I'd heard of this and that. I happen to do great at those but I want to be sure I can be productive (the position uses Elixir, which I'm totally unfamiliar with) so I'm suggesting they give me a take-home exam.

[lucasnemeth]

Well, I've seem a lot of false positives. The questions asked tend more to the mathematical side, So I've seem smart people but with little programming experience, that didn't knew how to write quality code, pass those interviews.

The problem is that problem solving with fancy algorithm's can even be part of the job, but are normally just a small fraction. I've never seem dumb people going incredibly well in technical interviews, that's true, but I've seem a lot of bad programmers giving great answers to those abstract problems. And sometimes, they're knowledge wasn't actually a fit.

[ctdonath]

The one thing that really has to go is whiteboard coding.

A smart candidate will bring a notebook computer, loaded with suitable IDEs etc ready to go, without being asked to. Impresses people when you tell them to continue the interview while you write the requested code (multitasking, competent enough to spare nontrivial brain cycles answering unrelated questions).

[aaronem]

Judging by the downvotes, this isn't something HN commenters find advisable. It's also something I hadn't thought of, and as I am currently looking for a new position, I wondered whether it was something I should consider doing.

Will some of those with opinions of this suggestion describe those opinions, so that I can better evaluate whether or not it's actually worth considering? Thanks!

[jorkro]

As I'm responsible for a small development department, I regularly do interviews including written tests. If one of the candidates would ask me if they could do it on their notebook, I would probably say no, as it sort of defeats the purpose.

However, I don't think bringing your notebook to show off some of your work is a bad idea.

[ctdonath]

How does it defeat the purpose? We don't code on whiteboards, so just the mental transition of coding with a pen while standing up - under stress to boot - is not a good indicator of using proper tools the normal way.

Downvotes? Meh. Taking a notebook and writing the solution with sensible tools - while fielding unrelated questions from 4 interviewers - got me an offer.

[ctdonath]

In the age of ultraportable computers and free/cheap IDEs, why would a software engineer not take his toolbox, prepared to demonstrate his abilities on demand? Doing so got me two offers.

Why the downvotes?