profile

ESPRESSO FRIDAYS

Eight engineering questions to ask and answer in interviews

Published about 1 month ago • 3 min read

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

Hi Friends, Today, we’re diving into the often under-appreciated git blame. Often used to find out who last modified a line of code, git blame has several powerful features. Let’s explore some of these hidden gems, particularly focusing on the flags: -w -C -C -C -C -C -C blame -C -C -C ignores code movements across the entire history Ignoring Whitespace with the -w Flag Do you know the annoying blame results showing over an indent or a space removed / added? "-w" fixes that! git blame -w...

5 days ago • 1 min read

Hi friends, This is the story of how one mysterious hacker, took advantage of an inactive negligible library in Linux, and the maintainers emotional stress. Slowly, week after week, bit by bit lines of seemingly random testing code were added, in front of everyone’s eyes, to the Linux upstream. Thanks to one curious developer, who had an itch because of a tiny lag in his login process, sending him deep into the rabbit hole of Linux SSH and the mystic world of ZX, we would have never heard of...

12 days ago • 6 min read

Hi friends, You know how companies use merge commits when working on projects? Just go to one of your work projects and checkout the history of the main branch. It may look tidy (or not) but it’s bad for the environment (the real-world one 😉) Lots of merge commits While that’s pretty standard, it actually makes things messy. Every time we do this, it stops us from keeping our commit history nice and clean all the way through from development to production. Here’s why that’s a bit of a...

19 days ago • 2 min read
Share this post