Discover more from Society's Backend
I Enjoy Technical Interviews and You Can Too
A simple change in mindset that completely changed the way I interview
To add context for non-software engineers, technical interviews are a special type of interview designed to showcase a software developer’s abilities. Instead of being asked general questions about work experience, technical interviews are more like an oral exam in coding, math, logic, and problem solving. For example, an interview question might be:
“Design a direct messaging app.”
“Write a program that finds the fastest path through a given maze.”
“Given a location and a destination, traverse a flight charter and find the path for the shortest distance, lowest number of flights, and lowest costs of flights to get from the location to the destination.”
Engineers are given about 30 minutes to come up with a solution, write the code for it, and explain why that solution was chosen. Each job application generally requires 4-7 of these interviews and most end with rejection. If it sounds exhausting, that’s because it is. There’s a reason technical interviews are almost universally hated.
I dealt with this as I had interview after interview while applying for internships during college. I had two babies to care for, four jobs to work, classes to study for, and I was spending most of my time preparing for interviews. It was so overwhelming, I stopped caring. To be quite frank, I went into each interview without a care about the outcome; but by doing so, I accidentally cracked the secret to succeeding at them. My nonchalant approach caused me to treat the interviews less like interviews and more like conversations.
How to Enjoy Technical Interviews
Since then, I’ve come to enjoy technical interviews and subsequently I’ve gotten a lot better at them. Here are the strategies I employ to make interviews easier:
Think of interviews as a conversation. If you remove the pressure of evaluation from an interview, it becomes just a conversation between two engineers. Every engineer I know loves to talk about the software they’re building. Think about an interview as designing software and chatting about it. Once you think about interviewing this way, it becomes much easier to enjoy the process and communicate clearly.
Engineers have to be people too. As a whole, software engineers aren’t known for their people skills. Many of us get along better with computers than we do with people. This should be used to your advantage in an interview. Companies will always take a smart person who shows they’re pleasant to work with over a super genius who shows they aren’t. Companies understand they can’t teach things like user empathy, communication skills, and friendliness as easily as they can teach technical skills. Just focusing on being pleasant in an interview will greatly increase your chances of passing.
Prepare more than just your technical skills. Leetcode is often the blocker for engineers that get rejected frequently—not because they don’t prepare enough for technical questions—but because they prepare for them too much. Spend time developing your communication skills and know your resume like the back of your hand. You should be able to pinpoint times when you were collaborative, thought critically, and solved difficult problems. It’s always great to solve coding questions quickly, but you need to show you can succeed at other parts of the job.
Be excited to be there. There’s nothing worse than spending time with someone who clearly doesn’t want to be spending time with you. Even if the company isn’t your first choice, find some part of the job to be excited about and show it in the interview. This is a super easy way to make a great impression and set yourself apart.
Some Interview Misconceptions
Along with the above strategies, I think it’s important to understand that you’ll never get better at technical interviews if you incessantly complain about them. When you believe they aren’t fair or are stacked against you, you’re causing that to be true. These are a few common complaints about technical interviews that are holding engineers back:
Technical interviews aren’t indicative of what we do on the job. As mentioned above, a technical interview is just designing some software and talking about it. This is the job of a software engineer. It’s just a packaged version of the job that can be completed in one 30-minute session.
Technical interviews take too long. 30 to 45 minutes already feels like too short of a time frame to answer a question. We could lessen the number of interviews a candidate goes through, but it would be tough to evaluate candidate ability while also ensuring a fair interview process. The length of technical interviews is an unfortunate reality. Just remember that everyone has to go through the same process.
Technical interviews test my memorization when I would just use Google on the job. It isn’t unreasonable to expect a software engineer to memorize the basics of data structures, algorithms, and their chosen language. You’ll likely spend your time on the job Googling more complex things. The basics should already come to you automatically.
Technical interviews require too much preparation. One thing I’ve learned at Google and Microsoft is the sheer amount of resources companies put into placing the right person in the right job. While we may spend a lot of time preparing for interviews, companies spend a ton more because people placement is integral to their success. The truth is: Time spent preparing is up to you but you should expect to be outperformed by others who are more prepared. You’re never forced to spend time preparing, but it does help your cause.
Let me know if you agree with my points. I’d love to hear feedback both from the interviewing and interviewee side. The engineering community spends too much time complaining about technical interviews and too little time focusing on what they can do to make them better.
Connect with me
Support me for pennies
100 of them to be exact. Support independent writing and let me know you enjoy my articles for just $1 a month.