Interview like you're already hired

I’ve been doing some technical interviews lately at $DAYJOB, which has been fun and interesting to get back into. I used to interview engineers and managers all the time at previous jobs; I’ve probably interviewed hundreds of people by now. Meeting candidates and working through little challenges together can be a nice way to break up the day.

But honestly I was shocked by how badly some of these recent interviews went.

I don’t think these interviews went south because we did a poor job screening candidates, or even that the candidates themselves were incapable of meeting the requirements of the role. They just categorically failed to demonstrate their abilities, which for me is the basis of a no-hire conclusion.

To avoid those pitfalls and show up as an impressive technical candidate, here is some advice you didn’t ask for.

Prepare!

Rule number one for any interview process is preparation. Whether we like it or not, an interview is a performance, and there is no successful performance that doesn’t start with some amount of rehearsal.

First things first: research the company you’re interviewing for. Assuming you’d actually like to land this job, you have a responsibility to learn as much as you can about it. When I worked on Wayfair’s website, would you believe candidates came in who hadn’t spent much time looking at the site at all?

My favorite thing to see was when candidates had not only browsed the website, but had strong feelings about things we could do better, or ideas we could try. Even if they were stupid ideas, it showed that they gave it some thought and could imagine themselves in the driver’s seat, contributing to the product.

If the product is not a public website, or if the domain is a classically secretive one (like government contracting, defense, etc.), find out what you can. Don’t be afraid to ask specific probing questions when you speak with recruiters at the company. They might be your only reliable source of inside information!

Second, but no less important: if you’re going out for an individual contributor role in software, be able to write software. It’s OK if you’ve been in management for a while, or taking a break from work entirely. Life comes at us pretty fast and we have to roll with it, but when you’re being asked to do a straightforward programming exercise you’d better be able to do some programming.

The thing is, I just can’t trust that everything on your resume is true. A resume is like a very blurry picture that begins to form some rough shapes, but resumes are notoriously easy to falsify and challenging to verify, so the only real evidence I have for your current skills is what you can do in the interview.

And look, I know that this sucks, and I know that our industry’s classic approach to interviewing is imperfect and that it’s more of an art than a science to separate the signal from the noise, but if you show up to a technical round and can’t cobble together a couple of functions in Javascript or Python or something, my faith in you is going to rapidly plummet.

I don’t do “leetcode” interviews. Not as the interviewer nor as the candidate. If you can write a depth-first binary tree search from scratch all it really tells me is that you can memorize things. Still, spending a little time leading up to an interview “sharpening your tools” by running through some exercises online is not a bad idea, and it can only help you.

Get comfortable being asked a hard question and breaking it down, writing out the questions you would ask an interviewer to steer your solution, and hashing out the structure of the code. To me, that’s 90% of the job anyway. Can you collaborate, bring value through ideas, and translate your concepts into working code? How do you demonstrate that?

Set the tone

As I said before, whether you like it or not, an interview is a performance. During your interview, you need to bring out the most confident version of yourself that you know. For that bounded window of time in which you’re showing off what you can do, you need to believe that you can do the job.

If you made it into a live-coding round, you must have done something right! This is not the time to dig on yourself or make excuses for any of your perceived skill gaps. Nobody wants to work with someone who is constantly hating on themselves and jumping under every bus that drives by.

If you want to tell me that you’re really anxious and that it takes you time to get comfortable working on a problem, that’s fine! It can be hard to admit that to a stranger, and I applaud your honesty. Honesty is good. Repeatedly making fun of yourself, though, only makes it easier for your interviewers to doubt you.

If you’re going to fail, if you have the sudden realization that you’re way beyond your depth, make it your mission to flame out spectacularly! Dig in, try hard, focus on asking great questions, and get as far as you can with what you know.

I’ve hired countless engineers who could not complete the entire coding exercise because I know that smart, motivated people can use Google. What you need to demonstrate is that you can see where your gaps are and that you have some idea of how to fill them. Ask direct questions (“can I assume X?”), lean on your resources (“is it okay if I look this up real quick?”), and be clear about what you do and do not know (“I think a regular expression would work here, but I don’t remember the syntax”).

Self-awareness is a surprisingly rare and powerful attribute. Show that you know what you know, but frame it as a strength, because it is. Instead of “I’m so rusty, I’m sorry I can’t write this simple loop,” spin it around into something like “I haven’t written Javascript in a while but I know there is a syntax for this, is it okay if I look that up?”

Finally, asking questions is great. But asking a question, stating your assumed answer aloud, and forging ahead without even pausing for any response is self-sabotage. Interviewers, more often than not, want to help you, because they want to know what it would be like to work with you. If you’re going to ask the question, wait to hear the answer.

How to do a great interview

I’ll summarize everything into a tidy list for you:

• Prepare by researching the company and its products, and forming opinions about them.

• Sharpen your tools: know the basic syntax of a popular scripting language that is likely to be used in interviews, like Python or Javascript. Assume that you’ll be asked to write code that runs.

• Acknowledge your weaknesses, but show up as the most confident version of yourself that you can find.

• Collaboration means listening, at least part of the time. Don’t forget to use your interviewers as resources to help you move past sticking points.

Questions for you

1. What do you look for in a candidate, and how do you bring that forward when you are one?

2. What is one thing you want to be better at in an interview, and how will you practice it?

3. What can you take away from this that will help you in your day-to-day work?

Comments