Good Interviews, Bad Interviews
I was voluntarily unemployed for almost three years, then I got a job. I applied to over thirty tech companies in a two month span. About twelve of those turned into interviews.
Positive traits are independent of company size and industry.
- Someone owns the interview process. This is the most important trend. It can be a recruiter (internal or external), a founder, or an employee. As a candidate, having a single point of contact to ask questions ("Can you suggest topics to brush up on before my technical interview?" "Who can I talk to more about business questions?") made everything smoother.
- Responses are timely and proactive. See above. I noticed that chaos in interviews correlated with chaos internally. If you tell a candidate you'll get back to them by Friday, get back to them by Friday.
- Interview questions are relevant to the job. More on this later. My favorite technical interviews, even at companies that turned me down, asked coding questions that were directly relevant to the company's needs. I may never convert an array to a graph in my day-to-day career, but framing the question inside the company's business needs made the process more fun.
- Technical interviewers are helpful and forgiving. Writing code on a whiteboard is unnatural, like soccer. If you get stuck, an interviewer who gives hints and helps you talk through ideas makes it less intimidating and awful. It also means they're knowledgeable about the question.
Flip everything above.
- No one owns the interview process. In one case, five separate people contacted me from the same company over several months, despite there being no open position for me. In another case, I was scheduled for an on-site but was never told about it. In another case, someone asked for my "git," then disappeared.
- Responses are chaotic or late. In a few cases, replies were a week or more apart. Some companies didn't get back to me until more than a month later, at which point I already had offers on the table.
- Interview questions have nothing to do with the job. I understand asking data structure questions to gauge reasoning skills. I don't understand asking binary math problems when you're applying as a web developer.
- Technical interviewers aren't helpful. Maybe they don't understand the question they're asking, or aren't experienced enough to help you. Maybe they don't know what's important to get right, and the interview tells them nothing, wasting both parties' time.
One interview sticks out in my mind because it raises almost every technical red flag I have. It was a phone screen, followed by a take-home coding challenge.
The coding challenge had nothing to do with the company, industry, nor day-to-day work. It was presented as such, and I'm quoting:
- It's a coding "puzzle."
- "This is a tricky problem. There's a trick to it."
- "The problem is not very practical."
- "Don't worry about writing good code."
- Solving this problem means you have "grit" and "perseverance."
- "This problem tests if you are somewhat smart."
- "For some people, this problem may take up to two weeks."
- "Solving this problem means you belong in programming."
Worst of all, this was presented by the CTO. These are not core technical values I want to sign on with. I was unable to find the trick to the puzzle, which apparently means I don't belong in programming.
It's easy for me to critique the interview process as a candidate. In the past, I've been the interviewer, and made plenty of my own mistakes. The overall landscape of interviews was good. Maybe even enjoyable.
If you enjoyed these thoughts, consider following me on Twitter.