I am terrible at taking tech interviews. Out of dozens that I’ve done, I may never have passed one. My typical pattern goes like this: A serendipitous contact leads to outstanding phone call with a manager or recruiter. I move on to a phone screen with a hiring manager who comes away very excited. Finally, I go onsite (or online these days) to dig into the nitty gritty with coders and get washed out.
Sometimes they would want to hear something I didn’t know. Other times I just froze on topics that I know very well. (One time I couldn’t even name my favorite video games.) Many times, I failed to perform well on some logic puzzle. Every job I actually got was because a friend made sure that it happened.
For years and years I lived in fear of the interview because I knew that I’d fail. At the same time, I knew that I was a very good developer. I was always a go-to guy on my teams, took on large projects alone, and had success as a lead.
As I struggled with my own interviewing issues, I set up interview pipelines as a manager that mimicked those that I had experienced. Brain-teasers, tests, technical grilling, the whole works. As I informally observed the track record of those pipelines in hiring great people, I began to realize that the only real predictor of great hires was if the candidate already knew someone on the team. You can’t just go off of one guy’s word that his college buddy is great, though. It’s not fair to your current employee to bear the entire burden of the hiring decision. So what do you do?
I finally stumbled upon the cure when I interviewed at a small startup that had a different approach. I met the leads for lunch, then followed up with a social chat with the whole team. We talked tech, but they didn’t try and vet my skills. Instead, they offered me a paid contract to do some work that they actually needed done. They gave just enough direction to get me started and then left me to my own devices to see if I could get it done well, on time, and with good communication. It took me about 10 hours of time in the evenings to complete. Three days later, I had a job offer!
Since that day, I have refused to take traditional tech interviews. I politely suggest that a short contract job might be the best option for a company to evaluate a senior developer. This works very well if they are unsure about you. It works even better if they really want you. As an added benefit, you get to see what it’s like to really work with a team before you take a job with them.
There have been some companies that refused to use my model, which I totally understand. Those jobs are just simply jobs that I am not going to get anyway. I just thank them for their interest and move on.
Succeeding with this approach to interviewing gives you a level of credibility and leverage that you can never get from a traditional interview. I have had a 100% success rate (4/4) in getting job offers from companies that I interview with in this way. The one that I actually accepted was from a company that, instead of hiring me, decided to invest in creating a new startup with me.
Some people do very well with traditional interviews and they should stick with what works for them. However, I’d urge any company to really look hard at what their interview process is screening for. Does it accurately produce employees that do great work and fit well with the team? Does it select people who have heard your particular brain teasers before? Are you just going through the motions on interviews and then going with someone’s gut? Maybe that manager is really good at guessing, but what happens when they leave? Think about whether or not the short term contract approach might give you a better idea about a candidate’s value.
EDIT: Thanks for all the interest, medium, twitter, and hackernews readers! I didn’t expect a response like this. I guess most engineers have had a terrible interview experience or two… or many.
Some quick clarifications to respond to some of the excellent criticism I’ve read today.
None of this applies to conversational interviewing. Ask me about closures or what the mutable keyword means all day long. It’s totally important to know if I’ve worked much with CSS(no) or if I know how A* works(yes). What I’ve opted out of is whiteboard coding, brainteasers, live coding, etc. A rule of thumb… if we can discuss it over beer or a bourbon, I’m game.
I’m not a “hide him in the corner” sort of coder. I’ve been an Executive Producer in the games world and done tons of team speeches, investor pitches, conference talks, publisher calls, etc. The difference in those settings is that I can nearly always say, “I need to think about that. I’ll get back to you tomorrow.” People tend to respect, “I don’t know that off hand,” too. I’ve learned to prepare and rehearse until I feel natural going from the script or diving into the many conversation tree options that I’ve pre-planned for. I haven’t been able to make these strategies work in a tech interview.
On top of that, you never know when you’re walking into an ambush with a tech interview. A great interviewer knows that it’s THEIR job to find out what a candidate is good at, if anything. Most interviewers are not great. Once you’ve got your leg stuck in the bear-trap of a stupid brainteaser, you’ve lost the job. By opting out of entering this minefield, I can filter for the situations where I’m much more likely to succeed and get along with the team.
Thanks again for reading and commenting!
EDIT 2: A former colleague of mine asked if I would refuse to answer a particular interview question of his. I’d never refuse to answer a tech question in an interview. If I’ve gotten myself into that situation, that’s what I get. It’s disrespectful to not even try. As an interviewer, I’d just assume that the candidate didn’t have a clue if they refused.
The goal is to not get into a situation where I’m at the mercy of whatever person is interviewing and have only limited skills in surviving.
