Interviewing as a Software Developer in 2022
I applied to several different software developer positions this summer. At one point I was going through five interview processes simultaneously. It was a lot. But it did give me a lot of experience to compare side-by-side. I’d like to share some of what worked for me and a few things I think companies could improve to attract better employees.
Every process I went through had behavioral questions like “Tell me about a time when you had a conflict with a colleague and how you handled it.” These behavioral questions always feel like a trick, and it’s hard to remember a good story on the spot, at least for me. One company told me about the STAR method for answering these questions. I like that it provides a structure for answering questions which are otherwise difficult to answer honestly.
I also wrote down a bunch of examples beforehand knowing this type of question was going to come up. It helped me recall relevant stories more easily, and let me control the conversation. I could start with a negative (conflict with a colleague), transform it into problem solving (turns out it was miscommunication), and ultimately show how it ended in success (colleague and I understood each other’s goals better).
Asking Valuable Questions
There’s always a time when the interviewer asks “Do you have any questions for me?” The answer is: yes. You should always have some questions ready. Even if you’ve asked them all in other interviews, ask them again to someone new. You’ll either get the same answer which lets you confirm your findings, a different answer which gives you a more complete picture, or an opposing answer which can be revealing in its own way.
A good question also isn’t meant to answer the question at face value. For example if you suspect everyone works long hours, don’t ask that directly. Chances are you won’t get an honest answer. It’s also a “closed” question; it only asks for a “yes” or “no”. Instead, ask a question that reveals the information you’re looking for. I once asked a company in the social care industry:
Your work sounds like it has amazing social impact. I could see that impact also creating a high pressure environment. How do you ensure you continue to have that impact while working sustainably?
I got great info on “working hours” expectations, project cadence (how often crunch time rolls around), and how most the team feels relaxed at the start of each project and crunched at the end (likely due to poor project management). I never asked about those things directly but got them to reveal it. It helped identify some red flags which I confirmed in later calls.
Another example is checking for true cross-functional teams. A lot of companies say they have a cross-functional team when they really just have an over-worked designer who throws mockups over a wall. This leads me to my favorite question for developers:
What’s something you’ve learned from someone who is not a developer at
Companythat has changed the way you build software?
I love this because it forces them to give me a specific answer, it shows that there is a structure in place for other roles to contribute to the product, and it can give you a much better sense of the day-to-day job. It also shows them that you are thinking about collaboration, something that most companies really want from someone they hire.
Negotiation Is More Than Just Salary
To be clear, it is also about salary. If I get an offer, I always start the conversation with “Is that negotiable?” because it opens the conversation without being demanding or giving any specific number. But also keep in mind that you can really improve your quality of life by negotiating other benefits.
One thing I did during a negotiation is raised concerns about one of those IP agreements many companies make you sign that say they own everything you do while you work there. I pointed them toward alternatives that covered them legally and didn’t make me feel like I was going to get sued out of a side-project that has nothing to do with the company.
Other quality-of-life improvements might be more vacation days, access to a company benefit sooner than normal, or outside technical mentorship. It’s amazing what companies will do to get an employee, but they have to know what you want. You can help them by coming up with creative solutions.
What I Wish Was Different
Interviewing is hard work. Interviews add up to hours of time and even more time is spent considering, researching, and planning. Anyone with means can take time off to come to a virtual onsite, but that’s a recipe to get a bunch of affluent, mostly white, mostly male employees. I’d love to see companies make it more possible to get a diversity of talent by paying candidates. Especially ones that make it to a late or time consuming stage of the process, like a take-home interview.
Which brings me to something I wish companies didn’t do: take-home interviews. These are not particularly good at getting a sense of how people work, and they don’t respect a candidates personal time. It’s true that companies want their programmers to be self-sufficient, but coding alone does not measure that. Good, self-sufficient programmers work within time constraints. They prioritize in ways that don’t always create perfect code, but that’s what a take-home encourages. Instead, pair with them and see how they make decisions and solve problems first-hand. You won’t have them make something as full-featured, but that’s also kind of the point. What do they cut for time? How do they get unstuck? There are absolutely trade-offs to this, but I believe it’s a better way to measure a broad range of skills than sending someone off alone.
Finally, I want technical challenges to be more representative of the job. Algorithmic challenges are good if you’re hiring someone to write algorithms, but most programming jobs aren’t. Companies would get a much better sense of programmer skills by watching a candidate model data, write commit messages, and chose what to test. And if Big O notation is that important to you, have candidates fix a realistic performance bug.
We’re All Human
Luckily, almost everyone was kind and understanding of schedule changes, or redoing an answer, or listening to me ramble a little. In a way, those upsets are part of the interview on both sides. Life happens, so how does everyone handle it? The good news is that most people get it and I had lots of good experiences. If you’re about to look for a job take care of yourself, and know there is a great team out there waiting for you.