Everything but the answers.

Engineering interviews are long, stressful affairs. After making it through (at least) one phone screen, you’ll spend the better part of a day writing code, talking architecture, and being asked about how you “handle working with adversity.” And though these days can seem like a mechanical process of checking off boxes, there is a lot more nuance to how you prepare and present yourself at an interview.

When interviewing for a job in software, be it your first role out of college, or coming in as a principal engineer, there are plenty of things that you can do to show that you are engaged, interested, and prepared for the role for which you are interviewing.

What’s happening on our side of the table?

So, you’re excited, nervous, and probably a little overcaffeinated. We, on the other hand, are sandwiched between meetings. Like any part of a job, doing enough interviewing can make it less exciting, and more mundane (especially because we’re not taking sick days to look for a new job).

That said: while we are here to evaluate your skills, your potential, and your fit, there is also a je ne sais quoi that you can bring to the table to earn some easy brownie points with someone who has asked the same questions to different people already three times that week.

Thanks for coming in today

So, with the admission that I am speaking entirely subjectively about the things that make a difference to me as an interviewer, making a few shifts to your technique to align with the suggestions below can go a long way in building a foundation upon which your skills can shine during your interview.

Have a relevant résumé, and make sure people can find it

This is the first line where people immediately fall down. In quite a few companies that I have worked at, recruiters will often float potential candidate résumés to engineering to see if the candidates even list skills or experience that would be relevant to the role. Having an out-of-date résumé, or one that doesn’t list relevant skills and projects, or, maybe worst, having one that is a novel of every thing you’ve ever done since you were ten years old (my current record for this offense is a 13-pager), you will be skipped over before even getting an initial phonecall.

Keep your résumé up to date, and link to it on your LinkedIn, your personal site, and even on your GitHub if you want to get eyes from more engineers than recruiters. The solution I’ve gone with is completely foregoing a printable résumé that I’d have to make a new PDF of whenever I work on something interesting, and instead have a digital-only résumé built on a Jekyll template I built for myself, updating it is as easy as creating a new partial and deploying on GitHub pages, and I never have to worry about someone looking at an older version.

Your résumé speaks volumes about you before you ever get to speak - make sure it is succinct, relevant, and shows that you are the right candidate for the job you’re seeking.

It can be tempting to put all of the information you can possibly think about yourself on your résumé, LinkedIn profile, or in an email to a company, but there is a real risk to oversharing and inundating someone with irrelevant information. Specifically: Your GitHub profile. Sharing your profile can be a great way to let your work speak for itself, if you have work that is in public repos, or if you share links to private ones. But if you simply have a link to your profile, and it shows virtually no activity because all of the repositories you work in are private, or part of organizations, than you are doing no good.

It can even do harm, as you are actively showing off that you do not contribute to any open-source projects.

Research the company with which you’re interviewing

When you show up to an interview not knowing about the company to which you’re applying, it shows. When you show up knowing about the company, it also shows.

Especially if the company reached out to you initially, instead of the other way around, it’s a great idea to poke around their website or app, read their About Us page, and look up any recent news in their industry. It only takes a few minutes the night before you interview, and can go a long way toward having more educated and fruitful conversations about the type of work you might be doing in your new role.

Have questions prepared for technical and non-technical interviewers

While you’re researching the company, make sure to note down questions you couldn’t find answers for. These are great candidates to ask technical and non-technical interviewers in person.

Come up with questions for both technical and non-technical leaders. Someone in design or HR won’t know how our CI pipeline works. while someone in engineering may not know the most prominent marketing threat.

Be prepared to ask about the business, the culture, and the processes. You are interviewing us, as well. And having challenging, insightful questions not only helps you get a good understanding of a potential employer, but it has the added benefit of helping you come across as engaged and thinking deeply about the new company and job.

Be opinionated in your answers, and solicit feedback on your opinions

An onsite engineering interview typically has a few sections: (at least) one with practical technology problems, one architectural understanding, and one behavioral and cultural fit with the company.

As you answer questions in any part of the interview process, it can be an easy crutch to hedge answers, and look to simply fit yourself into the opinions already held by the people interviewing you. I can’t stress enough how big of a red flag this is for interviewers.

Especially if you are looking for a more senior role, this comes across as an inability, or at least unwillingness, to share and defend opinions that you hold.

Instead, when answering questions, take a stance, defend it, and then ask how well it aligns with the thought processes of the interviewers.

Remember: We’re trying to understand how you think - don’t wait for us to give you the answer.

Explain the assumptions you’re making as you make them

This applies most to technical and architectural parts of the interview process. We absolutely do not expect you to figure everything out so perfectly that we need to go back and change code that we write. First of all, it’s an artificial scenario in which you’re working with code that you’ve seen for the very first time, likely in a context with which you have limited or no market or organizational knowledge.

That said, it matters more that we understand the decisions you’re making and why you’re making them. If you need to assume the shape of an API response, let us know that you’re doing that. Or if you are deciding to purposefully skip an edge case that you recognize, make sure to tell us, and even put a comment somewhere, that you are skipping it.

We don’t live inside your head, and we have seen the same problems solved many times over. There is no exact right answer, and even if there was, we do not want to see the same one over and over. Just as much as we are evaluating your technical skills, we are also looking to see the unique ways that you approach problem solving.

Simply put: show your work. Even if you’re wrong, it will go a long way.

Admit when you don’t know something

We can tell when you’re faking it. Always.

Research the things you don’t know between interview rounds

If you are stumped by something, it’s a terrific show of effort and interest to research the thing that stumped you. It comes up in the post-interview debrief.

Know what you’re looking for, and why you can’t find it where you are

Sometimes we run out of things to say on the interviewer side, which is why we so often lean on “So what are you looking for in a next role?” It’s a good probing question to find out just how much you have thought about your career trajectory, and how a role at a new company can align with that trajectory.

There aren’t always questions that you can prepare answers for, but this is one that you’re very likely to be asked. Have answers ready for both:

What you are looking for in a next role.
Why you can’t find it where you currently are.

It’s even more impressive here to share the story of steps you’ve taken toward your career goals internally, and how they perhaps ultimately didn’t work out. It shows that you are looking for new challenges and opportunities, and not just to leave your current job.

Dress up

I know, I know. You really shouldn’t need to, and most of the time your email for an onsite, or even an initial phone screen will come with a caveat along the lines of, “Our dress code here is very casual. We’re here to evaluate your skills, not your wardrobe - come in what makes you feel best!”

But here’s the thing: We’re lying.

You certainly won’t end up losing an opportunity because you showed up in shorts and a t-shirt, but there is absolutely an implicit nod to the slightest bit of additional effort you put in by wearing something that respects the process of showing your best self to a potential employer. It is a simple way to signal to your potential new colleagues and management team that you are willing to put in effort to stand out from a sea of people with similar skills.

These tips will not get you hired

Remember, you do still need to know your stuff. You are likely going to talk to multiple companies, and sit through rounds of technical and non-technical phone screens. If you feel like you skated through an interview by simply employing good interview technique, you should be incredibly concerned that the company you’re working for does not have high standards for vetting its team to begin with - you may end up peeking your head up in just a few months because you find yourself unsatisfied.

The tips shared here are to help you shine as a competent and engaged individual when you have already shown your technical expertise. Or, at worst, they can give you the cookie points to forgive a mistake here or there.