Eight engineering questions to ask and answer in interviews


Hi friends,

For eight years, I’ve been interviewing engineers for different positions.

I compiled a list of questions I think every engineer, especially the experienced ones, should be able to answer pretty easily.

Here is the list, with each question followed by what I expect:

  1. System Architecture
    This can be a generic “here’s our product, describe the architecture” type of question. But what I like to do, is use it as a followup to them describing the last place they worked at. If they can describe the system, it means a lot. I’d also usually add a “How would you improve it?” to learn more.
  2. How do you perform deployment in your system without downtime, how do you perform a rollback, what would prevent you from performing a rollback?

    Here’s what I expect to learn:
    - If this is a developer, did they build their application to sustain failures? - If an ops engineer, did they build a system in place to support automated rollbacks?

    - If a rollback was made, how do they deal with the lack of coherence with their source of truth (usually the main git branch)
  3. Why is it possible to do scaling, why is it hard. What metrics do you check to ensure that scaling happened and it’s not a trivial bug?

    This is my favorite question. All engineers are expected to know how scaling effects their application / system. What allows it, what prevents it, and how do you scale smart (up, down, inside and out!)
  4. Are you event-driven? Do you have a DLQ (Dead Letter Queue), what happens when there is a bug? Do you reprocess the DLQ? If so, how does it affect the new events?

    I’d expect to hear about the events in the system and why this is important to them. How do they deal with a DLQ in a sustainable way (manual reprocessing is usually a red flag I’d want to dig into!).
  5. What non-trivial issue have you encountered recently, and how did you work to solve it?

    Before even going down the complexities of the bug itself, I’d like to learn about their process of debugging. What is the debugging environment looks like? Is there one? Did they use bisect at all? Every developer has to debug, a lot. They’re process is one of the best ways to learn their skill level and methods of work.
  6. Are you DB (Database) driven? What indexes did you put on the tables, and why? How did you decide on them?

    Understanding database practices is crucial. Unfortunately, most second-level managers (group leaders and above) I have met were unable to engage in a satisfactory discussion about this topic. Knowing the data structures, schemas, and indexing approaches indicates that they have seriously considered how to handle data and construct applications accordingly
  7. How do you check the security of your system? What do you insist on there? Why?

    This can go in infinite ways. I like to start from application security; basic SQL injection vulnerabilities, how they work and how to protect the app with code only. Then add system layers and other solutions. I’d also ask about IDOR’s (indirect object reference) and broken access control (first on OWASP top 10 this year!).

    - Are you an interviewer? Just pick one from OWASP top 10 and dive in.
    - Interviewee? Know the list, and know how to have a conversation around most vulnerabilities.
  8. What were your performance issues? After solving them, are there still any in the area?

    This is a great “DevOps” question, but I even like it better when interviewing backend engineers. It means so much when a dev can speak about performance of their application, how the systems around it support or degrade performance and, how they monitor it effectively.

I love these questions because each can be developed to a 60 minute conversation.

When discussing with seniors, not only it’s fun to cover, but I also get to learn a lot, and to feel their skill level.

Based on the position I’d usually emphasize a subset of these, hopefully the “non-comfort-zone” ones.

Please let me know if you feel different, have questions or comments, just reply directly here!


Whenever you’re ready, here’s how I can help you:

- Building a Second Brain with Neovim in Under 90 Minutes: My first course, discussing the basics of building a second brain using the PARA and CODE methods, combined with Obsidian and Neovim as an editor. Join 200+ enrolled students here

ESPRESSO FRIDAYS

Every once in a while I send hand picked things I've learned. Kind of like your filter to the tech internet. No spam, I promise!

Read more from ESPRESSO FRIDAYS

Thank you to our sponsors who keep this newsletter free to the reader: Aikido is your no-nonsense DevSecOps platform. One central system that shows you what matters and how to fix it, from code to cloud. So you can get back to building. Try Aikido today! We’ve all been there – that heart-stopping moment when you realize you’ve accidentally exposed sensitive information. Today, I’m sharing a personal story and introducing a tool that could save you from a similar nightmare. The Nightmare...

Hi friends! Today we’re diving deep into improving your terminal history management. Exploring techniques that can transform your command line experience from frustrating to fluid. Whether you’re a CLI novice or a terminal titan, these methods will boost your productivity and smoothen your workflow. To do that, we’ll explore three levels of terminal command management, from basic to advanced. Not actually running on my phone 😅 1. Basic: Built-in (mostly unused) tooling: Even without...

Hi friends, Tmux is a fantastic tool for managing terminal sessions, but it has its limitations. One major drawback is the lack of a floating pane feature, which can make navigating between different panes cumbersome and inefficient. Me frustrated with Tmux lack of floating panes while Zellij is killing it... Most users workaround this by creating new Tmux windows or panes, or by using hidden splits to zoom in and out. These methods work but can be inefficient and require many keystrokes,...