Preparing for technical interviews can feel overwhelming! There’s so much to learn and keep in mind. I’m helping a friend prepare for technical interviews by running mock interviews with them and offering feedback. I wanted to share some feedback and guidance those interviews

The Interviewer’s Responsibility

As an interviewer, it’s on me to create a comfortable and collaborative environment that helps you to perform your best. It can be difficult and stressful to interview! I want to leave candidates with a positive feeling about the company I represent, even if it doesn’t work out.

Sample Agenda

When I lead interviews (mock or no), I like to start by offering an agenda for the interview. Here’s what I like to cover:

  1. Brief introductions
  2. Behavioral and situational questions: Exploring scenarios to evaluate behavioral skills.
  3. Technical questions: Delving into system design / coding.
  4. Candidate questions: Giving the candidate an opportunity to interview me.

I’ll offer some advice for each of these areas.

Brief Introductions

Be brief and offer the interviewer the chance to ask more if they’re interested. In about 30 to 60 seconds, aim to cover your name, position, career summary, and relevant background.

Here’s my sample introduction as an interviewer:

My name is Kevin London. I’m a Software Engineer at Snapchat on the A/B team. We build tools for internal teams to determine whether customers enjoy changes before we launch them more broadly. I’ve worked as a software engineer for about ten years at companies including startups and Amazon before joining Snap.

You want to give the interviewer enough to get a picture of you and your background if they haven’t had a chance to review your resume. It’s an opportunity to give context for the stories you may offer in the coming behavioral interview questions.

Practice your introduction with a friend or two to check if you’re providing enough context about yourself without going too long.

Behavioral Questions


When you’re preparing for behavioral interviews, practice the STAR format. Interviewers want to know about your actions and the results, since those show the areas that are most under your control.

Company Values

Research the company’s values and craft a story for each one. These stories should show how you demonstrate the company’s values through your actions. I prefer writing on paper for this part, though typing is probably fine too.

If you don’t feel like the story strongly illustrates your values, consider finding another one or seeing if there’s an area or action that you overlooked that would be helpful.

Narrative Structure

As humans, we’re wired to be more interested by and engaged in stories. If you can, frame anecdotes as a story using common narrative structures such as the Hero’s Journey.

In this structure, the hero is faced with a big obstacle that upends their day-to-day. They fight against the odds and may have an “all is lost” moment. Then, at the end, they emerge victorious, having solved the problem.

This structure helps keep interviewers engaged and puts an emphasis on your actions and what value you would bring to the company.

Phoenix Stories

Even if a story reflects a challenging experience, remember to showcase your resilience and growth. Consider how you recovered from failure and emphasize the positive outcomes or lessons learned.

Phoenix art

A phoenix is a mythological bird that dies and is reborn from its ashes. Think of these stories as your personal “phoenix stories” that demonstrate transformation and growth.

Be Specific

If an interviewer asks you a broad question like “How do you handle conflict?”, offer a specific example rather than a general one.

For example, here is a broad answer:

I try to avoid conflict with coworkers by building alignment and listening to their concerns. I like to understand what they’re thinking and collaborate with them.

And here is a fictional specific answer:

I like to make sure we understand each other’s viewpoint when there’s conflict.

For example, I led a design to build a new thumbnail generation system at a previous company. I wrote a design document for it and presented it to the team. One teammate asked questions about how it would scale and questioned the overall approach in the document. I offered to follow-up with them offline and scheduled a 1:1.

When we discussed, they pointed out a few areas where the service could have trouble, such as if we had a batch upload or if one of our dependencies went down. I thanked them and incorporated their feedback in the design. They had some concerns about the architecture as well, so I walked them through the decision-making process and how I arrived at that conclusion. At the end, they agreed with the overall approach and we decided to move forward.

I built out the service, and I’m grateful they identified the scaling gap. We were able to handle a huge batch of images uploaded before a major sales event and the new thumbnailing system worked without issue.

In the first example, as an interviewer, I get limited feedback about how this person handles conflict. I understand how they like to handle conflict but not necessarily what they do. The second gives me a clearer picture, as well as what specific actions the candidate took to resolve the conflict.

Favor “I” over “We”

If you worked on a team project, identify your individual contributions. Specify whether you led the project or if you made significant decisions. As an interviewer, it can be hard to tell what your contributions were if it was part of a group experience.

Technical Interviews

  1. Ask clarifying questions before you start. Make sure you understand the problem’s scope and intent before diving in.
  2. Express your plan for solving the problem before you start writing code.
  3. When you’re stuck, start thinking about how you’d solve the problem manually using the example.
  4. If the editor has a run function, don’t click run until you’ve gone through an example and checked that the code should do what you want. Be a human computer.

Know Your Language

Practice and familiarize yourself with your chosen programming language. While you don’t need to memorize every detail, get comfortable with fundamental programming concepts, syntax, and common data structures.

As an interviewer, I don’t expect a candidate to have memorized the syntax for obscure data structures (such as Python’s heapq module), though I would expect them to be comfortable writing loops, control statements, variables, etc.


I’ll only offer hints if we’ve been stuck in one part of the exercise for a while.

Pause and consider what the interviewer might be trying to tell you. If a candidate ignores hints and continues on their existing path, that can be a concern for interviewers. Likewise, if a candidate requires more hints than normal, that could be a concern as well.

Do Mocks!

Ask a friend to do mock interviews with you. I’ve used Pramp to do mock interviews as a free option.

Once you’re done with the interview, if you’re the candidate, think about what you could do better and offer this to see if you’re aligned with the mock interviewer.

Closing Thoughts

Clearing technical interviews requires a combination of preparation, practice, and effective storytelling. By following the strategies in this post, I hope you’ll increase your chances of success.

If you’d like to read more posts about interviewing, I wrote How to Land the Right Tech Job for You and, more recently, Senior Engineer Job Search Preparation.

Good luck!