Interviews
As a software developer, looking for a job is one of the most stressful things you will ever do. This is particularly true for your first job. In the months leading up to my departure from the Army I applied for 117 different jobs. From those 117 applications I received 35 responses. From those 35 responses I was able to secure interviews with 18 different companies. Of those 18 different companies I was eventually extended offers to work at 6.
Think about that for a minute. Out of 117 applications I only received 6 offers. Why was it so hard to get a job? Especially when the news media is constantly broadcasting a shortage of tech workers.
Seattle Startup Week was a large source of interview opportunities for me. At one point in the week I attended a workshop by an Amazon Bar Raiser that was actually targeted at startup founders. I listened in with the intention of seeing what he recommended they look for in an aspiring candidate. He had three simple rules:
- Set your standard (whatever it is) before, not after, meeting the candidate.
- Ask yourself “How risky is this candidate?” Reject those that have any risk at all.
- At the end of the interview consider whether it would be a mistake to NOT to hire this candidate.
His reasoning for risk aversion was simple. Startups are small in the beginning, usually not more than 3 or 4 people in size. Hiring the wrong person could compromise the prospects of the entire company, smothering the aspirations of the founders before they even had a chance to succeed.
The breadth of interview styles that I faced as a candidate was as diverse as the companies that I applied to. Most required that I interview on-site after passing an initial phone screen. Some exclusively did phone interviews. Others had take-home assignments. Still others did online code tests. A couple were as brief as a short conversation and a handshake. Despite the differences, there was a common thread between all of them. Could I be trusted?
Smaller companies more often than not sought to confirm that trust by probing my honesty and likability. This was because they usually lacked the in-house technical expertise that I specialized in. Moderately sized companies were more likely to have at least one individual familiar with my field. Questions in these interviews would focus on making sure I was up to date on current practices so I could hit the ground running. Larger software companies , rather than becoming even more specialized, actually focused on my grasp of computer science fundamentals in general. This usually meant white-boarding algorithms, data structures, and design patterns.
Each interviewing approach had its benefits and drawbacks. As with any new experience, I got better at the various interview styles with lots of practice. The mistakes I made became scarred into my memory, and I never made same mistake twice. Eventually, I had accumulated enough “scar tissue” to regularly secure offers in any of the interview types.
Since then I’ve spent an equal amount of time on the other side of the table as an interviewer. 26 interviews for candidates that would work directly for me. Dozens of others for those that would work in parallel teams within our company. In each case the objective has remained the same: Could I trust them? Trust them to hit the ground running, put in their hours, work well with others, and require a minimum of hand-holding?
Developers are given only a limited amount of time to make a decision about the candidate they interview. For the majority of the interviews I’ve been limited to a 30 minute phone screen and a 30-60 minute in-person interview with the candidate. For the phone screen I’ve generally focused on what I call “pub trivia”. That is, questions about their familiarity with libraries for concurrency, databases, and networking as well as tools for debugging. source control, and project tracking. In my opinion the phone screen is a great opportunity to get these questions out of the way. Doing so allows you to maximize your time observing the personal behaviors of the candidate during the on-site as they work, rather than going through questions of rote memorization.
What do they work on in the hour that I have with them on site, you might ask? Generally my approach has been to pair-program with them, either debugging a feature that I intentionally broke, or implementing a series of features of increasing difficulty. The intent is two fold. The first is to see how well they communicate with their partner during pair programming. Are they easy to work with? The second is to gauge their comfort with coding in general. Nothing is off the table for them, including auto-complete, Google, or even Stack Overflow. So far I couldn’t be happier with the results.
Do you have some interview war stories, from either side of the battlefront? Leave your story in the comments section below!
Photo credit to unsplash-logoHunters Race
comments powered by Disqus