Like many engineers, I’ve been obsessed with computers and electronics for as long as I can remember. But it wasn’t until I began taking computer science electives in college that I realized software engineering might just be my professional calling.
Today I’m a director of product engineering at Greenhouse, a software company that helps businesses make better hiring decisions and onboard new employees more effectively. I still love writing code, but at this stage in my career, I spend most of my time managing 11 people split across three teams – strategizing technical changes, reviewing code, and recruiting and hiring new engineers.
Enter: The “technical interview” – a specific type of screening that a lot of engineering teams, including mine, use to assess a candidate’s technical skills. I didn’t know anything about technical interviews when I first started coding, which proved somewhat problematic. So, now that I’m on the other side of the table and conducting multiple technical interviews each week, I wanted to open source my learnings.
Some companies ask you to write code similar to what you would write on a day-to-day basis. Others focus on very abstract questions about data structures and algorithms with the intention of assessing aptitude. The latter touches on topics you would rarely encounter in day-to-day work, but solving these problems demonstrates a deeper understanding of the underlying concepts. Most interviews involve some combination of the two. My advice: Be prepared for both ends of the spectrum and do whatever background research you can — try looking through Glassdoor’s interview questions & answers section and asking any employees or former employees you share a connection with — into how this employer tends to conduct its interviews.
Practice, practice, practice. For the more abstract end of the interview spectrum, I recommend following the advice in this post . On the concrete end, it’s important to demonstrate that you can actually build software. Sometimes this means exercising muscles that you don’t regularly use. As a student, you probably focused on specific curriculums, but professional engineers spend most of their time doing a very distinct set of technical tasks. If you’re fresh out of school or your current work doesn’t involve building software, consider completing a few relevant side projects before you start interviewing. If you’re planning to interview for a job as a web application developer, for example, get your hands dirty by building real apps and familiarizing yourself with different web frameworks.
This is where you enlist friends and contacts in the industry. To diversify your practice rounds, pick people at different companies who are familiar with different interview processes. Whether it went terribly or wonderfully, I still gained valuable experience and got into the right headspace. This served me well when I entered the running for the jobs I was super jazzed about.
This one’s tough. You want to get across how invested you are, but at a certain point, stress becomes a saboteur. Practice helps. If you’re feeling shaky, try to land a few low-stakes – but real – interviews to start. I did this in my job search, knowing that if I crashed and burned, it wasn’t a huge deal. As an interviewer, I also want to see candidates who are humble, calm, and collected. Remember: All you can do is to do your best.
Many people think that being a good engineer requires nothing except technical ability. Not true. Engineering is very much a team sport with groups working together on a codebase. That’s why showing you have stellar communication skills and work well with others is often as important as wowing interviewers with your coding. I look for candidates who are able to clearly articulate their thinking around problem-solving and demonstrate “strong opinions, weakly held” – a balance of patience, humility, confidence, and conviction that helps me imagine them raising the overall caliber of my team.