Anatomy of Julie's Job Search: Preparing for interviews
This post is part of a series. See the introduction for additional context and disclaimers.
In addition to the general preparation I wrote about earlier, I usually spend a good amount of time preparing for interviews.
Table of contents
My process
Interviewing for software engineering roles is a skill unto itself. I am sure there are people who come to it naturally and need no preparation, but I am not one of those people. You probably aren't either. I rarely exercise some of these skills in my day-to-day job, so I have to practice to warm up my brain. When it comes to real interviews, this helps me identify a pattern, tell my brain "I know this," and focus more on solving the problem at hand than spiraling into anxiety doom.
Below are some examples of the kinds of interviews I often see, and how I attempt to prepare for them (or not).
Discussion interviews
This is my catch-all for conversational interviews that do not fall into a more specific category. They often come up in early interviews with recruiters and hiring managers and later interviews with engineering partners (e.g. designers, product managers, support).
Between years of public speaking and roles that require significant communication, this is one of the areas where I need less practice. The primary preparation here is knowing the story I want to tell about myself and what I am looking for in a job right now. Thankfully, I did a lot of that preparation in the reflecting step of my process.
For a specific interview, I will usually refresh my memory about the company, the role, and the person I will be talking to. This helps me communicate well for my specific audience, talk about why I am interested in the role, and ask thoughtful questions.
Behavioral interviews
Behavioral interviews ask questions based on past experiences to theoretically determine the likelihood of future behavior. The idea is that people are more honest and realistic when talking about real, lived experiences than when discussing hypotheticals. I dislike hypotheticals, so it works for me.
Similar to discussion interviews, I do not need a ton of practice for these. However, there are a few common questions that can be tricky to answer well extemporaneously, so I will often think a little about them ahead of time. I do not memorize answers, but I think about some stories I may want to tell to make a good impression.
Examples include:
- Tell me about a time you had a conflict with someone and how you handled it.
- Tell me about a time you had to work through a challenge.
- Describe a time when you had to influence others and how you approached it.
- What are your strengths? Weaknesses? Tell me about how they have impacted your work.
System design interviews
System design interviews involve talking through the design of a technical system. They often include a mix of verbal discussion and some light notes or diagrams to visualize the system.
One variation of the system design interview is to talk about a system you worked on. I like this version of the interview because it is grounded in real work I did on a real system where I had time to think through the problem collaboratively with my coworkers. Similar to the behavioral interviews, I prepare by thinking about a story I want to tell. I will often practice talking through the system using the tools I would use in an interview (e.g. I like draw.io for diagramming remotely) to get comfortable ahead of time.
The other variation of the system design interview is to work through design of a system on the fly based on a prompt from the interviewer. These can range from a pleasant collaboration on a problem in your area of expertise to a hellish ordeal where you try to guess at the right solutions to arcane problems while a stranger silently judges you. Usually they fall somewhere in the middle. Sometimes I will find a practice problem online to work through, but I don't spend much time here because I get practice with system design on the job.
Technical quiz interviews
Some companies will ask you a set of technical questions with the expectation that you will be able to answer them quickly from memory. These can range from mildly annoying to interviewing malpractice. I do not think they are a particularly good source of signal for interviewing as either a candidate or an interviewer.
At their best, these questions focus on topics I should be able to speak about from memory in my day-to-day job. At their worst, they focus on trivia, edge cases, or other minutiae that many engineers (myself included) do not waste time memorizing when the internet is right there.
At their best, these interviews are given by people familiar with the subject matter, so they can clarify the intent of the question and understand nuances in answers. At their worst, they are given by people who have little-to-no familiarity with the technical context of the questions and can only accept answers written down for them ahead of time.
I do a little prep work for these by googling for lists of "frontend interview questions" and running through a few of them to see how I fare. The outcomes are usually a mix of questions that:
- I understand and can competently answer right away.
- I understand, but am not great at communicating to others. I may do a little work practicing answers to these.
- I understand and can explain competently after a tiny bit of googling because I forgot the fancy technical term. I may do a little practice trying to remember the terminology.
- I do not understand and have to google to find the answer. If this is an area where I've fallen behind on something relevant, I'll take the time to catch up. Some are niche questions I'll choose to ignore.
- I understand, but do not know the answer off the top of my head and think it's bullshit I'd be expected to. If asked these in an interview, I would respond with something like "I'd look it up at <trusted resource>" or "I'd type it into the console to see what happens."
Coding interviews
My area of specialization (frontend web) changes constantly, so I usually start preparing for coding interviews by catching up on the latest and greatest in case I missed anything important. This usually involves skimming through the backlog of tech newsletters in my email archive, collecting a list of topics, and then digging into them.
My preferred form of coding interview involves pairing on the implementation of a simple (for the sake of time) UI using React (my framework of choice) using my personal setup because this is a good approximation of the kind of work I am being hired for. I usually practice for this sort of interview by doing a timeboxed implementation of a common UI (e.g. a todo list) while speaking aloud about what I am doing.
Coding interviews sometimes focus more on general programming and algorithms using JavaScript (my language of choice). I will often practice a handful of easy-to-medium LeetCode questions to get familiar with these. If I'm feeling festive, I'll practice with Advent of Code questions from the early weeks before things get really tricky.
I don't spend a ton of time here because I code regularly at work and have been programming for decades. The practice is mostly to work on being comfortable coding while under the artificial pressure of an interview. For interviews that need practice for the technical part, see the next section.
Technical interviews unrelated to my work
"Unrelated to my work" is my nice way of referring to the type of interviews made popular by very large, well-paying tech companies that usually involve regurgitating undergraduate computer science curricula from memory onto a whiteboard. I took those classes to get my computer engineering degree, but use very little of it in my day-to-day job, so my brain does not keep it in active memory.
I think that these types of interviews are time consuming, stressful, gatekeeping bullshit for the majority of software engineering roles. It feels like hazing at this point. We suffered through it, so the people after us have to suffer too. Just because I can pass these interviews (with significant time and effort) does not mean that I should have to. My willing participation in them encourages companies to keep giving them, so I will do my best to decline interviews that require them at this point in my career.
In my 15+ years of working as a software engineer, I have never needed to implement mergesort from memory to solve a problem on the job, but I was required to do so to be hired at Google. I was much earlier in my career and had significantly less options at the time. Working at Google taught me a lot and opened a lot of doors, so I do understand why people are willing to slog through these interviews. If you are one of those people, below is some circa 2012 advice based on my experience:
- You likely need CS fundamentals like data structures and algorithms to pass these interviews. If you learned them already, you probably need a refresher. If they are new to you, you need significantly more time to learn and practice them.
- If you are not fresh out of studying algorithms or do not use them in your day-to-day job, you will probably need to study. I made flashcards and practiced implementing common algorithms from memory.
- Most people need to practice to get good at these interviews. Plan accordingly. I practiced a bunch using the book Cracking the Coding Interview. These days, a lot of people practice exercises using LeetCode — so much so that they're often referred to as "leetcode questions."
- Practice in the medium you will use in the interview (or an approximation). For example, I worked with pencil and paper to approximate a whiteboard.
- Practice solving problems without looking anything up. These usually aren't "open book" interviews.
- Practice talking aloud, asking questions, and describing your thought process while you solve problems.
- If possible, get a buddy to do mock interviews with you and give you feedback.
- Get comfortable with failure. These interviews tend to have a high false negative rate.
Personality tests, puzzles, riddles, and other nonsense
I do not prepare for these. I am frustrated that companies still ask them. They do not in any way select for high quality software engineers. I am seriously considering ending the interview if I get asked one this time around because it is a waste of my time and a sign the company is probably not a good fit for me.
Why it works for me
The scale of the public job search and having an in demand background means I can be a little picky. I can bail on companies doing certain kinds of interviews because I know I have other options. People who are only interviewing with a couple companies at a time, are earlier in their careers, or otherwise have less options are less able to pick and choose. Part of the reason I want to stop participating in these interviews is to discourage companies from giving them, so that hopefully nobody has to go through them in the future.
I am not trying to get a job at a FAANG company, so I can skip studying algorithms and grinding leetcode. I have done those things in the past, so I have some historical practice I can lean on if I get questions on the easier end of things. Having a traditional computer science background also helps with some kinds of interviews.
I am comfortable with the verbal communication needed for many interviews, so I do not spend a lot of time practicing that part. This was not always the case. I spent decades of work on public speaking and professional development to get to the point where this is easier for me.
Takeaways for job searchers
Interviewing for a software engineering job truly is an exercise in sadness. Many parts of the interview process bear only a passing resemblance to the work you do at your job. Interviewing is, in many ways, a separate skill you have to build in your own time. This is bullshit, but you need a job, just like I do. I'm sorry.
Given limited time and energy, you cannot practice every piece of interviewing forever until you are perfect at it. I focus my practice on the intersection of interviews I am likely to get and areas where I struggle. If you are planning to interview at a FAANG-style company that does really difficult algorithms interviews, I recommend giving yourself significant extra time to prepare.
Be wary of people selling you the "one true way" or "this one weird trick" for being awesome at interviewing. They sometimes include some useful advice, but they do not know you and your situation. For example, you do not need to leetcode hard algorithms problems until you bleed from the eyes unless you are trying to work at a very specific set of companies.
Takeaways for employers
General takeaways
Your interview process should focus on evaluating the skills and behaviors you expect a candidate to use in their day-to-day job. Interviews that test other things will lead to losing out on potentially great candidates for dubious reasons. The interview process is already stressful and time-consuming enough. Why are you making it unnecessarily worse?
Takeaways for people who want to hire me
Please be up front about what your interview process entails, so I can evaluate if it is worth my time and yours. I am disinclined to participate in interviews that are completely divorced from the work you are hiring me to do (e.g. leetcode-style hard algorithms, coding on a whiteboard, riddles).