I will not do a tech interview

My best technical interview was a take-home programming assignment. I could ask questions by email. After a week, I would present my work to the other programmers and they'd ask questions about why I did something a certain way.

Best interview process ever, and that company had excellent programmers and the lowest employee turnover I've ever seen.

"Then don't. Toss out this experience if I'm not clearly better."

Telling a person they need to just be different is easy; being different is hard, and maybe objectionable for other reasons.

For one, actually becoming more relaxed in confrontations is not something that has been achievable merely by asserting that I want to be -- instead, the only thing that seems to work is being in confrontations enough more often to reduce the stress level of such an environment. While this works to some degree, it raises the anxiety or stress level of the rest of my life, and is thus completely antithetical to most of the other things I do to make my life better. If I can instead just avoid situations which raise my stress level, and in which I would perform less well, that seems more conducive to overall happiness.

For another (and this was somewhat already implied), making changes to one's personality often has other effects on one which may be undesirable. Being more assertive might make it more likely that one bullies others (unintentionally). I've noticed this in myself as my assertiveness waxes and wanes: if I'm feeling especially confident, I'm more likely to say things without qualification, and say things that I would normally stop myself from saying. Later, I wonder if what I said came across as asinine, since that's how I would take such statements.

I sympathize quite a lot with the original poster, because while I'm a pretty good developer (at least, some others praise my skill highly), I'm really, really bad at interviewing, sales, talking to clients in a situation where I actually depend on their response, etc. (A previous commenter was quite right when he compared interviewing and sales -- they raise the same confrontational anxiety). When hired for a previous job, I was told months after the hiring that the interviewer was quite astonished that I'd turned out to be an intelligent and very capable developer, since I'd interviewed terribly, and the only reason he'd hired me at all was that he was having a fight with HR, and had announced that he would hire the next person he interviewed to show them how that worked out. That worked out poorly for his argument, but well for me and the team. :)

I walked into an interview once, expecting to go over my work which I'd brought along with me, much of it for the company I was interviewing for, so I wrongly assumed the interview was just a formality. They asked a couple of basic questions then opened a laptop, and BOOM! technical interview right out of no where.

I blanked. They just handed me the laptop and didn't even tell me it was a test. There were some comments at the top of a few javascript files and like an idiot I answered the questions verbally. The two devs just sat their smirking at each other like they'd won at something.

I'm not averse to tech interviews, but I do not enjoy the "look at how smart we are that we caught you out" attitude that comes with them. I'm shit at crosswords, that doesn't make me illiterate.

I've since been keeping an eye on their work and now I get to feel smug because it's been universally panned.

I also had to sit a test for what I call "the worst agency in the world" (AKQA and after 7 hellish months there I'm happy to stand by and put my name to that assessment, they're simply awful). I forgot to specify the radix in a call to parseInt. It was the only flaw and while they didn't make a big deal out of it, the interviewer was clearly pleased with himself for finding it. They then proceeded to ask ZERO questions about why I'd coded the test the way I had. Which is a shame, they might have learned something.

In my experience, there's nothing wrong with tech interviews, but there's a lot wrong with the people administering them. If I want to know wether a dev knows what they're talking about, I ask them to explain something they've already coded. If they can explain it, they understand it, and I usually learn something to boot. Everybody wins.

> Google's brainteasers did not lead to quality candidates

This is why we at Google don't (or shouldn't, at least - it's widely discouraged) ask brainteaser questions in interviews.

I disagree on whiteboard coding though. I don't find it that easy, but I think it's reasonable to expect a demonstration of relevant skills before you hire a candidate. Any sensible interviewer won't expect syntax-perfect code on a whiteboard, but it's at least a way of seeing if the candidate can walk the walk rather than just talking for an hour.

> I guess I do not see how you can lose if you take the contract-to-hire approach ..

For the first month, the vast majority of people are relatively unproductive. After the next month, good candidates are generally still going through a significant learning curve. Contracting several candidates for a few months to pick one who seems good enough is expensive for relatively little output - apart from salaries, they need desks and computers etc, and you have to do some interviewing to pick them in the first place. It's not a worthless approach, but I don't see it as a panacea.