For context, I work in a BU responsible for two B2B SaaS products, built on a large monorepo of 100+ production services, ~10,000 Python files, and tens of thousands lines of code. All maintained by a group of 50-ish engineers!

My team maintains ~20% of these services, so we’ve invested a lot of time and energy in building tools and processes that allow us to ship new features while guaranteeing security and reliability to our customers.

In this post, I’ll share an AI workflow I designed for managing my team’s tech debt.

Tech debt at scale

We ran into friction with our dev velocity when shipping new features. Partly because some legacy systems weren’t designed to support new use cases or had an implementation that made sense at the time but later became an unavoidable bug. These are past pragmatic decisions for solving problems, which I do support.

However, stashing-small-todos-under-the-rug becomes a real pain point over time, especially when organisations want to move from startup stage to a large tech company.

So I started the conversation about code quality internally, and later expanded to wider engineering. I’ll cover more about code quality in next post. For now, I’ll focus on how we moved the needle with automated tech debt management.

If you’re interested to learn more on leading successful initiatives, check out below:

How we’re managing tech debt

Our tech debt generally comes from feature development and migration projects. We manage this on a dedicated kanban board, separate from our main board.

We review this board fortnightly and allocate every other Friday to work through tech debt in priority order. We gamify this work among the team and recognise the engineer who fixed the most tech debt, aka “The Fixer 🛠️”.

We used to curate this board manually by running a one-off script to create JIRA tickets (or even worse, on the UI). Other times we nudged people to write a ticket based on a TODO they found.

It took us time and bandwidth to actively update and review the board. Instead, we recognised that automating these repeatable steps can be handed over to an AI agent, which we did with Windsurf’s Cascade.

We defined a set of rules on the monorepo with MCP integration with Atlassian and GitHub. After that, we set up a Cascade Workflow that scans over selected services, finds any tech debt, and writes a detailed ticket to the board with proposed solution. I use Claude models (Sonnet and Opus) to run these workflows so it can analyse the complexity of the found tech debt and categorise it accordingly.

• If it’s low-hanging fruit, an agent knocks it out with a PR.

• If it requires deeper change, it goes on the board for an engineer to look into.

Benefits are:

1. We delegate the tech debt board management to an agent.

2. We make it easier to surface tech debt that requires an engineering input.

3. We delegate squashing small tech debts to an agent.

Below is a screenshot of an agent adding tech debt tickets to our kanban board.

This is one instance of how we’re using AI tooling. We’re still integrating more with AI tools to automate most of our repeatable tasks. Code quality is definitely an opportunity worth capitalising on.

See the markdown template below for an AI workflow for creating tech debt tickets.

Subscribe now

Workflow template

Use this as a starting point and refine to your standards and tools.

# AI Workflow: Create Tech Debt Ticket from TODO

> Compatible with Claude Code, Cursor, Windsurf (Cascade), and any AI assistant that supports tool use / MCP.

---

## Usage

```
/create-tech-debt-ticket <file_path>
/create-tech-debt-ticket <file_path> "TODO: specific text"
```

---

## Steps

### 1. Identify the TODO

- If a specific TODO is provided, use it directly
- Otherwise, scan the file for all `TODO` / `FIXME` markers and list them
- If multiple are found, ask the user to pick one
- Extract the TODO line and 5 lines of surrounding context

### 2. Check for duplicates

Before creating anything, search your issue tracker for existing tickets that reference the same file or TODO text. Show any matches to the user and ask whether to proceed.

> **Why this matters**: skipping this step turns a helpful workflow into a ticket spam machine.

### 3. Generate the ticket summary

Use a consistent format so tickets are scannable in the backlog:

```
[module.path] <TODO description>
```

Example: a TODO in `src/payments/utils.py` → `[src.payments] Refactor retry logic`

### 4. Generate the ticket description

Use a structured template so every ticket has the same quality bar:

```markdown
## Problem

<What is the tech debt? Why does it matter?>

## Location

- **File**: `<file path>`
- **Line**: <line number>
- **Code context**:

<5 lines before the TODO, the TODO line, 5 lines after>

## Proposed solution

<Suggest an approach based on the TODO and surrounding code. If unclear, write "To be determined during implementation.">

## Acceptance criteria

- [ ] TODO marker removed
- [ ] Solution implemented and reviewed
- [ ] Tests added or updated
- [ ] Linting and type checks pass
- [ ] PR merged and deployed
- [ ] No regressions in monitoring
```

### 5. Create the ticket

Use your issue tracker's API or MCP integration to create the ticket with:

| Field | Value |
|---|---|
| Project | Your team's project |
| Issue type | Task |
| Labels | `tech-debt` (or your team's equivalent) |
| Parent | Your tech debt epic |
| Description | Output from Step 4 |

### 6. Confirm with the user

Show the created ticket URL and summary. Remind the user which board/backlog it landed in.

---

## Adapting this workflow

| Tool | How to use this |
|---|---|
| **Claude Code** | Save as `.claude/commands/create-tech-debt-ticket.md`, invoke with `/create-tech-debt-ticket` |
| **Windsurf (Cascade)** | Save as `.windsurf/workflows/create-tech-debt-ticket.md`, invoke with `/create-tech-debt-ticket` |
| **Cursor** | Save as `.cursor/rules/create-tech-debt-ticket.mdc` and trigger via chat |
| **Any AI assistant** | Paste the steps above as a prompt with your file content |

For issue tracker integration (JIRA, Linear, GitHub Issues), connect via MCP or your tool's native plugin.

Intro

An initiative at its core is an opportunity to make something better collectively.

It could be a technical challenge like leading an application redesign, infrastructure migration, or new in-house tooling.

It could be a non-technical challenge like people management, handling customer support, improving cross-team communication, or starting a new product discovery.

A strong engineering team is one that recognises that projects and initiatives can come from either leadership (top-down) or engineers themselves (bottom-up).

Not only does leading initiatives demonstrate ownership, it also shows that engineers genuinely care about (1) the product, (2) the business, and (3) their tools. Focusing on tools alone can be a trap.

For leading initiatives successfully, there are five phases you should be aware of.

Initiative Lifecycle

(1) Identify a problem

Every initiative comes with a cost: engineering, time, and money. To justify the spending, there should be a clear problem statement you can communicate to others on what exactly you’re trying to solve.

The problem could be developer tooling, an architecture bottleneck, a cost savings problem, routing customer requests, etc.

A tangible problem that you can experience yourself will make it easier to understand the crux of the problem and the benefit of solving the problem. From there you can brainstorm possible solutions that you can propose before an initiative kick-off.

(2) Propose solution to a small group

Once you have the problem documented, it’s good to start the conversation with a viable solution that reviewers should consider.

Going into a meeting with a problem and a fix is better than nothing:

• ❌ Here’s a problem

• ✅ Here’s a problem and a candidate solution

This could be a 1-1 or a small meeting with close stakeholders like tech leads, managers, directors, or VPs.

The goal is to highlight a problem that impacts a valuable metric (customer success or developer experience) and propose a well-thought-out solution as a starting point. It could pivot to another solution, that’s fine. The goal is to not mandate a solution but to eliminate the problem with the best solution.

Depending on the scope and/or your organisation, you might need an additional “hop” to get buy-in for the initiative. If it requires support or involvement from a wider group (e.g., engineering org, backend guild, or platform team), it is important to go through that first before starting the initiative. You don’t want people to shoot down your solution mid-execution.

That’s where the flow is highlighted in the diagram: 1 → 2.a → 2.b → 3 → 4 → 5

(3) Define Strategy

Richard Rumelt defined a good strategy by its “kernel” in his book Good Strategy Bad Strategy. The kernel of a strategy contains three elements:

1. Diagnosis (the why)

2. Guiding policy (the what)

3. Coherent actions (the how)

He explained the “good strategy” neatly with a medical analogy:

1. Diagnosis: name the disease or pathology

2. Guiding policy: therapeutic approach decided by the doctor

3. Coherent actions: prescriptions for diet, therapy and medication

The same applies to driving initiatives. Write the diagnosis as a problem statement in a document (i.e., why this initiative exists), followed by the guiding policy (what we aim to achieve), and then a set of actions/tasks to be carried out throughout the initiative.

My favourite quote from his book summarises what makes an initiative successful:

Subscribe now

(4) Execute

At this stage, it is clear what we’re doing, why we’re doing it, and roughly when we should finish. The focus here is on leveraging engineering skills for execution.

Every engineer involved should be focused on execution. You as the initiative leader, should be able to provide support when needed. If there is a repeatable pattern or knowledge to share, it’s more efficient to write it in a shareable document rather than re-explaining the method to every individual.

During execution, your participants should not be distracted as much as possible. You have the duty to protect their deep focus time (if possible) and make sure everyone is in-sync. This could be translated into daily, weekly, or bi-weekly catchups. It depends on the scope of the initiative.

The key thing here is efficiency. If setbacks happen, mitigate the risks, and discuss what happened after you finish execution.

(5) Retro and Celebrate

Once the work is done, take this opportunity to retrospect with your engineers and discuss the following:

1. What went well? What we should keep doing in future initiatives

2. What didn’t go well? What were the hiccups and why did it happen

3. What we learned? What lessons can we take away and apply next time

Retros help capitalise the value from a long-running initiative (days, weeks, or months) and allow engineers to share insights they might not have had time to share. This is an important meeting because it reinforces collaboration and inclusion. As a general rule, anyone who pitched in should have the opportunity to speak openly.

Celebrate and recognise the efforts of everyone involved. They will appreciate investing time and effort in your initiative. Even better, they might be inspired to start their own initiatives and introduce innovative solutions. This is an example of being a force multiplier.

Wrap up

Driving initiatives is an important skill for an engineer. It requires time, practice, and patience. I encourage all engineers to practice as early and as often as they can. It is a great return-on-investment later in their careers.

To wrap up, here are final tips on leading a successful initiative:

1. Explain the crux of the problem

Explain briefly why people should care about this problem. What’s the value of solving the problem? If you can present some quantitative metrics and highlight how “painful” the problem is, the more likely the team will buy into your initiative.

2. Don’t mandate a solution upfront

The goal is not to enforce a specific answer. It is to introduce the problem statement, why it is important to solve, and a candidate solution to discuss. This changes the narrative from (raise a problem with no solution) to (here’s a problem and a solution, what are your thoughts?).

The solution with the most “votes” is likely the one that the team is happy to support.

3. Document and ask for feedback

One sign of a strong engineering culture is where teams follow a document-driven approach for exchanging ideas. When discussing requirements or proposals, it’s best to articulate your thoughts and present your research in writing. This will allow reviewers to not miss any critical detail and be able to challenge any assumptions.

4. Choose the right timing

If the team’s bandwidth is already used for other projects and the initiative isn’t time-critical, it’d be better to park it for now and resurface when the time is right. People should trust your judgement on when a problem is worth solving.

If you enjoyed reading this newsletter, consider subscribing and sharing with a friend.

Subscribe now

So I thought it’d be useful to write a “Claude Code 101” post where I’ll cover what Claude Code is, the agentic loop, and practical tips for getting started.

What is Claude Code?

Claude Code is a terminal-based agentic tool that interacts with your local filesystem to plan, write, and debug code (plus more features that we’ll talk about below). It was internally released in Nov ‘24, research preview in Feb ‘25, and then GA in May ‘25.

From the official docs:

Claude Code is an AI-powered coding assistant that helps you build features, fix bugs, and automate development tasks. It understands your entire codebase and can work across multiple files and tools to get things done.

In practice: you open Claude Code inside a project folder, give it a task, and it works through your codebase: reading files, coding, testing, and refining. That’s it.

Anthropic built its reputation on high-performance models (Sonnet & Opus). With Claude Code’s bare-bones terminal experience, they’re creating a possible future where IDEs might not be necessary. At least that’s what Boris Cherny, creator of Claude Code, predicts.

Boris recently sat down with Y Combinator to talk about his journey of building Claude Code. Highly recommend watching.

What makes Claude Code interesting

What makes Claude Code interesting (aside from building apps fast), is it removes the barrier to entry for building software and fundamentally changes our role as software engineers.

Boris predicts a future where software engineers are product builders (not backend/frontend engineers), given how easy it is to switch from one tech stack to another with Claude Code.

For example, iOS engineers don’t have to be locked into the iOS stack for building apps, they can jump from one tech stack to another using Claude Code as a coworker (or team of coworkers!).

The real value of Claude Code comes from subagents. You can run a team of agents — separate Claude instances — working in parallel on different parts of your codebase without an IDE (though I use them within VS Code). And the level of complexity Claude handles when debugging and implementing solutions is fascinating and keeps improving with each new model.

At the time of writing, Anthropic’s latest models are Sonnet 4.6 and Opus 4.6.

How Claude Code works

Claude Code operates on an agentic loop. When you give it a task, it works through three phases:

1. Gather context: searches your codebase and reads relevant files.

2. Take action: edits files, runs commands, generates code.

3. Verify results: runs tests, checks compilation, reviews output.

These phases repeat in the loop until the task is complete.

This works great. However, as context accumulates over longer sessions the output quality starts to degrade (usually ~150k tokens) and you’ll notice the model getting “dumber” at making decisions. A good practice would be to track the current context window and use /compact to summarise older context, or start a new Claude session.

For more details: https://code.claude.com/docs/en/how-claude-code-works

Subscribe now

Core building blocks

Claude Code has four core building blocks:

1. CLAUDE.md: A markdown file that tells Claude about your codebase (coding standards, repo structure, architectural decisions). This is persisted context so new Claude sessions can load this into memory.

2. Skill: A set of instructions or repeatable workflows (e.g., /code-review). A skill is a markdown file that can be used globally (~/.claude/skills/<skill>.md) or at the project level (.claude/skills/<skill>.md).

3. Subagent: Separate Claude instances for isolated execution. The key advantage is context isolation. Each agent can work on a specific task in parallel without interfering with each other’s context. Read more about subagents here.

   Fun fact: Anthropic engineers once asked 16 Claude agents to build a C compiler.

4. MCPs: Connectors to external systems and data sources. You can instruct Claude to read your docs, query databases, or access GitHub through an MCP. The more tools you can provide to Claude, the more you can automate. Be careful of giving too much access though!

My first app: Personal dashboard

The first app I built was a personal dashboard: local calendar, GitHub PRs, and Hacker News in one view. I described the idea to Claude and steered it with a few follow-up prompts. In <30 minutes, I had a working web app without writing a single line of code. What surprised me wasn’t just the speed, but how Claude planned the work, implemented the tasks, tested its output, and improved.

The agent scaffolded the repo, wrote its own CLAUDE.md to persist context, and kept refining the UI until it looked right.

🔗 Link to the repo: shehab-as/code-review-dashboard

Tips for getting started

1. Use /init when working on new projects

It tells Claude to analyse your repo structure, dependencies, and conventions. It then writes a CLAUDE.md file that persists context across sessions. Without it, Claude has no memory of your project structure and you’ll spend the first few messages re-explaining your codebase every session.

2. Context is gold, keep it under 150k tokens

When you’re close to 100k-150k context window, Claude Code starts to forget earlier decisions and make silly mistakes. It doesn’t warn you when this happens. Use /compact to summarise older context, or start a new session.

🌟 Pro tip: Monitor context health with a “canary keyword”.

At the start of a session, share a memorable detail and check if Claude remembers it later. If it doesn’t, then you have a bloated context window.

You: "Remember this: my favourite coffee is mocha"
[...long coding session with multiple file edits...]
You: "What's my favourite coffee?"
Claude: "I don't see that information in our conversation"
→ Time to start a new session.

3. Keep CLAUDE.md files short

CLAUDE.md is like the onboarding doc for a new engineer working on your project. It doesn’t require a specific structure, but the general advice is to keep it short and straightforward. My CLAUDE.md files usually have: folder structure, coding conventions, available tools, and architecture highlights.

You can version it on the repo and share it publicly (.claude/). It doesn’t have to be a static file. Revise it as you go.

Here’s a guide on writing a good CLAUDE.md file

While Anthropic does not have an official recommendation on how long your CLAUDE.md file should be, general consensus is that < 300 lines is best, and shorter is even better.

4. Prompt like you’re communicating to an engineer

Avoid vague prompts like “fix this” or “make this better”. Be specific with examples as if you’re talking to one of your engineers. For example,

❌ Fix this bug
✅ There is a memory leak in <module> that causes OOM crashes when handling </api> requests. Check the <class> logic and find the root cause. Ask me clarification questions before implementing a solution.

5. Build Skills for repeatable workflows

A Skill can be a simple markdown file or a folder that looks like this:

• code-review/

  • SKILL.md (required): Instructions in Markdown with YAML

  • scripts/ (optional): Executable code (Python, Bash, etc.)

  • references/ (optional): Docs, style guides

  • assets/ (optional): Templates

This could also be writing tests, generating changelogs, or scaffolding new services. Experiment and see what works best for you. See Anthropic’s guide for building skills.

6. Connect Claude with MCPs

The GitHub MCP is the easiest to start with. Allow Claude to read your PRs and issues for gathering more context before taking actions.

Explore available MCPs in the awesome-mcps repo and play around with it.

Cheat Sheet

Finally, here’s a list of common commands you’ll need in a Claude session.

1. /init → Run this once per project. It analyses your codebase structure, dependencies, and creates a CLAUDE.md file that persists context across sessions.

2. /plan → Enable plan mode. Claude proposes a detailed implementation plan before taking action. Use this for designing complex features or architectural changes.

3. /memory → Views project memory (./CLAUDE.md) or user memory (~/.claude/CLAUDE.md). Edit these files directly to guide Claude’s behaviour, or ask it to update it if you want to persist context.

4. /context → Provides a visual representation of the current context. Use this to debug why Claude might be missing something or to reduce token usage.

5. /compact → Runs context compaction to free up the context window space.

6. /model → Switches between Claude models during the session.

7. /resume [session-name] → Resumes previous sessions.

8. /skills → Lists available skills or create new ones.

9. /agents → Creates or manages subagents (isolated Claude instances).

10. /mcp → Manages MCP servers at project-level (.mcp.json) or globally (~/.claude/mcp.json).

11. /permissions → Manages the allow & deny tool permissions.

Wrap up

So far this is scratching the surface of what Claude Code can do. I highly recommend checking it out. Onboard it on your projects, see where it fits into your existing workflows, and try running multiple subagents. I’m still in explore mode and I plan to share example capabilities in the future (probably a Claude Code 201 post?).

Here’s a quick reference on when to use what with Claude Code.

For further reading, check out: https://code.claude.com/docs/en/best-practices

If you found this post useful, make sure to subscribe and share with a friend.

Subscribe now

Some make the mistake of having a project get blocked by a decision without exploring possible paths forward. Others delegate too many decisions, which can slow down overall progress. Vibe-coding is a form of delegating decisions to AI tools.

Decision-making is a skill in its own right: it requires practice and a framework to follow, particularly as you take on projects with growing impact. Engineers can still be good decision-makers even when projects fail for reasons outside their control. What matters is having the right mental model for evaluating decisions and weighing consequences against reversibility, which I’ll cover in the post below.

I’ll start by introducing Amazon’s decision-making culture by Jeff Bezos, then discuss the cost of decisions and their consequences, and finally share examples of how engineers can make better decisions.

First, let’s start with decision types.

Decision types

Bezos introduced the concept of “decision types” to encourage better and faster decision-making, which later became a core part of Amazon’s culture: Type 1 and Type 2 decisions. He wrote the following in a shareholder letter:

Some decisions are consequential and irreversible or nearly irreversible – one-way doors – and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation. If you walk through and don’t like what you see on the other side, you can’t get back to where you were before. We can call these Type 1 decisions. But most decisions aren’t like that – they are changeable, reversible – they’re two-way doors. If you’ve made a suboptimal Type 2 decision, you don’t have to live with the consequences for that long. You can reopen the door and go back through. Type 2 decisions can and should be made quickly by high judgment individuals or small groups.

As organizations get larger, there seems to be a tendency to use the heavy-weight Type 1 decision-making process on most decisions, including many Type 2 decisions. The end result of this is slowness, unthoughtful risk aversion, failure to experiment sufficiently, and consequently diminished invention. We’ll have to figure out how to fight that tendency.

Type 1 Decisions (One-Way Doors)

Type 1 decisions are irreversible and have long-term consequences.

These are decisions that set the direction and strategy of a company, like entering a new market, launching a new product, or reorganising teams.

For engineers, these decisions should be made slowly and carefully, with analysis and forward thinking. For example:

• Choosing a cloud provider

• Defining public APIs

• Designing your data and security model

• Picking a primary programming language for the product

These are examples of decisions that require research, deep thinking, and discussion with impacted stakeholders (tech leads, managers, directors, and CTO).

A strong sign of leadership is the ability to identify Type 1 decisions, draft proposals, and discuss them with relevant stakeholders. These are decisions that will eventually be maintained by engineers, so it’s important to take time to explore alternative solutions and tradeoffs.

Type 2 Decisions (Two-Way Doors)

Type 2 decisions are reversible and have short-term consequences.

These are day-to-day operational decisions, like handling customer issues or implementing new product features. These decisions should generally be made by engineers directly and shouldn’t require a long chain of approvals. It’s valuable to communicate these decisions proactively, but don’t block yourself waiting on others (especially when the action is reversible). For example:

• Configuring CI/CD pipelines

• Adding feature flags

• Trying a new frontend framework or changing ORMs

• Refactoring a service

These are examples of daily decisions that can be made quickly, and if the outcome is inefficient, it’s not the end of the world. These are often reversible or disposable ideas that don’t create meaningful consequences for the company or its users.

As an engineer, you’re trusted for your technical contributions, which are usually a combination of making fast Type 2 decisions and carefully reviewing Type 1 decisions.

Junior engineers often get blocked here, sometimes due to lack of experience. That’s normal during onboarding/training. But it’s important to build this mental model when working on a busy team: senior engineers and tech leads won’t be available to review every Type 2 decision, especially when it’s reversible.

🌟 My advice: ask for input on high-level decisions (like a design proposal) and make Type 2 decisions yourself (e.g., implementation details).

Changes are always reversible in a pull request.

Subscribe now

Decision costs

Decisions fall on a spectrum from reversible to irreversible. You can tell where a decision lies by asking how much it would cost to undo it. The higher the cost, the more irreversible the decision.

As you progress in your career, there will be all kinds of decisions you need to make. Understanding the impact and cost of each decision is important and will make you stand out as an influential leader.

The following diagram frames decisions along two axes:

• Reversibility (x-axis)

• Consequence (y-axis)

To build the right mental model, this diagram suggests the action based on two factors: reversibility and consequence. The top two quadrants represent high consequence to your team and the business, while the bottom two quadrants represent minimal consequence. The top-right quadrant represents “technical excellence”: high-consequence, irreversible decisions that require deep expertise and long-term thinking. The top-left represents “prototyping”. It’s for building a hypothesis and then running experiments to validate or nullify it, and explaining the results to other engineers. The bottom-left quadrant is for quick decisions on small items. Engineers don’t have to spend too much time on this, especially if it’s easy to undo. The bottom-right quadrant can also be delegated or decided quickly. It might be useful to communicate those kinds of decisions with your teammates, but it certainly doesn’t require hours of meetings back-and-forth.

Below are example decisions you might face as a software engineer.

In startups, you’ll often be exposed more to the top-right quadrant: consequential and irreversible decisions. In larger companies, you’ll see more of the top-left quadrant: consequential but reversible decisions. However, you’ll face all sorts of decisions throughout your career regardless of your chosen environment.

Junior and mid-level engineers typically start in the bottom quadrants and level up to the top quadrants over time. For the top quadrants, senior engineers are typically needed for the top-left, while staff/principal engineers are required for the top-right.

🌟 A useful way to think about career growth is the consequence of the decisions you make. If your decisions can meaningfully impact customers or the business—and succeed—you’re trusted as a strong engineer.

🌟 If you’re mostly making inconsequential decisions, your work likely has limited impact. Reorient toward business outcomes and seek opportunities to make higher-consequence decisions with your manager.

Conclusion

I’d highly recommend building mental models around decision types and consequences. Whether you’re an IC or a tech lead, knowing where to spend time and energy in decision-making is critically important to the business. Teaching others how to make better decisions also provides a great return on investment. Knowing when to delegate, prototype, or bring together a group of engineers for an important technical decision is a skill that requires practice and repetition.

My suggestion moving forward:

• Reversible & consequential: Prototype and get buy-in before executing.

• Irreversible & consequential: Research, think deeply about the options, and discuss with relevant stakeholders.

• Irreversible & inconsequential: Decide quickly or delegate. Don’t waste time.

• Reversible & inconsequential: Decide quickly and undo if needed. Don’t waste time.

My final takeaway is this:

If you enjoyed reading the newsletter, consider subscribing and sharing it with a friend.

Subscribe now

As we’re entering the 2nd week of 2026, I wanted to share some thoughts and trends I’m seeing in the AI ecosystem. I’ve chatted with many software, AI, and product engineers over the past year through local meetups, workshops, and intros. From these discussions, I’ve noticed two things: engineers are empowered with AI and overwhelmed by AI slop.

This post might sound buzz-wordy, but I promise I’ll keep it straight to the point.

Intro

2025 was a pivotal year for AI. We saw:

• Major foundation model advancements from OpenAI (GPT-5 in August), Anthropic (Claude 4 family with Sonnet 4.5 and Opus 4.1), Google (Gemini 3), and Meta (Llama 4 family).

• An early acceleration toward reasoning models. It started when DeepSeek R1 disrupted the industry in January by achieving performance comparable to OpenAI’s o1 at a fraction of the training cost (~$6 million vs $100+ million).

• The term “vibe coding” gained mainstream traction, popularised by platforms like Lovable and Replit that enable building apps through natural language prompts.

• Businesses re-evaluating their strategies with AI and increasingly adopting agentic workflows.

• Hiring engineers became more challenging with LLM cheating. The most documented case was the fake candidate interview story with Vidoc Security Lab.

This space is still evolving and I believe 2026 is going to be an inflection point for software engineers.

Trends I’m seeing ahead for 2026:

1. New wave of AI-native engineers

2. Increasing demand for standardised agentic orchestration

3. Vibe coding becoming the de-facto standard for prototyping

4. AI is booming in the UK

Subscribe now

#1 New wave of AI-native engineers

ChatGPT was released on November 30, 2022, and its performance has improved exponentially ever since.

CS undergraduates who started their 4-year programs right as ChatGPT made public are graduating this year. Technically, we’re looking at the first generation of engineers who have been immersed in GenAI throughout their education.

We’re already seeing some engineers being too dependent on AI tools. But on the flip side, they experienced early integration of AI tools and are more equipped for execution than engineers a decade ago. Hiring should expect a new wave of AI-native engineers.

Challenges:

• Engineers need to understand, explain, and justify LLM outputs at work and interviews. Blindly accepting outputs is not acceptable.

• Critical thinking and debugging will be more emphasised with AI-assisted development.

Opportunities:

• Early-career engineers can practice higher-level thinking and feature planning

• Engineers will be more productive, contributing to projects faster

• Experience with AI becoming a competitive advantage

AI adoption is already happening in SWE interviews…

Some companies now allow candidates to use AI tools like Copilot and Cursor during interviews (with algorithmic interviews being the exception). Meta has been trialling this approach in an attempt to move away from old LeetCode-style interviews. An internal memo reads:

Meta is developing a new type of coding interview in which candidates have access to an AI assistant. This is more representative of the developer environment that our future employees will work in, and also makes LLM-based cheating less effective.

Candidates will still need algorithmic thinking. The idea is to provide an environment for candidates to solve problems using AI tools and to be able to justify their decisions and explain the outputs they’re using to solve.

Task-based interviews are popular among startups and scale-ups, and they’re increasingly more open towards candidates using AI. I’ve covered this before in technical interview guide, which you can read more here:

#2 New demand for Orchestrating agentic AI

TL;DR - I believe we’re close to having a “Kubernetes” version for agentic workflows.

In short, there are two kinds of AI:

1. Generative (ChatGPT) that generates text based on a user’s prompts.

2. Agentic (Claude Code) that acts to achieve complex goals with minimal supervision (e.g., coding up a feature, testing, and creating a PR).

Both kinds are increasingly improving. Generative AI has stronger reasoning capabilities, and agentic AI is evolving from a passive assistant to an active collaborator with decision-making capabilities. Orchestration is about employing a network of AI agents, each designed for specific tasks, working together to automate complex workflows.

Engineers are already experimenting with multiple agents executing different tasks concurrently, essentially operating as a tech lead on top of an “AI super team”. But the de-facto orchestration standard hasn’t emerged just yet.

With this trend, I believe there is a need for developer tooling on top of the agentic workflows. For example, monitoring and observability (o11y) will be required to track and manage the progress of agents like Claude Code. Another is managing resources (CPU/Memory) for running agents. All can be unlocked by an orchestration platform that manages these “AI super teams”, the same way Kubernetes manages containers.

Agentic AI is still a hot topic, and businesses are looking for ways to adopt agentic workflows. So I believe there will be a new class of developer tools built primarily for managing AI agents. And upskilling in that area will be a great ROI for engineers.

#3 Vibe coding becoming the de-facto standard for prototyping

While non-technical individuals quickly embraced vibe-coding, engineers preferred an “AI-assisted development” approach. However, prototyping ideas with vibe coding started to be a thing among engineering teams.

Engineers have reported great results in terms of speed and quality when validating new ideas. The ability to create throwaway solutions in temporary repos for technical review makes it easier for engineers to explore new ideas. And with the increasing coding performance of LLMs like Claude and GPT, teams have started prototyping like vibe-coders.

Vellum shared public leaderboards for evaluating LLM performance. The diagram below shows coding performance (last updated 18 Nov 2025).

Engineers who are good at prompting and high-level thinking will solve more complex problems faster with accurate code generation. This is a highly valuable skill for AI-native engineers in the job market.

One thing I learned from Addy Osmani, Google Cloud AI Director, who shared recently on the “Pragmatic Engineer” podcast by Gergely Orosz, is that he writes an internal monthly AI newsletter to his engineering org about the latest trends and learnings to empower his engineers to work with AI and establish standardised practices.

He explains that engineers should be curious about AI and contribute to defining standard guidelines when working with AI. These efforts will pay off in the long term for an innovation-first culture.

TL;DR - Engineers who keep up with the latest foundational models and are naturally curious will be ahead.

To recap, what makes engineers successful in this environment:

• Strong prompting skills combined with architectural thinking

• Staying current with foundational models (Claude, GPT, etc.)

• Natural curiosity to experiment with new tools as they emerge

#4 AI is booming in the UK

The UK government data shows the number of AI companies has nearly doubled over the past two years, reaching close to 6,000 firms and generating around £24 billion in revenue in 2024, more than double in 2023. Employment in AI has also increased by 33% in just 12 months, with over 86,000 new roles.

Research shows UK businesses are spending an average of £15.9 million on AI, and that figure is expected to grow by 40% over the next two years. Many organisations have started to shift from using AI as a series of isolated technology projects, and implementing enterprise-wide AI strategies.

Latest example is my previous company, Faculty AI. They recently announced acquisition by Accenture for a $1bn, making the company a “tech unicorn”. This is a clear signal of Accenture’s AI strategy. Acquiring Faculty allows them to deploy enterprise-wide AI solutions within their consultancy.

I’ve been fortunate to meet many engineers and founders working on exciting AI products, as well as experience the strong camaraderie in the tech community and supporting other startups as they grow.

No affiliation, here are a very small list of exciting companies (they’re all hiring)!

• Incident.io

• tldraw (short video for AI-assisted drawing agents, fairies!)

• Granola for back-to-back meetings

• Synthesia, an AI video platform for businesses

• Encord for managing, curating, and annotating AI data

• PolyAI for building AI voice agents

• Isomorphic Labs, an AI platform for accelerating drug discovery

Wrap up

Going into the second week of 2026, AI will continue to disrupt industries, and it is more important than ever for engineers to be well-equipped with AI. This shift presents both an opportunity and a challenge. Strong judgment, human creativity, and strategic thinking will become some of the most valuable skills for software engineers.

To recap, these are the trends I’m looking forward to:

1. New wave of AI-native engineers

2. Increasing demand for standardised agentic orchestration

3. Vibe coding becoming the de-facto standard for prototyping

4. AI is booming in the UK

If you enjoyed this newsletter, consider subscribing and sharing it with a friend.

Subscribe now

If the answer is no, but it still leads to a promotion, that is promotion-driven development. Unfortunately, it’s a symptom of a broken incentive system.

Promotion-driven: Solving engineering problems that optimise the promotion packet.
Business-driven: Solving business problems that impact the company.

When leadership rewards this strategy (even accidentally), it signals a clear disconnect between them and engineering.

I don’t claim this is true across all companies; this is a personal opinion based on what I’ve seen and discussed with engineers from other companies.

I’ll share some thoughts below on the problem and how I approach it with both leadership and engineering.

A quick work from Scalekit who is kindly sponsoring this email.

Scalekit (Sponsor)

Agents are becoming first-class actors. They’re calling APIs, triggering actions, and operating without user sessions — which means your auth stack needs to support more than just humans. With MCP servers emerging as the standard interface for agents, Scalekit brings the comprehensive auth stack for AI apps. Their MCP auth module supports all client registration flows, so you can handle real-world clients without sprawl or security debt.

The good part is even if you’re already using a custom auth system, or third party auth providers like Auth0, Cognito, Scalekit plugs in alongside, letting you add scoped, observable auth for agents without ripping out what you’ve built.

Because if agents are on your roadmap, your auth infra needs to meet them there.

Learn more

Problem with promotion-driven development

Shipping projects is a great skill. Doing enough reps as an engineer makes them more valuable for the team and the business. The number and quality of repetitions varies from one company to another. But in larger organisations, there’s often the challenge of competing for scope.

For example, if there are dozens of senior engineers and only a handful of projects, most engineers will be disincentivised to share scope, especially if their promotions depend on shipping those projects. Sadly, not picking the right projects can tank your performance review.

This culture of not sharing scope became more visible at Meta, especially when they cut 5% of their workforce in January and did more performance layoffs later this year. Some Meta engineers shared this shift where teams stopped sharing scope to avoid getting PIP’d.

This environment pushes engineers to find complex, promotion-driven initiatives that didn’t come from a business need. Common examples: architecture rewrites or microservices rewrites.

This is over-engineering, but with a different motivation: finding the complexity to make the promotion case more compelling.

Both leadership and engineering share responsibility for fixing this.

For engineers: Focus on the leverage

A well-rounded engineer should be obsessed with solving business problems. The goal is not delivering complex engineering output with no business value (i.e., showing off).

Finding scope can be very challenging, but introducing unnecessary complexity is not the right direction to follow. If you’re struggling to find scope:

Talk to product people and leadership. Your manager, skip-level, or product manager. Pay attention to their words: what they’re thinking about, what OKRs they mention, what customer deals are making the CEO literally sweat.

These are great signals for you to dig deeper.

Engineering and business challenges don’t have to be mutually exclusive. The problems are at the intersection of a Venn diagram, where solving them moves the business forward and make an engineering impact. This is finding your leverage.

Challenging Complexity

If an engineer presents a “microservice rewrite with no business OKRs” proposal in a design review, this should be challenged, either pivot to an idea backed by a business metric or completely reject it.

Whenever I’m proposing a new idea, I always have answers to the five whys ready.

Say I’m designing an architectural proposal (e.g., scaling out a database).

Valid questions are:

1. Why do we need to scale?

   Answer: Because we’re reaching the limits of a single database instance.

2. Why are we hitting the limits?
   Answer: Because we’re storing data on X, Y, and Z

3. I see the value in storing X & Y, but why are we storing Z?

💡 Notice the shift: why are we solving this with infrastructure rather than addressing the data model?

4. Have you explored other options? Why this <approach>?

5. Why are we confident this plan will work without it becoming an operational burden?

Being prepared to answer these five whys (with research and data) is the mark of a well-rounded engineer.

Also, simplicity > complexity…

There’s an immense value to adopting pragmatism for solving problems. Evan & Stefan, cofounders of hellointerview.com, reinforced this in their blog post: 14 Lessons from Building Hello Interview. They run their entire product using only two services: a Next.js web server and a Temporal worker service.

To quote Stefan:

“Perfect is the enemy of shipped, and we’ve shipped a lot.”

For Leadership: Celebrate product stability

Product and feature launches are great. When engineers deliver and customers are acquired or retained, that’s successful engineering-product partnership.

This partnership still holds true even during “feature dryness.” When architectures are reviewed, costs reduced, and scale improved, those are meaningful contributions that strengthen stability and reliability of the product.

This could be:

• Metrics improved (uptime, latency, cost savings, database connections)

• Infrastructure wins

• Onboarding large customers or sustaining high traffic (e.g., Black Fridays)

These are all efforts worth recognition and support by leadership.

POV: Promotions shouldn’t skew toward building “feature factory” teams, but toward building teams of creative problem solvers.

Maintaining the product might not be a sexy slide deck to present. But initiatives around reliability and scale have long-term impact worth celebrating!

Feature releases are not a prerequisite for promotion. Promotions should depend on many things, including (but not limited to) releasing new features.

Wrap up

Leadership should encourage business-driven development over promotion-driven development. Engineers should anchor themselves to solving business problems, complex or not, boring or not.

Complexity must always be challenged. Not because of the individual, but to justify maintaining that complexity and making sure all options were exhausted.

To me, a healthy design review meeting is one where the engineer has done enough research to justify their idea and can answer the five whys before presenting.

That’s the last post for the year. If you enjoyed reading this, consider subscribing to the newsletter.

Subscribe now

I’ll be back on January 9th. Till then, happy new year to you and your families! 🎉

A month ago, I shared on LinkedIn that I took a mid-year break to make more room for new experiences and reading. Also, writing a weekly blog while working a full-time job is a very challenging thing to manage. But, I’m planning to get back to writing again, at a more relaxed pace (once every 2 weeks) and also share my journey using AI. Today, I’ll share how I use LLMs as an engineer.

Before that, a quick word from Scalekit, who is kindly sponsoring this email.

Scalekit

Today’s fast growing AI apps are collectively thinking about growth, activation, and expansion. But behind that frictionless product adoption, lies the most overlooked systems in product design: authentication & authorization. To understand how this new generation approaches these choices, Scalekit did a manual teardown of 50+ modern AI apps — studying how users sign up, join orgs, switch contexts, and scale into enterprise accounts.

Read the full report here

Intro

In early 2025, many engineers were skeptical about using AI. Some still are, while others fall somewhere in between. However, leveraging AI in software engineering has become a key skill companies look for when hiring engineers, and those who invest in using AI are now being described as AI-native software engineers. We’ll hear the term “AI-native” a lot in 2026.

Addy Osmani, engineering leader at Google, described it in his newsletter as:

An AI-native software engineer is one who deeply integrates AI into their daily workflow, treating it as a partner to amplify their abilities.

I was one of the skeptical engineers, but I became invested in AI adoption for engineering teams and started researching ways to optimise my workflow. So far, I’ve worked with tools like GitHub Copilot, CodeRabbit, Cursor, and Windsurf. I currently use Windsurf as my main editor with state-of-the-art models like Claude Opus 4.5, GPT-5, and SWE-1.5 (default).

I’ve yet to play around with Claude Code, but I’ve heard engineers at Incident.io love using it and that it weaves nicely into their codebase. They wrote a post about it, which I highly recommend reading: Shipping faster with Claude Code.

So, here’s how I use LLMs at work.

1. Coding (logic replication) and writing tests

I use LLMs for coding, testing, scripting, and documentation. For coding, I lean more on logic replication rather than innovation. Replication is things like: copying a design pattern from another module, extending test cases, configuring a new Terraform module, and so on. It’s the local context I can quickly pass to the LLM so it types faster while I review and accept the changes. Also, I spend time writing more specific prompts for the LLM to get better output, just like I’m writing a JIRA ticket for an engineer.

For innovation, I prefer to write the critical myself and delegate the repetitive parts to LLMs. I want the core logic to be crystal clear in my head as I write it. It’s a business asset I must fully understand with its edge cases before shipping.

That said, I still enjoy the tab-tab experience of AI-generated code. It significantly speeds up my development process, and it has certainly made me a better code reviewer.

2. Learning a new programming language

I use LLMs both as a teacher and a study buddy. My common use cases include learning programming languages and onboarding to new repositories.

At my previous company, I had to pick up Rust to write a high-performance simulation library. Using LLMs was helpful at translating ideas from idiomatic Python to Rust. Overall, it accelerated my learning process, especially when figuring out idiomatic patterns like managing memory, handling errors, etc.

Now I always use an LLM when working with new codebases. It’s my AI onboarding buddy. Sometimes I need to jump into an infrastructure monorepo and ask questions like “what are the dependencies of X” or go through another team’s repo and ask “Explain this service to me”.

Being able to ask an infinite amount of (stupid) questions is wonderful. Of course, hallucinations or missing context can produce wrong answers, but still a small risk I’m willing to take. Also with experience you develop an engineering sense to spot incorrect results quickly.

3. Debugging (sometimes)

POV: I find debugging with LLMs harder than debugging solo.

In my experience, LLMs sometimes give you a slightly wrong fix that sends you in a different direction, creating a cascade of misleading answers and fixes. A lot depends on the context you provide.

At the moment, I prefer debugging in focus mode, but if I’m desperate, I’ll try asking an LLM, though without high expectations. However, Anthropic mentioned that their engineers who used the latest model Opus 4.5, solved a critical bug that Sonnet 4.5 couldn’t fix, in 2 mins. So it may just be a matter of time before I can rely on LLMs entirely for debugging.

Generally, when working with large log files, JSON blobs, etc. I definitely will use an LLM for interpretation, since it can process large amounts of information much faster than the human brain.

Subscribe now

4. Proofreading engineering docs

I write a lot of documents as part of my tech lead work. Before sharing design proposals or wikis across teams, I use LLMs to proofread them. Covering edge cases, adding missing links, and fixing typos.

But I don’t use LLMs for drafting new documents. As an engineer, I’m responsible for the technical decisions and proposals I produce. That means taking the time to think through solutions that align with the product spec, and also to carry the project in my head end-to-end (similar to the 1st point about coding).

For me, writing documents is a strategic exercise that I don’t delegate to LLMs.

5. Prototyping ideas (faster)

Before LLMs, I used to jot down ideas on paper and allocate some focus time to code up a silver bullet prototype.

With LLMs, I can now branch out a repo, vibe-code a solution, test it, and quickly decide whether it’s worth sharing.

This cycle of ideation → prototyping → testing → validation can be executed much faster, and I can iterate multiple times a day.

On Friday mornings, I like to vibe-code ideas I’ve had throughout the week, experiment with throwaway solutions in local branches and see if one or two are worth sharing with the team.

That said, I am skeptical about engineers vibe-coding in production repos. To me, it adds a risky layer of abstraction (English → Machine Code) instead of (High-Level Language → Machine Code). Experienced engineers are careful not to blindly accept AI-generated changes that might end up creating an unwanted incident in production. This is especially true for large organisations and enterprise.

But who knows? With the performance improvements I’m seeing, I might change my mind soon. For now, just throwaway prototypes.

Wrap up

I wrote this post knowing there’s still more to leverage with LLMs, but I’m glad I’ve gone from a skeptical engineer to a full-on AI-native (still a work in progress). To recap, here’s how I use LLMs:

1. Coding (logic replication), testing, and documentation

2. Learning new language(s)

3. Debugging (sometimes)

4. Proofreading engineering documents

5. Prototyping ideas (faster)

I don’t use it for:

1. Coding (non-replication)

2. Writing documents

3. Diagramming

How do you use LLMs at work? Let me know in the comments below

One of the early mistakes I made in my career was not reading engineering blogs. I used to think that the only way for an engineer to deepen their knowledge was by reading textbooks like Designing Data-Intensive Apps by Martin Kleppman, Fundamentals of Software Architecture, and so on. While these are great references to have, they often miss the real-world challenges engineers face when architecting solutions for their customers, especially at scale. A great way to learn new patterns or solutions is through stories. That’s where engineering blogs can help.

In this post, I’ll highlight some example stories and share my 25 favourite engineering blogs.

Why should I read engineering blogs?

Say you’re in product team (A) focused on developing a component like search service. There’s team (B) working on a payment service, and team (C) working on the product’s infrastructure. If one engineer from each team gave a ~30min talk to share new findings or solutions they’ve tried, you’d want to attend, right?

Now instead of 30-min talks, their findings / solutions are shared as written documents. And instead of just internal teams sharing their work, these documents come from teams across various companies. The range of stories is now virtually endless, with something interesting and relevant for every engineering team.

A good engineering story includes:

1. Challenge/Struggle

2. Ideas

3. Solution

4. Next Steps

Academic textbooks often take time to include new industry-tested ideas. So, to avoid “knowledge staleness”, it’s important to combine work experience with modern solutions to build a strong understanding of what works and what doesn’t. Solutions aren’t always as straightforward as some textbooks may suggest.

So my advice for software engineers is this:

Here are 8 blog posts where engineers share how they solved an interesting problem, including what worked and what didn’t.

Engineering blog stories

1. Netflix - Introducing Impressions (2025)

Netflix wrote a post about building a system to track every image a user hovers over on the homepage, called “impressions”, to improve personalised recommendations. They explained why tracking impression history matters (to avoid overexposure, highlight new releases, and improve analytics).

They shared interesting stats about their new system, processing from 1 to 1.5 million events per second using technologies like Apache Flink, Kafka, and Iceberg. They also talked about their system’s qualities like ensuring high data quality, and their future plans to automate performance tuning and improve alerting.

Link: https://netflixtechblog.com/introducing-impressions-at-netflix-e2b67c88c9fb

2. Canva - Supporting real-time mouse pointers (2024)

Say you are asked to design an edit collaboration experience (like Canva) based on customer research. You discuss product requirements and trade-offs, and after some thinking, you might arrive at a solution that requires websockets for bidirectional communication with a coordination component (e.g., etcd or ZooKeeper), or a pub/sub model (e.g., Redis).

That’s what Canva initially did. They served 100,000 users using websockets and Redis pub/sub for real-time interactions.

However, Canva faced a scalability issue with supporting real-time mouse updates, which were capped at 3 updates / sec. They shared in their blog post how they transitioned from a Websockets + Redis-based architecture (Milestone 1) to a WebRTC-based architecture (Milestone 2) to achieve a much higher update rate of 60 updates / sec.

Their unique infrastructure problem is a great example of how production engineers manage stateful connections at scale while carefully weighing the trade-offs between technologies that power a great product like Canva.

Link: https://www.canva.dev/blog/engineering/realtime-mouse-pointers

3. Figma - A 9-month journey of sharding PostgreSQL for “infinite” scale (2024).

Figma wrote a blog post about their journey with horizontal sharding on their SQL database. They shared useful insights on database sharding (logical vs physical sharding). They shared some interesting stats in their blog. For example, new tables sharded in production experienced only 10 seconds of partial downtime. It’s an interesting read for those managing databases at scale.

Link: https://www.figma.com/blog/how-figmas-databases-team-lived-to-tell-the-scale

4. Discord - how they store billions trillions of messages! (2023)

Discord shared in their 2017 blog post how they were managing 120 million messages / day using Cassandra with a team of only four backend engineers! However, they later faced performance issues with Cassandra as their messaging infrastructure grew to store trillions of messages. As a result, they decided to migrate to ScyllaDB for handling the new write-throughput. They go into technical details about how they managed the database migration and celebrated how ScyllaDB helped them handle massive data during high-traffic events like the World Cup. Here’s a highlight:

“At the end of 2022, people all over the world tuned in to watch the World Cup. One thing we discovered very quickly was that goals scored showed up in our monitoring graphs. This was very cool because not only is it neat to see real-world events show up in your systems, but this gave our team an excuse to watch soccer during meetings. We weren’t “watching soccer during meetings”, we were “proactively monitoring our systems’ performance.””

Links:

• (2017) https://discord.com/blog/how-discord-stores-billions-of-messages

• (2023) https://discord.com/blog/how-discord-stores-trillions-of-messages

5. Snap - using QUIC for Snapchatters (2021)

The QUIC protocol was designed in 2012 as a replacement for TCP to reduce network latency. I had read about this protocol before, but I had never read stories about using QUIC in production. Snap shared their story of how QUIC reduced network latency for live videos, a critical feature for their users (Snapchatters).

Link: https://eng.snap.com/quic-at-snap

6. Shopify - Building resilient payment systems.

Shopify shared 10 tips for building resilient payment systems in a blog post. While the details are high-level, their sixth tip on Idempotency Keys stood out as an interesting observation. They recommend using ULID instead of UUID4 as it performs better with B-tree–based indexes due to its sorted nature. Here’s a highlight:

“In one high-throughput system at Shopify we’ve seen a 50 percent decrease in INSERT statement duration by switching from UUIDv4 to ULID for idempotency keys.”

Link: https://shopify.engineering/building-resilient-payment-systems

7. Uber - Kubernetes migration journey (2025)

Uber initially used Apache Mesos as their container orchestration framework to manage their platform. However, they decided to move away from Mesos (which they announced as deprecated in 2021) and migrate to Kubernetes. This decision posed significant challenges related to scale, reliability, and integration. They first defined their migration principles and explained why they had to rebuild all their integrations from scratch. It’s an interesting read about Uber’s year-and-a-half journey migration from Mesos to Kubernetes.

Link: https://www.uber.com/blog/migrating-ubers-compute-platform-to-kubernetes-a-technical-journey/

8. Stripe - Building interactive docs with Markdoc

Stripe shared how they rebuilt their documentation with Markdoc, a custom format that simplifies the authoring experience for developers. It’s an interesting tool that boosts both developer productivity and documentation quality. If you care about great docs, this one’s a must-read.

Links:

• https://stripe.com/blog/markdoc

• https://markdoc.dev/

Subscribe now

Top 25 engineering blogs

P.S. My recommendation is not to read all these blogs. I recommend picking the ones that tackle a similar problem you’re facing or cover a topic you’re curious about.

Here are my favourites:

1. Engineering at Meta (also, AI Research at Meta)

2. AWS Architecture Blog

3. LinkedIn Engineering

4. Discord: Engineering & Developers

5. GitHub Engineering

6. Stripe Blog: Engineering

7. Slack Engineering

8. Google for Developers

9. Uber Engineering

10. Spotify Engineering

11. Netflix Tech Blog

12. Canva Engineering Blog

13. Pinterest Engineering

14. The Cloudflare Blog

15. Medium Engineering

16. Yelp Engineering Blog

17. Airbnb Tech Blog

18. Shopify Engineering Blog

19. Snap Engineering

20. Docker Engineering

21. Engineering at Microsoft

22. Dropbox Tech Blog

23. Auth0 Engineering

24. Booking.com Blog

25. Grafana Labs Blog

Let me know your favourite blogs or share your recommendations!

P.S. If you’re finding this newsletter valuable, share it with a friend, and consider subscribing if you haven’t already.

Subscribe now

Subscribe now

First, Feedback 101

If you’re new to providing feedback, I recommend following one of the two guides below. This will help you structure your responses in a meaningful way to get started.

• Situation-Behaviour-Impact (SBI)

• Situation-Task-Action-Result (STAR)

There are probably 10 more guides out there, but they all follow the same idea (describe a scenario and what the person did). I wouldn’t spend time reading them all if you’re already familiar with SBI or STAR.

Now, let’s talk about giving feedback to engineers using the growth axes.

Growth Axes: Technical and Behavioural

Growth axes are an abstraction of technical and soft skills. They highlight key areas engineers should focus on and group them into two main categories. When writing feedback or doing self-assessments, it’s helpful to view these axes and see the “deltas of expansion” over time. This way instead of asking, “How much did this person improve as an engineer?”, you can reframe it to, “How much more scope has this person taken on since last time?”.

First, the Technical axes measure a software engineer’s core skills and ability to solve complex problems. These include how well they understand underlying systems (knowledge depth), the creativity and complexity of their ideas (solution complexity), the quality of their code and design (quality of execution), and the challenging projects they can take on (scope).

Second, Behavioural axes measure how someone operates within a team: how they communicate ideas and ask questions (communication), work with the team (collaboration), take initiative and introduce new ideas (influence), and demonstrate a leadership-like attitude in getting things done (ownership).

Using growth axes to provide feedback is an effective way to link a person’s performance to the traits most valued at work. The best type of feedback is when it helps the recipient progress in either the Technical or Behavioural axes, making sure they’re moving in the right direction and ultimately getting promoted.

🌟 Tip: Most engineers (especially junior-level) tend to focus heavily on the Technical axes. Highlighting the Behavioural axes in your feedback is a great way to broaden their perspective and emphasise the importance of soft skills in the workplace.

Now, let’s go to contextualised feedback.

Contextualised Feedback

Contextualised feedback is just a fancy way of saying, “provide a specific example of when a particular action occurred”. It works best when you highlight a specific scenario with a delta on how to handle the scenario better next time. If they have an “Aha” moment from your feedback examples, that’s a sign of great feedback!

To illustrate, here are four examples of contextualised feedback:

1) Alice is a strong IC, but needs to start scoping work.

“Alice did an excellent job on delivering X and supporting her team, great work! For further growth, I’d recommend she start focusing on technical planning. This is an opportunity for her to stretch her high-level thinking and think about trade-offs when designing a new feature. For example, in her next project she can start writing an RFC document to propose a solution, discuss it with the team, and break it down into tasks. This will help her build confidence in scoping more complex features”

2) Bob did a good job on his first tech leading, but needs some pointers.

“Bob’s project as a first-time tech lead was a success, well done to him! I noticed however some coordination challenges when managing work across a few team members. For example, I noticed in situation X and Y where he had to step in multiple times to support a junior engineer and unblock their work, which left him with little time to prepare for design meetings. While supporting the team is a great quality of a tech lead, one area for improvement is identifying tasks he can delegate to more experienced team members. This would empower them to support junior engineers with less-friction tasks, essentially creating “clones” of himself through the more experienced engineers. I’m happy to share more tips on that!”

3) Charlie needs to further develop his technical skills.

“Charlie showed strong ownership when working on X, which I’d encourage him to keep doing! I also noticed his passion for backend engineering during our weekly catch-ups. One area for growth would be to deepen his knowledge by tackling more challenging backend tasks or leading small initiatives to improve our product’s infrastructure. This would be a great opportunity to ask the tech lead for more challenging work and guidance for improving his technical chops.”

4) Emma is afraid of asking questions.

“Emma did an excellent job managing project X and handling comms around Y. This was really helpful for leadership’s context, so kudos to her! I did notice she sometimes hesitated to ask questions during our bi-weekly leadership calls, especially around Z, which is totally understandable. For growth, I’d encourage her to start asking questions (even basic ones) during planning meetings to clear up any miscommunication and build confidence to ask tougher questions with leadership. I’m happy to chat more and share resources that helped me with this too.”

Helper Questions for Writing Feedback

For writing great feedback, here are some of the questions I often copy-paste from my template:

1. What projects did I work on with this person?

   • (A bullet list is fine)

2. What stood out when I worked with them on each project?

   • Something cool they did or an initiative that was valuable.

3. What do I want them to do more of or keep doing?

   • This could be anything. For example, how they manage a weekly meeting. If that was useful, I’d want to reinforce the behaviour through recognition.

4. How would I score this person (1–10) on the Growth Axes?

   Note that the goal is not to provide “official scores”, but to help understand my perspective on their strengths and areas for development.

   

5. If this were my feedback, are there any examples that would make it more helpful?

   • For example, on the “Influence” axis, this could be leading an idea or an initiative. On the “Quality of Execution” axis, this could be recommending an engineering book or do some pairing.

Conclusion

Writing great feedback is an underrated skill. Every 6-12 months, you’ll be asked to write feedback for your peers, managers, and direct reports. If the process feels like hitting a brick wall each time, that’s a missed learning opportunity. Having a systematic approach reduces the friction of writing and allows you to share meaningful insights that the reader can build on. This is what drives engineers (and everyone) to grow in their careers and have meaningful conversations with their managers.

The last things I’d say is:

• Be empathetic: The person receiving feedback is probably feeling just as uncomfortable as you are.

• Be specific: Avoid ambiguous statements. Provide a clear example with a delta on how to handle the situation better. (Remember, contextualised feedback)

• Be welcoming: Allow room for discussion. They might have something new to add or clarify.

And that’s another made-up framework for you, ESW. 👀

Finally, the one piece of advice I’d give to those receiving feedback is this:

If you’re finding this newsletter valuable, share it with a friend, and consider subscribing if you haven’t already.

Subscribe now

And last one is unclear purpose. Some senior engineers and tech leads argue, “Who will benefit from these docs if we already have the mental model of the system?”

You can see why this single-point-of-failure is not sustainable.

However, most engineers hand-draw the architecture using simple diagrams (boxes and arrows) because it’s a more intuitive and straightforward approach. The C4 Model builds on this concept, providing some convention and clear boundaries to make the diagrams more consistent. It’s been adopted by engineering teams like Spotify (blog) and is referenced in several articles, including Martin Fowler’s: Building Infrastructure Platform.

Subscribe now

In this post, I’ll explain what the C4 Model is and how it can be used for better team collaboration and documentation of software architecture.

Documenting Software Architecture

Designing an architecture is an evolving process, not a finished product. This holds true for different types of organisations, including startups, scale-ups, and big tech. However, the driving factors can vary. It might be a scalability issue requiring architectural changes for new read/write patterns, or a new project that demands additional infrastructure (e.g., building ML pipelines, etc.).

Keeping the architecture documentation up-to-date without a clear framework is challenging for engineers, especially when they’re busy with other tasks like project scoping and feature development.

As a byproduct of missing frameworks, we default to using many shapes (boxes, circles, etc.) with many arrows to model the systems’ infra and code structure in multiple diagrams.

Here are some examples below:

Adjacent to the problem of documenting architectural designs is the challenge of documenting software design (i.e., OOP and design patterns).

In the 2000s, the Unified Modeling Language (UML) was the go-to approach for software design. UML was introduced in the 1990s as a general-purpose language to visualise a software design, break down its internal components in a Class structure, and model their relationship.

However, it was built to solve an outdated problem. Its main focus was modeling class relationships in source code—which worked well for Monolith architecture and academic projects—but it relied on strict rules and notations for relationships and associations. For most engineers, it quickly became too complex to follow and use, especially in modern software design.

In software design/OOP interviews, I never expected candidates to use UML; simple boxes and arrows were good enough.

Here’s a classic example of modeling a banking system using UML. Notice the annotations and arrow types used to define specific relationships.

The C4 Model

So what is the C4 model?

It’s a set of hierarchical abstractions that describe software architecture using simple graphical notation. C4 stands for Context, Container, Component, and Code, each representing a diagram at a different level of abstraction.

The idea is simple and tooling-independent. The Context view provides a high-level overview of the system and its interactions with external systems (or internal systems we don’t have context on). The Container is a view of the software building blocks, such as applications and databases, and how they communicate. The Component view is a breakdown of containers into smaller detailed flows (e.g., CRUD components). The Code view is the implementation details, focusing on classes and code structure (similar to UML). This multi-layered view supports the needs of different stakeholders—from architects and developers to product managers and analysts—by building a clear, shared understanding of the system’s architecture.

Think of the Context as viewing a country in Google Maps: you can zoom in to explore a city within the country (Container), zoom in further to a specific area in the city (Component), and finally zoom all the way in to a specific street (Code).

This layered approach is what the C4 Model provides. No complex notations, only hierarchical diagrams with clear boundaries.

For more details, I’d recommend watching this latest talk by Simon Brown where he explains why C4 Model exists:

How to use the C4 Model

With any new approach, I’d start simple. The goal isn’t to enforce a diagramming convention on the engineering team, but rather to test and explore the intuition behind explaining an architecture using the layering approach. This could involve modeling one microservice or two services, where one depends on the other. I’d recommend trying a top-down design approach. Here’s a reference diagram as a recap.

Before starting this exercise, here are some questions I’d ask myself:

• Do I understand the boundaries of each diagram (Context, Container, Component, Code)?

• Am I able to identify which part belongs to which diagram?

• Am I abstracting too much or over-explaining my diagrams?

• Would another person understand the intention behind my diagrams?

• Is it easier to read compared to our existing diagrams?

Wrap up

Software documentation is a bottleneck for many engineering teams. The goal of overcoming this bottleneck is to quickly build a mental model of a system, making it easier to introduce new ideas and fully understand how everything fits together.

Having a standard process like C4 for documenting and updating architecture improves decision-making, increases collaboration, facilitates knowledge sharing, and provides smooth onboarding. C4 is tooling-agnostic and easy to follow, making it an excellent fit for any organisation.

P.S. If you enjoyed reading this post, you might also be interested in reading this post on developer documentation.

🧊 IcePanel

If you’d like to use the C4 Model, I recommend checking out IcePanel.

IcePanel is a collaborative diagramming and modelling tool for software architecture based on the C4 model.

It’s a lightweight and powerful tool to help you visualise your architecture at different levels of abstraction with a single source of truth. Great for all audiences, from technical (engineers, architects) to non-technical (product and business people).

Design your architecture

If you found this post valuable, share it with a friend and consider subscribing if you haven’t already.

Subscribe now

Subscribe now

It is a general term used for the first engineers at a startup. They are the first hires made by the C-suite to work on the business idea and help transform it into a viable solution (very high-level here).

Here’s another explanation I found useful on Medium:

“They are the ones that got the product off the ground and into the hands of the customers. They designed and developed significant portions of the codebase from scratch, and know the inner workings of the code better than anyone. Beyond engineering, they joined the company at the riskiest point and tend to have higher equity than following hires in comparable positions.” Source

P.S: A Founding Engineer is not a CTO.

In some cases, especially at the start, a CTO might operate as a Founding Engineer if there are only a few people (e.g., 2-5), but they will eventually need to delegate that responsibility to a full-time engineer who will serve as the product architect and the coding machine.

With that context, let’s talk about some key traits of Founding Engineers and how they operate.

#1 Plan for the Punches 🥊

Joining an early-stage startup as a founding engineer is a high-risk move that requires some calculation. Those who join and are prepared for some personal / professional punches are the ones who can make great things happen.

Some of the punches are:

• Working with a tight budget.

• Weekend calls to fix broken deployments.

• Customer calls not going great.

• Struggling with customer acquisition or growth.

• Rewriting significant parts of the codebase.

• A family member not feeling well.

• Moving between houses.

Reality is, this isn’t a 9-to-5 cushy tech job. It’s a critical role that requires someone who is passionate about the problem they’re solving and making a significant impact. Founding engineers know this upfront because they’re in it for the long game, so they plan accordingly.

They also make sure they’re getting a good base salary to support their personal life so they’re not distracted midway.

#2 Deep Technical Skills 🧠

Founding engineers need to be technically strong, I’m talking A+ engineers. They operate as generalist software engineers where they handle the backend, frontend, infrastructure, and QA work (with some limitations). These are people who are skilled at solving problems and enjoy a new challenge. Either they know how to solve a specific problem or know how to find a solution for it.

They’re also responsible for later hiring other engineers. They define the engineering culture and enforce good software engineering practices. They can also attract like-minded individuals through referrals to join their team at the growth stage.

Hiring A+ founding engineers increases the likelihood of building an A+ team.

#3 Hard Conversations 🗣️

Being able to have tough conversations is valuable for founding engineers. They’ll need to talk about crucial topics, whether it’s with early customers or the founders.

This could be about equity, salaries, product direction, hiring, budgeting, and more.

A common situation for founding engineers is receiving customer feedback. If customers don’t like their prototype demo or the latest feature, that’s perfectly fine. It’s a valuable data point to improve from. What you want is honest feedback. Politeness can create a bad dataset, which is unhelpful in early-stage product development.

Those who can ask the hard questions and handle the tough responses, stand out. This personality trait creates a culture of transparency and honesty within the team, and that’s something all stakeholders highly respect.

#4 Good Information Diet 🛜

Founding engineers aren’t absorbed in daily startup news. They protect large blocks of their time for deep work.

They focus on solving their startup’s problems rather than watching others solve theirs. The engineers behind OpenAI, Lovable, and Cursor aren’t spending their time on Twitter (X) or Hacker News reading about DeepSeek or what other Agentic AI startups are doing. They’re heads down, focusing on scaling and improving their products.

A good habit of a founding engineer is being conscious of their news consumption (online) and leave room for deep thinking and creativity (offline).

#5 Fight or Flight ♟️

This may sound like common sense, but founding engineers need to double down on the company vision. They’re not shaken by the first bump on a bumpy road. They also understand what it means for businesses to be fight-or-flight mode.

What is fight-or-flight?

In a business context, the flight strategy is about differentiation, offering a unique value to new customers rather than directly competing for existing customers with relatively the same value. The fight strategy on the other hand, involves competing with other competitors by offering a similar value to customers with some different parameters (think AWS vs GCP for cloud offerings).

Companies that follow the flight strategy look for under served market or create entirely new spaces (often called “blue oceans”) where competition is minimal. They focus on innovating in these new spaces and serving new markets without intense competition.

Let’s take an example of a cloud observability startup (Honeycomb vs AWS)

Competing with AWS is a classic fight strategy. AWS provides observability solutions (e.g., CloudWatch) that offer metrics, logs, and traces out of the box. Some companies focus on competing with them by offering better dashboards (e.g., AI-powered solutions) or better pricing, but they’re still playing the same game. Some businesses follow this approach to compete for existing customers, and that’s okay.

However, Honeycomb (founded in 2016) took the flight approach. Instead of building “yet another monitoring tool”, they introduced a novel approach to observability. They provide an observability platform that empowers engineers to better understand their systems and know why things are happening, not just what happened.

This flight strategy of differentiation allowed them to avoid directly competing with AWS. Instead, they focused on defining what great observability looks like and how their product delivers it.

📝 Quick note on fight-or-flight

Founding engineers aren’t typically responsible for this, as it aligns more with a product person (e.g., CEO/CPO). However, knowing this in general can help provide context for the environment in which founding engineers are operating in.

Remember: Slack was originally a gaming company. They didn’t compete for a better gaming company (fight), they pivoted to become a multibillion-dollar B2B messaging platform (flight).

#6 Expectation Setting 🤝

This one is short and sweet. Founding engineers know how to manage expectations with both technical and non-technical stakeholders. They’ll be the first ones asked:

• Why the product is behind the technical roadmap.

• When a specific feature will be available.

• Why a particular idea isn’t possible.

• How we can make some idea possible.

Being able to manage different stakeholders and set expectations is important for the first engineers writing the code from scratch.

Wrap up

Hiring a founding engineer is not the same as hiring a software engineer at a big tech company (i.e., LeetCode). This process typically happens through strong referrals or candidates demonstrating deep technical expertise from previous projects. Hiring a founding engineer also requires immense trust. That’s why most founders first reach out to their network to identify a potential match with someone they’ve worked with before and ask them to join their team.

Would I recommend taking the Founding Engineer path? Spoiler: it really depends.

But in general, I admire those who take it. These are engineers with impressive scars from building products who have lots of stories worth listening to.

If you’re finding this newsletter valuable, share it with a friend, and consider subscribing if you haven’t already. One email every Friday at 12PM GMT. 🤝

Subscribe now

What is backlog refinement meeting?

It is a recurring meeting where the engineering team and the PM review the product backlog, add new or remove outdated tasks, and reprioritise for upcoming sprints.

Think of it like this: the input of the meeting is a list of unordered tasks, and the output is a priority queue where the sort key is importance score.

How to deliver a backlog refinement meeting?

Refinement sessions are typically led by Tech Leads (Senior or Staff). However, smaller projects or feature planning can also be led by Mid-level engineers, requiring efforts of ~1-2 engineers.

First, let’s clarify what the meeting should not be about.

If new projects require scoping and design for team buy-in, it’s better to have that as a separate meeting. The mechanics of the two meetings can be similar, but the outputs are quite different.

Design proposal meetings involve in-depth engineering discussions, exploring alternatives, and gathering feedback from the team. The next steps from this meeting could be either for the author to explore other options and check back (possibly with another design meeting if needed), or to reach a consensus on a specific design and start breaking it down into tasks (i.e. backlog refinement meeting).

For (operating) tech leads, your goal is to clearly communicate the tasks the team should focus on. A good way to prepare the agenda is by writing them down in advance, following this template.

Here’s the breakdown for each task:

I. Description: Context of the project: why this task exists and what we aim to achieve.

II. Technical Notes: Suggestions or ideas for implementation details the assignee should keep in mind. Links to existing designs or source code.

III. Acceptance Criteria (AC): When can we mark this as done? Have we tested this? Have we shipped this?

IV. Points/Days: How important is this task to the business? How many points or days should we estimate?

🌟 Tip: Product Managers highly appreciate this metric. It helps them manage expectations outside the team and also derive some clarity from the dev team.

V. Deadline (optional): Is this time-sensitive? Are users expecting it by a specific date?

Your agenda should look like this before the meeting:

How to run the meeting:

1. Set the context upfront.

If your team is working on multiple work-streams, specify upfront which type of work you want to refine. You might be refining work from two sub-projects or one highly important feature. Either way, make it clear at the start what you expect your team to review.

2. Walkthrough each task on the backlog.

Go through each task, explain its purpose at a high level (description), and what you expect the assignee to do (acceptance criteria). Highlight the technical notes (when applicable) and ensure that relevant resources are added for the assignee. Keep task descriptions short and concise as well as your explanation (~1-2 minutes).

3. Allow room for questions, modify if needed.

After going through each task, ask if the team has any questions. Leave some space for that uncomfortable silence before someone speaks up. This gives team members time to re-scan the task and call out any details. If there are questions or notes, make sure they’re resolved and added to the task if relevant (e.g., additional technical notes or a follow-up task).

4. Story-point and agree on estimates.

If everything is clear, ask the team for effort estimates (e.g., poker planning). This can reveal new insights, like some team members flagging risks by estimating high or everyone agrees this is a quick fix. Make sure each task the team reviews is story-pointed.

Note: You don’t have to use the “traditional agile estimation” holistically. An estimate can simply be 1/2 day or 1 day of engineering time. Follow your team’s preference for the estimates or metrics that work best for them.

P.S. It’s okay if not all task are fully defined — as long as they include some details to guide the conversation and allow you to fill in missing details during the session.

P.P.S. Your team might work with more or less metadata on each backlog item. Use this as inspiration if you’re just starting out, and improve the template as you go.

Wrap up

Like anything else, getting good at delivering refinement sessions takes practice. Tech leads aren’t naturally skilled at it—they were once junior engineers who learned from their tech leads running these sessions, gradually took on feature planning with increasing complexity, and eventually became comfortable scoping and leading larger projects.

A sign of a growing engineer is one who proactively asks to scope a specific feature, understands the technical challenges, and can deliver a clear roadmap for technical delivery through well-refined backlog items. This approach of dry-run tech leading is a strong signal of someone operating at the next level.

For recap, the four steps are:

1. Set the context upfront.

2. Walk through each task on the backlog.

3. Allow room for questions and modify if needed.

4. Story-point and agree on estimates.

Rinse and repeat, and you’ll noticeably get better. 🚿

If you’re enjoying the newsletter, share it with a friend, and consider subscribing if you haven’t already. You can also add a testimonial through this 1-question form.

Subscribe now

Here are some testimonials from our readers 🫶

Subscribe now

Let’s unpack each one and explore how proactive engineers approach them.

I. Solo Programming

Engineers who can take on any task and execute it solo are often regarded as strong ICs. It’s an opportunity to demonstrate ownership and accountability when working on a specific task. Examples include:

• For junior-level, coding a well-defined task.

• For mid-level, debugging a deployment issue.

• For senior-level, designing a new service.

Solo programming is the default for engineers working on a task in deep focus.

Contractor software engineers work in solo mode 99% of the time. Some companies hire engineering teams made up mostly (if not entirely) of senior ICs. While this approach can increase the bandwidth for complex technical delivery, it reduces the opportunities to grow and mentor less-experienced engineers.

Pros of Solo:

• Learning: Encourages research and critical thinking to find the best solution.

• Ownership: Demonstrates responsibility for a task or project.

Cons of Solo:

• Limited perspective: Solutions may be influenced by personal biases.

• Skill variability: Task outcomes can vary depending on individual experience levels.

II. Pair Programming

Two developers working together, with one writing code (the driver) and the other reviewing (the navigator).

Coding interviews are based on pair programming. The candidate being the driver for solving the problem, and the interviewer as the navigator supporting the driver.

I once spent a full 8 months at Dell working in pair-programming mode. The first half was with a mentor, where I received live code reviews and guidance while implementing new solutions. The other half was with a colleague, whom I was onboarding to our codebase and infrastructure.

There are times when an engineer wants to think out loud about an implementation detail or explain their debugging approach to another engineer. This is similar to rubber duck debugging, with the other engineer acting as a sounding board.

Pros of Pairing:

• Second opinion: Seeking another opinion to address a specific problem.

• Knowledge sharing: Onboarding and mentoring engineers.

• Live feedback: Providing real-time suggestions or code reviews on a developed solution.

Cons of Pairing:

• Reduced Autonomy: The need for immediate feedback leaves little time for independent thinking and research (i.e., engineers tend to context switch if their attention is not required for long).

• Resource strain: Two people working on a single task can be an expensive use of engineering time for the team.

III. Mob Programming

Taking pair-programming to the next level.

This is a mode where the entire team works on the same problem, at the same time, and at the same computer. One writing code (the driver) and others exchanging ideas (navigators). Also known as Ensemble Programming.

Pros of Mob:

• Solution Ideation: More ideas are generated as everyone is actively involved.

• Team Engagement: All team members are equally engaged and invested in the outcome.

• Onboarding at scale: It’s an effective way to onboard multiple new team members.

Cons of Mob:

• Inefficient utilisation of time: Having multiple people working on the same task can be distracting, especially if conversations get in the way of focused work.

• Slower progress: While collaboration encourages discussion and debate, it can also slow things down since decisions need group approval. If speed is important, Mob Programming might not be the best approach.

Here are some use-cases to think about:

• If an engineer is stuck on an implementation detail for 1+ days, offer to pair with them.

• If there’s a pain point that significantly affects the entire team (e.g., dev tooling), consider fixing it solo to remove friction. Teams and managers will highly appreciate it.

• If there are new engineers on the team, consider mob programming to share process knowledge (e.g., deploying a feature, resolving an incident).

• If there’s a task you can handle quickly and effectively (e.g., demos), do it solo.

• If you need live input from product or design on a specific feature (e.g., UI widget), consider pairing if appropriate.

Wrap Up

Engineering teams know what works best for them and can mix and match different work modes based on the context. Solo programming enables high developer velocity, pair programming allows for immediate feedback and knowledge sharing, and mob programming creates space for solution ideation and debugging critical incidents.

Does your team work in all three modes? Let me know in the comments below.

P.S. If you’re finding this newsletter valuable, share it with a friend, and consider subscribing if you haven’t already.

Subscribe now

Andrej Karpathy, co-founder of OpenAI, introduced a new term called vibe coding to describe how developers can guide an LLM to solve a problem by framing it through a set of prompts. The concept is similar to prompt engineering, but is focused on generating code with LLMs. Andrej describes it as a new way of programming by “giving in to the vibes to LLMs, embrace exponentials, and let it do the work”. Here is his famous tweet from February 2025.

Subscribe now

People are increasingly doing vibe coding and AI coding tools make it ridiculously easy to get started. For recommendations, you can check out Cursor or Replit Agent.

However, as cool and trendy as vibe coding is, it will have a massive impact on traditional software engineering—both positive and negative. In this post, I’ll talk about the future of vibe coding, its upsides and downsides, and its impact on software engineering.

The future with vibe coding

Developer tools have become more capable with AI. Tools like GitHub Copilot and Cursor allow a developer to chat with an LLM to describe a task to solve. The LLM generates the necessary code, the developer reviews it, and can quickly approve it with a few tabs.

Some industry professionals love this new way of coding and advocate for making code accessible to non-technical users. Others are concerned about the reliability and maintainability of AI-generated code. I’m more with the latter group, at least for now, until I see more positive examples of companies using it or until we have a proper vibe debugging in place.

Jared Friedman, Garry Tan, Harj Taggar, and Diana Hu from Y Combinator shared their thoughts on vibe coding a couple of weeks ago. They talked about how vibe coding is shaping the future and unlocking exponential benefits for founders and startups. It’s a 30-min discussion if you want to check it out:

Check out this NicolasZu’s flight simulation game, built purely on vibe coding (thousands of prompts, no coding).

However, people on the internet didn’t like the Y Combinator video (excluding trolls). They shared opposing views on how relying heavily on LLMs can be dangerous. It could either force users to create mediocre, repeatable apps, or generate code with unpredictable behaviour that is hard to maintain, or act as a replacement for engineers. Heres’s an example:

There is truth in both arguments—vibe coding is a double-edged sword. It can increase developer productivity in engineering teams, but it is obviously not a replacement for engineers. To leverage vibe coding in building software, you’d still need technical expertise to review the new changes. That’s why we do PR reviews.

Vibe coding is like having non-tech users review PRs before releases.

Upsides of vibe coding

1. Great for prototyping, especially when building new products

Vibe coding is powerful for prototyping and building MVPs. It allows teams to quickly translate ideas into functional code without spending extensive time on development. This fast iteration helps founders test new ideas and validate features early in the process, enabling them to pivot fast based on feedback.

2. Up skilling individuals

Vibe coding can be powerful for engineers who are learning a new programming language or want to operate as a full-stack (generalist) software engineer. A backend engineer can tap into frontend work with vibe coding if needed.

Vibe coding is also great for less-technical professionals who want to test out new ideas and bring them to life. They can communicate their ideas to an LLM to generate functional code without deep programming expertise. This allows product managers and designers to create simple software ideas through a conversation, making it easy to test and less expensive to delete (without spending engineering resources).

3. Increased developer productivity

Vibe coding can significantly boost developer productivity by automating repetitive tasks, generating test cases, and speeding up the coding process. This allows them to focus on higher-level design, architecture, and problem-solving, ultimately accelerating the development cycle. By leveraging vibe coding, teams can move faster and ship more features with less manual effort, driving greater overall productivity in the development process.

Downsides of vibe coding

1. Complicated to use in large enterprises

Vibe coding can be difficult to use in large enterprises. While it works well for individual developers and small teams, complex codebases and existing abstractions present challenges. Relying on AI-generated code requires thorough review and testing to ensure it meets the necessary standards and fits within the broader design.

2. Non-technical individuals can get stuck midway

While vibe coding lowers the barrier to entry for coding tasks, non-technical users can get stuck on runtime errors or debugging issues without additional help from LLMs. A simple example is when an LLM generates code using a deprecated API from library version x.y.z, while the non-technical user has library version x.y+1.z installed.

Although the chances of this happening are relatively low, lacking technical knowledge makes it harder for users to resolve such issues on their own.

A good example is Leo’s SaaS, which was built 100% with LLMs. 😬

3. Less-experienced engineers relying too much on vibe coding

Junior engineers who rely too heavily on vibe coding without understanding core programming concepts risk producing inefficient or unmaintainable code. Excessive use of AI tools can hinder their long-term growth by limiting the development of problem-solving skills and a deep understanding of software engineering principles.

Just as we advise junior engineers not to blindly copy-paste code from stack overflow, we should also encourage them not to rely on vibe coding without thoroughly understanding the output.

Final thoughts

Vibe coding is shaping up the future. AI tools are getting better and more autonomous every day, allowing developers to ship code faster than ever. Less technical people can now build apps as easily as capturing an iPhone video.

However, a strong technical foundation remains essential for building software beyond prototypes. Engineers must develop the skill of capturing vibe coding practices within their teams and carefully reviewing LLM-generated code. Vibe coding should be treated as a supplementary practice in software development, not a primary one.

Less-experienced engineers now turn to LLMs instead of the good ol’ Stack Overflow. This shift places greater responsibility on senior engineers and tech leads in startups and large enterprises to audit LLM-generated code and ensure it fits within their software design. After all,

Each new line of code adds debt to the developer—it needs to earn its place in production.

Have you tried vibe coding recently? Let me know your thoughts in the comments below.

If you’re finding this newsletter valuable, share it with a friend, and consider subscribing if you haven’t already.

Subscribe now

In this post, I’ll answer two questions:

1. How to think about tech debt.

2. When to pay down tech debt.

First, there will always be tech debt

In early 2023, my manager asked me to chair the backend weekly meeting and own the platform backlog. I was responsible for curating the backlog, tracking ongoing progress with the backend team every Monday, and managing comms with the platform users.

In first few months, I noticed that the platform backlog was somewhat static, very few things are being added every month or two. So I figured, what if I encouraged the team to divide-and-conquer on these tech debts in parallel to working on the upcoming sprints? Our backlog should be clean in a few weeks. 🧹

My assumption was wrong, obviously. I assumed that our new implementations would not generate any new tech debt, our tools would not push us to do any version upgrades, and no legacy code constraints would surface over time. Thinking of squashing all the debt is a positive approach, but not a realistic one.

So rather than thinking of debt as a finite set of tasks in a fixed bucket, think of it as an infinite stream of tasks, where the rate of change depends on how your teams operate. Following good design patterns and abstractions in writing code = fewer debt. Writing messy spaghetti code = more debt.

As long as you’re building new things, there will always be tech debt.

Why you should care

A technical debt can be defined as an issue in the codebase or infrastructure that makes it harder for engineers to introduce new changes.

Tech debt is sometimes viewed as a quality-of-life opportunity for engineers working on the product.

While the main goal should still be focused on the product roadmap for delivering business value. However, the engineers working on the roadmap should have the least amount of friction to do their work. Tech debt is a secondary backlog that accumulates over time, and neglecting it too often can harm developer productivity, reduce team morale, and eventually lead to engineers leaving.

A friend of mine who worked at a tech company once shared that the main reason she left her job, was the unwillingness from her team and leadership to address tech debt. She became frustrated working in an environment with broken tools, flaky tests, failing pipelines, and missing READMEs.

I empathise with her story. While delivering business value is always a priority, neglecting developer productivity too much ultimately slows down the engineering team. If businesses need to delight their customers, they’ll need to support their engineers.

However, on the flip side, not all tech debt is worth fixing. Some of them are nice-to-haves with no noticeable improvement to developer productivity. Possibly in 6–12 months, they can start to make a dent at developer productivity. At that time, we can pay down the debt. But for now, we should focus on shipping new features and make a note of these potential future dents.

We should only care about tech debt that improves our ability to deliver business value.

When to pay down tech debt

Going back to the platform backlog story, one day I received an email from Google Cloud Provider (GCP) announcing the deprecation of their Container Registry service and the migration to Artifact Registry. Since we were using the soon-to-be-deprecated service for storing images, I saw this as tech debt, a critical one. However, looking back, the email that was sent was only announcing a 2-year deprecation window. So by prioritising and pushing for immediate action amid all the other things we were working on was a hard sell, one that didn’t seem like a good idea. I raised it during our weekly backend meeting, had a good discussion, and took some notes. But the general consensus was, “Is this a problem we need to solve right now?” The answer was no.

So my advice is this: pay down tech debt for today’s problems and plan for 3-6 months. Focus only on those that will (A) increase developer productivity or (B) improve user experience.

To reiterate using ’s quote:

“The heuristic I use to pay tech debt these days is this: by reducing a specific tech debt, can I increase developer productivity and deliver business value right now?”

One thing I’d also avoid is solving far future problems, like the 2-year deprecation window I mentioned earlier. I reported something we should fix before March 2025 in February 2023. That’s over-engineering.

Over-engineering: Solving a far future tech debt (> 12 months).

If it requires action within 6 months, discuss and plan. If it’s 6-12 months, depends on the impact. If it’s 12+ months, that’s over-engineering.

Starter decision tree

If I could visualise an engineer’s decision-making about tech debt in the form of a decision tree, there would still be differences across different orgs. Some would have short binary trees (yes/no questions), while others would have deep B-trees, with each branch containing less obvious answers.

However, if I could picture an initial tree for a skilled engineer, it would look something like this:

This tree provides a set of simple questions to narrow down the problem into quick actions. Note that this is not a static tree to paying down tech debt. Engineers are responsible for continuously refining their decision-making process when assessing tech debt.

Take this starter tree as an inspiration and refine it as you go.

Your relationship with your product manager

The types of tech debt generated are somewhat similar across different tech companies, except for early-stage startups.

An early-stage startup is typically in the process of validating and finding its product-market fit (PMF). Product managers (PMs) are mainly focused on:

1. Identifying unmet needs in the market through customer research.

2. Developing a value proposition or hypothesis to be tested via an MVP.

In my view, a successful Product <> Engineering relationship is one where PMs can communicate an unmet user need, define a product vision and strategy, while engineers provide technical feasibility, review the roadmap, and build a solution. This is the most important relationship in any software company.

PMs trust engineers to deliver, while engineers trust PMs that their work serves the users.

In an early-stage startup, a product typically goes through multiple iterations (pivots), and so does tech debt. With each product iteration, new technologies or abstractions are introduced, codebase is rewritten, or architecture is redesigned.

If a product isn’t live and used by at least one customer, real tech debt hasn’t been created, and any previous debt isn’t worth discussing.

Once the product is live and being used by customers, then we can start measuring developer productivity. PMs trust your judgment as an engineer on highlighting impactful work that increases developer productivity and delivers business value. It’s important for both of you to be in sync so you can decide what should go on the priority backlog for the next sprint and what can be put on hold.

Invest in the PM <> Eng relationship. Staying in sync will make a PM’s decision tree for resolving tech debt similar to yours.

Wrap up

Paying down tech debts as an engineer require:

• Evaluating the maturity of the product and solving today’s problems.

• Being aware of over-engineering, i.e., solving far future problems (>12 months).

• Thinking critically about the engineering cost beyond the individual, considering the business impact as well.

• Building a relationship of trust and transparency with PMs to get buy-in.

One last thing: PMs trust your skills and opinions as an engineer. When discussing tech debt, make sure you highlight its relevance and impact on developer productivity so you both stay aligned while working on the product roadmap. Once you’re out of sync, discussions about tech debt will become ineffective and may raise eyebrows.

💬 Quick Note:

I recently launched a testimonial page for readers to share their thoughts about the newsletter, and I’d love to feature yours! You can add one through this link 🙌

Special thanks to Ingy E. for her latest testimonial!

If you’re finding this newsletter valuable, share it with a friend, and consider subscribing if you haven’t already.

Subscribe now

After working at five different companies that use Slack, I’ve realised that within an engineering culture, there’s also a Slack culture. A culture that reflects how effective and communicative a team can be. How they communicate ideas, progress, blockers, solutions, etc.

This is not research-backed, but here’s a thought experiment:

What if you could measure a team’s performance by observing their Slack channels?

Over time, they’ll develop some unspoken rules for communication to increase their team’s productivity. I believe you can spot a productive engineer by their written communication and how they use Slack.

So, here are 10 rules for efficient Slack communication.

#1 - Don’t overuse @here

When I worked at Dell, I was responsible for coordinating tech talks for engineering teams and regularly posted announcements for upcoming talks. A rookie mistake I made was pinging the channel with every announcement and inviting discussions, which ended up pinging every member for every reply. This created a noisy update, one I’d even mute myself.

Unless there’s an urgent update or a need for the team’s attention, using @here more than necessary will interrupt their deep focus time. A conversation thread that starts with @here generates lots of notifications, making it difficult for non-relevant participants to concentrate.

Be mindful of using @here. Only use if the entire group should engage.

#2 - Use threads for new conversations

Some people tend to go back and forth on a specific point, which ends up cluttering the channel. For example, my team once had a debate on Docker vs Podman (50+ messages). A good rule is to create a thread, tag the relevant people, and start the conversation there.

This provides a bird’s-eye view of all current and past nested conversations within the main channel. It’s super convenient for people who want to zoom in or out of any conversation they find relevant or interesting.

If Alice, Bob, and Charlie want to follow up on the $feature release, they know where to find it.

#3 - Add context to new messages

This rule is simple but essential. Messaging individuals without context creates awkward ambiguity and leads to longer discussions before issues are resolved. Receiving multiple “Hi”s from teammates makes it harder to distinguish what’s urgent, important, or easy to resolve.

So, instead of posting

❌ Hey there
❌ I have a question
❌ Are you free?

Take the time to write out your question or request:

✅ Hey, can we catch up on the new roadmap this week? I have a few questions about the second milestone.

#4 - Separate channel for a recurring topic

Having an all-in-one channel for all discussions can hurt the team’s productivity, making it harder to search for key details and organise conversations by category. If a topic keeps coming up with specific individuals, create a dedicated channel for it.

For example,

• Asking a team about backend services → #ask-backend

• Requesting support from QA engineers → #support-qa

• Discussing key details of a project → #project-awesome

#5 - Format links with bookmarklets

Over time, teams develop their own habits and tools for communicating over Slack. Sharing PRs, posting release notes, recording demos, etc.

A common one I found in previous companies, is using bookmarklets for PR reviews.

A bookmarklet is a JavaScript code snippet stored as a bookmark in a browser.

A bookmarklet is a small piece of code that runs on a web page to perform a specific action. For example, I can have a bookmarklet that copies the page URL and formats it into an [emoji][page title] for fun. Here is an example:

🌟 A concrete example of a bookmarklet is copy-pasting PRs to the team channel.

A good solution is to have a bookmarklet that generates a standard message with a PR link, including its state (open or draft) and diffs. Here are two examples: (1) GitLab and (2) GitHub.

Check out the repo below for using a bookmarklet for PRs:

🔗 https://github.com/shehab-as/bookmarklets

#6 - Cut down on previews

This is a biased opinion, but from experience, I’ve found that message previews create a lot of clutter. This is true in busy channels where important conversations are happening.

My colleagues and I have this unspoken rule of removing “visual noise” as much as possible when posting in the main channel. This includes previews from PRs, Notion, Shortcut, Jira, etc.

Try to minimise previews when posting links, especially if there are many.

#7 - Use Slackbot for reminders

Individuals with busy calendars tend to set reminders in Gmail or Outlook to keep things on track. Teams do the same with Slackbot, using it to set reminders and automate repeated tasks. This helps everyone stay organised and make sure nothing is overlooked.

Here are examples:

• 🔔 /remind #channel to share team updates every Friday at 3PM

• 🔔 /remind #channel to review open PRs every weekday at 9AM

• 🔔 /remind #channel to accept new interviews every Thursday at 3PM

• 🔔 /remind #channel to schedule a retro on the first Monday of every month at 1PM

#8 - Avoid lengthy channel names

This may seem like an obvious rule, but I still come across channels with long names that add little value. Naming channels shouldn’t be a big deal, but take a moment to trim down any unnecessary words.

Here are examples:

• ❌ #engineering-team-technical-discussions
  ✅ #eng-discuss

• ❌ #customer-bug-reports-and-tracking
  ✅ #bug-reports

• ❌ #hiring-and-referral-process-updates
  ✅ #hiring

There are only two hard things in Computer Science: cache invalidation and naming things.— Phil Karlton

I would also add—naming Slack channels—as another hard thing. 😬

#9 - Use tmp- for short-lived channels

Some projects require temporary collaboration from adjacent teams or individuals. These channels are short-lived, meant for only a few days or weeks. A good convention is to signal the liveness through the channel’s name.

tmp- channels are expected to be archived within days or weeks.

#10 - Use prefix for consistency

Channels with a common prefix can help visualise an engineering function and highlight relevant channels for engineers. This is especially useful for new joiners, who may find themselves lost in many channels without knowing which are most important.

Technical program managers (TPMs) or individuals working with multiple teams also find this valuable for coordinating and managing cross-team communication.

Using a prefix for all channels is not mandatory, but try to find a balance between convenience and clarity.

Bonus: #11 - Leverage Slack’s marketplace

🔗 https://slack.com/marketplace

Slack is more than just a messaging app. It’s a platform with many supported integrations and a marketplace full of apps for collaboration and productivity.

Take the time to explore the apps that work best for you and your team.

Some ideas for inspiration:

• Loom — Record demos or quick updates.

• Jira — Create and track team sprints.

• GitLab — Track CI/CD statuses and new MRs.

• Polly — Create quick polls for teams.

• Clockwise — Manage a busy calendar.

• Coffee & Donut Chat — Randomise coffee chats with the team.

One last thing: Posting a direct message to someone vs. in a channel can be seen as synchronous vs. asynchronous communication. If you need an urgent response, message that person directly (sync). If it’s not urgent, post it in the channel (async).

Or for clarity, you can signal this at the beginning of your message, like this:

✅ “(Non-urgent) Can someone look into the error logs?”
✅ “(Urgent) Can someone look into the deployment failure?”

Wrap Up

Teams love using Slack for day-to-day communication. They find new ways to boost productivity through app integrations, Slackbot, formatted links, and more. They have fun with emojis, GIFs, and memes. They pin announcements and links for quick access, and generally make everything easy to search.

To recap:

💬 Quick Note:

I recently launched a testimonial page (also known as Wall of Love) for readers to share their thoughts about the newsletter. I would love to feature yours! You can add one through this link 🙌

Special thanks to Kenny, Nim, Karim, Roxana, and Mark for their beautiful words!

Subscribe now

Subscribe now

Recap:

Note: companies might have specific requirements/responsibilities for their roles. Make sure to contextualise these estimates based on the role you’re applying for.

Behavioural Interviews

If you’re at this stage, congratulations! You passed the hard technical interviews. However, just because you have the behavioural interview left doesn’t mean you’re guaranteed an offer. Behavioural interviews can be the final piece hiring managers need to decide whether you get an offer or not, and at what level you should join.

So, by putting some effort into this final round, you increase your chances of getting an offer you want and can negotiate.

What is a behavioural interview?

It is a way for evaluating candidate’s experience and ability to perform based on their previous work. It also serves as a culture-fit test to see if the candidate will work well with the team.

Leadership roles (e.g., Staff) require a strong yes in behavioural interviews, just as much as system design (see preparation guide above). In the rest of this post, I’ll cover four key steps to help you prepare for behavioural interviews.

How to prepare:

1. Research the company

2. Use CARL for storytelling, lint with STAR

3. Speak to the level you’re applying for

4. No villains in your stories

1. Research the company

Say you have one day to prepare. First, check out the company’s website and take notes on what they’re doing (mission), what their future plans are (vision), how they plan to get there (strategy). Your goal is to get a rough idea of why this company exists, where it wants to go, and how you can contribute to its mission.

Second, research your interviewer(s). Check their LinkedIn profiles, see what they’ve been working on, and look for common ground. Any shared experience or interest can be a valuable discussion point during the interview. For example:

• You both worked at the same company before.

• You share interest or expertise in a specific area (e.g., platform engineering).

  • 🌟 Tip: Highlight this in your intro.

• You both enjoy reading The Proactive Engineer newsletter.

Your research doesn’t need to be a full-page paragraph, just a few bullet points and any questions you might have for the interviewer.

🌟 Tip: Don’t ask generic questions that can be found in the /about page of the company’s website.

Asking questions that make it seem like you don’t know what you’re applying for will give a bad impression. Do your research beforehand. Ask questions that give you insights into the company’s solution, team culture, and role expectations.

🌟 Tip: A good question doesn’t have a binary answer (yes or no).

Here are few examples:

❌ What is <company>?
✅ I’ve read that <company> does <solution>, could you tell me more about that?

❌ Do you need backend or frontend experience?
✅ Could you share more about the responsibilities or expectations of the role?

❌ Do you like working at <company>?
✅ What’s the one thing you enjoy most about working at <company>?

Coming prepared with questions and a sense of curiosity is a positive signal to the interviewers.

2. Use CARL for storytelling, lint with STAR

Now, when answering questions, you need to build strong behavioural responses by practicing how to communicate your past experiences. The key is storytelling.

The common advice on the internet is to follow the STAR method for storytelling. STAR is a way that lets you describe a situation you handled at work, providing key details for interviewers to assess your experience. It is an acronym for:

• Situation: What was happening, who was involved, and why it mattered.

• Task: What was your responsibility and what you needed to achieve.

• Action: What you did, how you did it, and why.

• Result: What was the outcome.

STAR is a good starting point, however I don’t recommend using it for all your responses because it lacks the character’s growth—you. As an interviewer, I am interested to hear about your stories and how you grew from each one of them. Lessons, insights, reflections, things you can take away from an experience.

So, instead I recommend using the CARL method. It is a refined version of STAR that allows you to describe the context you worked in, the actions you took, the results you achieved, and the learnings you’ve taken away. CARL is an acronym for:

• Context: [similar to Situation] Share context of what was happening.

• Action: [same] Explain what you did, how you did it, and why.

• Result: [same] Share the outcome.

• Learnings: [new] Share what you learned from the choices you made.

🌟 Tip: I previously covered a similar version (CARs) and how to write them in a Brag document for future behavioural interviews. For more, check out the post below.

Finally, here’s my strategy for preparing behavioural responses:

Step 1: Write down a few compelling stories from your previous work.

Step 2: Use STAR to lint or refine, make sure they have a clear structure.

Step 3: Repurpose them to CARL by highlighting your growth in each story.

I recently found ’s Substack, where he shares excellent advice on preparing for behavioural interviews. Austen was a Senior Engineering Manager at Meta and Chair of the hiring committee for iOS and Android pipelines.

Check out his recent discussion on approaching behavioural interviews:

I recommend checking out his newsletter: Mastering the Behavioral Interview

3. Speak to the level you’re applying for

I’ve been in hiring committees where we had candidates who were technically strong but received a lower-level offer based on their behavioural interviews. Frustrating as it sounds, but unfortunately that’s the case. Companies hiring for leadership roles (e.g., Staff) look for signs of strong decision-making in candidates’ responses about their past experiences. If a candidate provides shallow answers or spends too much time discussing lower-level details, committees will be cautious about putting that candidate in a critical role.

If I’m interviewing a senior candidate and the conversation tends to go more on lower-level topics, chances are the candidate will be hired at a lower level.

To fix this, focus on sharing stories that show growth and high-level thinking in your work.

• Mid-level: The features you’ve worked on and how you delivered them.

• Senior-level: The projects you’ve worked on and how you supported the team.

• Staff-level: The projects you’ve led and their organisational impact.

🌟 Tip: I can talk all day about how my team’s code is perfect and clean, but none of that matters if it doesn’t solve a user or a business problem.

Speak to the level you’re applying for. Don’t spend time on “small potato” topics like: code refactoring, what’s a good PR, what’s an ideal stand-up, etc.

4. No villains in your stories

Your goal is to pass the interview, get an offer, join the team, and do great work.

Your goal is not to badmouth your previous companies or create villains to make your stories more compelling. This will negatively impact your overall interview process. Some reasons are:

• You’ll certainly badmouth the new company if/when you decide to leave.

• You’ll signal a blame-culture attitude (e.g., “our project failed because <person> did not bla bla”).

• You’ll come across as difficult to work with, which is the last thing the team needs to worry about.

And in general, interviewers will question your “innocence” if all of your stories revolve around having villains at work.

Story time. Years ago, I once broke a platform’s observability by accident for a few days and no one noticed. As painful and awkward as this was, it created an opportunity for my team and me to re-evaluate our platform alerts, refine our incident response process, and improve our communication speed with users. I am the villain in this story, but the hard lesson here is the one takeaway worth sharing (Think CARL).

Every other person I’ve worked with has a similar “broke production” story, and none of them are villains. These incidents were just hidden opportunities waiting to be stumbled on by someone for improvement.

Focus on telling high-impact stories and new learnings. No villains. Even if you’re leaving because of a bad environment, frame your reason for leaving as looking for better opportunities and how the new company can offer that for you.

🌟 Final tip: Be authentic to your self. If you’re in the behavioural round, it means they value your technical skills and they want to see how you’ll fit in with the team. Come prepared and make it ridiculously easy for them to say yes.

Wrap up

As you advance in your career, behavioural interviews will become increasingly important, especially if you’re applying for a leadership role. So yes, soft skills are important for engineers.

To recap, four things to prepare:

1. Research the company

2. Use CARL for storytelling, lint with STAR

3. Speak to the level you’re applying for

4. No villains in your stories

Quick ask: If you enjoyed this three-part series, let me know in the polls below. Also, if you have a question or a topic you’d like me to cover in the newsletter, feel free to submit it through this form. 🙌

If you haven’t subscribed to the newsletter yet, make sure you do. 🙏

Subscribe now

Subscribe now

Preparation Recap:

Note: companies might have specific requirements/responsibilities for their roles. Make sure to contextualise these estimates based on the role you’re applying for.

System Design

System design interviews can be one of the most intimidating rounds for engineers. However, with the right preparation and practice they can become the easiest to crack. A system design interview is a design activity that allows engineers to demonstrate their knowledge and expertise in building systems, break down a large system into a functional MVP, and discuss requirements and trade-offs with other engineers (interviewers).

System Design is not a Q&A interview, it is a collaborative design session, and you’re the one leading it.

So, here are four key things to do to prepare for system design interviews:

1. Refresh on the fundamentals

2. Learn to scope

3. Start high-level, end with deep dives

4. Do mock interviews

1. Refresh on the fundamentals

One of the strong signals interviewers look for in a candidate isn’t just familiarity with technologies but a deep understanding of the core fundamentals that guide their technology choices. A strong candidate can design a system without being locked into a particular tech stack. And if they do choose a stack, they can justify its pros and cons. When doing the interview, be careful about throwing out a lot of technology names without logical reasoning.

Here are two good/bad examples of designing a solution:

❌ I’ll use a MongoDB because it’s “fast” and “easy to scale”.
✅ Given the data locality imposed by the system, I’ll use a NoSQL database.

❌ Scaling Database? We can do data sharding using AWS’ RDS (Aurora Limitless).
✅ Depending on the read/write ratio, if query performance is already optimised with indexing, we can introduce a leader-follower cluster, creating read replicas for read-heavy paths and a single master for write-heavy paths.

So what are the fundamentals?

Imagine there are three foundational layers beneath Technologies, representing the Fundamentals. These are:

1. Core Concepts

2. Protocols / Interfaces

3. Patterns / Techniques

The boundaries don’t matter; they highlight topics in specific areas like networking, protocols, data formats, and communication patterns. Technologies are solution offerings from different companies (e.g., cloud providers like AWS, Azure, and GCP) that solve a fundamental problem using a specific technology.

That’s why when candidates say they’ll use an object storage in their design—an S3 bucket or GCP bucket—I don’t care which technology they pick. I care that they pick the right solution for the problem (an object storage).

Interviewers look for signals of your knowledge depth beyond Technologies, so deepen your understanding of the Fundamentals to confidently explain any layer of the stack during the interview. They also help you make better decisions during the system design interview. Focus on the problem, not the technologies.

🌟 Tip: Technologies change over time. Fundamentals stay the same.

Here are two examples of topics around Technologies/Fundamentals:

Take the time to refresh on the fundamentals and deepen your expertise in a specific area that interests you. That could be working with databases, networking, security, etc.

🌟 Tip: Interviewers look for breadth and depth in the design, make it easy for them to see that.

2. Learn to scope

This one is similar to task-based interviews, covered in the Coding post:

Learning how to scope (i.e. gather requirements) is critical in a system design interview. When asked to design a system, you need to think about:

1. Functional requirements (FR): Core features/functionalities of the system.

2. Non-functional requirements (NFR): Attributes of the system.

For example, designing a system like Uber will have something like:

1. FR: Users can request rides to a specific location.

2. NFR: Real-time data (Uber should support live tracking)

🌟 Tip: NFRs usually end with -ility (e.g., Scalability, Availability, Reliability). However, only mention those that are important and relevant for your system. Don’t list them out without purpose.

Practice taking ambiguous systems and gathering requirements for each one. You’ll find lots of examples in the study resources down below.

3. Start high-level, end with deep dives

Once you’ve gathered the requirements for a system, start designing an end-to-end working solution (sharing your thought process) at a high level, and then dive deep into 1-3 technical components at the end.

Your approach should be to:

1. Satisfy the FRs via high-level.

2. Satisfy the NFRs via deep dives.

To illustrate, here are two examples of how to approach a system design interview question.

Example #1 - Spotify

Design Spotify: a music streaming platform where users can search for songs, play music, and create playlists.

Step 1: Scope the system

Step 2: Design a high-level solution

Step 3: Go through 1-2 deep dives:

• Search Service: How to build a search engine for songs, artists, and albums.

• Play Service: How to handle traffic spikes for song streaming.

• Play Service: How to handle traffic spikes for top-10 hits.

• Play Service: How to handle buffering and adjust quality based on network conditions.

• Playlists Service: How to sync users’ playlists in real time across different devices.

Interview #2 - Design YouTube

Design YouTube: a video streaming platform where users can upload, search, and watch videos.

Step 1: Scope the system

Step 2: Design a high-level solution

Step 3: Go through 1-2 deep dives:

• Watch Service – How to handle users with low internet connections to ensure smooth video streaming.

• Watch Service – How to handle traffic spikes during peak usage times.

• Video Processor – How to handle corrupted videos and generate different qualities.

4. Do mock interviews

Mock interviews are a great way to practice system design interviews and get feedback from others. That can be a friend, mentor, colleague, etc.

Benefits of doing mock interviews is that they help you understand:

• Your approach to gathering requirements

• How you communicate ideas to engineers

• Where you get stuck on the technical components

• How you handle “Bar raiser” questions or direction shifts

If mock interviews aren’t an option, try to set aside 45 minutes of deep focus time to work through an interview question on your own. You can record yourself if you want to simulate an actual interview with you speaking.

📖 Study Resources

• If you’re in a hurry, read System Design intro by HelloInterview

• Highly recommend System Design Interviews by Alex Xu and Sahn Lam

• Designing Data-Intensive Application, excellent resource for distributed systems.

• Checkout Hello Interviews Playlists on YouTube, phenomenal walkthroughs by Evan King and Stefan Mai.

• Fundamentals of Software Architecture, a great intro to architectural thinking.

⭐️ Final tip: You only learn if you try. So don’t consume all these resources without actively practicing.

Wrap up

Take a vague system design problem, narrow it down to a set of functional (FR) and non-functional (NFR) requirements, design the solution end-to-end on a high-level, and end with 1-2 deep dives. If you find any knowledge gaps during interview practice, take notes of the topics/areas and study them.

There’s no secret formula for “mastering” system design interviews. A system design interview can go in a million direction. The more you prepare, the more confident you’ll become in tackling ambiguous problems. So, practice, practice, practice.

To recap:

1. Refresh on the fundamentals

2. Learn to scope

3. Start high-level, end with deep dives

4. Do mock interviews

If you’re finding this newsletter valuable, share it with a friend, and consider subscribing if you haven’t already.

Subscribe now

Subscribe now

Preparation Guide

First, let’s break down the preparation time for each interview based on engineering experience.

Note: companies might have specific requirements/responsibilities for their roles. Make sure to contextualise these estimates based on the role you’re applying for.

Important insights:

1. Junior / Fresh Grads should focus on their problem-solving skills through programming and on explaining their thought process. Having general system / software design knowledge is a plus.

2. Mid-Level Engineers are expected to have some experience working with production-grade systems. While coding remains a priority, they should invest time in preparing for system design and behavioural.

3. Senior Engineers cannot pass solely on coding (only 40%). They are expected to demonstrate strong system design skills and communication skills. Some companies also expect them to operate as a tech lead or mentor to juniors, so they might be asked leadership questions in their behavioural interviews.

4. Staff Engineers is the first rung on the leadership ladder. They are expected to demonstrate deep technical expertise in system design and leadership in behavioural interviews. A candidate with:

   strong system design + strong behavioural + okay coding = yes

5. Principal Engineers’ preparation is harder to pin down since it depends on their industry expertise and the business needs. However, their main role is to shape the company’s technical direction, so the focus should be on demonstrating organisational impact and deep technical expertise relevant to the role.

Note: Some companies merge or expand roles based on their structure. Staff/Senior engineers are often labeled as Tech Leads. Mid-level engineers may be divided into multiple levels, such as E3/E4 at Meta or SDE II/III at Amazon.

Part One: Coding Interviews

There are two types of coding interviews:

1. Algorithmic

A standard interview to evaluate a candidate’s knowledge of data structures, algorithms (DSA), and complexity analysis through coding problems.
Examples: Binary Search, String Manipulation, Tree Traversal, etc.

2. Task-based

An exercise (or take-home assignment) to evaluate a candidate’s knowledge through application development. Ideal for assessing specific roles such as Backend, Frontend, and DevOps.
Examples: CRUD Applications (e.g., ToDo App), Web Scrapper, etc.

I. Algorithmic Interviews

More common in big tech and large companies than in small ones and startups.

Algorithmic interviews are the standard for assessing CS graduates and junior engineers. These interviews are great for testing the foundations like data-structures and algorithms, Big O analysis, object-oriented programming, design patterns, etc.

Since these candidates don’t have much production experience, companies rely on algorithmic interviews to evaluate their problem-solving skills and their understanding of core software engineering principles.

Four Things to prepare for Algorithmic Interviews:

1. Data-structures and Algorithms (DSA)

2. Time and Space Complexity (BigO)

3. Thinking Vocally

4. Practicing Pattern Recognition

1. Data Structures and Algorithms (DSA)

First things first, you need to learn your data structures and algorithms before attempting to solve problems. They are the backbone of building efficient software.

You should be able to explain what a data structure does, when it’s useful, and how to use it.

For example, understanding why searching for a value in a Python dictionary is faster than in a list, and knowing their underlying data structures.

Data-structures to study:

> Arrays & Linked Lists (Singly, Doubly, Circularly)
> Stacks (LIFO-order) & Queues (FIFO-order)
> Hash Tables (Hash Maps/Sets)
> Trees & Tree Traversals (PreOrder, InOrder, PostOrder)
> Binary Search Trees
> Graphs
> Heaps (Min/Max Heaps & Priority Queues)
> Tries

You should also learn the algorithms that operate on the data within these structures — how each algorithm works (e.g., searching, adding, removing), when it’s useful, and its cost (time and space complexity).

Algorithms to study:

> Search Algorithms (Binary Search, Breadth-First, Depth-First)
> Sort Algorithms (Bubble Sort, Merge Sort, Quick Sort, etc.)
> Dynamic Programming (DP)
> String Algorithms (Longest Common Subsequence (LCS), Tries, etc.)
> Graph Algorithms (Topological Sort, Dijkstra's, A* Search, etc.)
> Two Pointers & Sliding Window Technique

You can search for online resources like GeekforGeeks that covers these algorithms.

Note: I also covered some of the data-structures in my old posts during uni. Here’s one on Binary Search Trees.

2. Time and Space Complexity (Big O)

A common mistake that some candidates make is coding up a solution, without knowing how long will it take and how much memory it needs.

Time and space complexity are measurements of how much time and memory an algorithm needs to run as a function of the amount of input it receives.

Understanding Big O is critical for software engineers. Choosing the right algorithm can make the difference between a program that runs in seconds and one that takes hours or even days. Make sure you’re able to analyse and justify the complexity introduced in your algorithms.

A candidate who is able to analyse their algorithms and explain trade-offs in time and space complexity is a positive signal.

3. Thinking Vocally

One common mistake I find with candidates during interviews is when asked to solve a specific challenge, they jump into implementation without thinking vocally.

Thinking vocally is verbalising your thought process out loud while working through a problem. This allows you to show to your interviewer/future teammate your reasoning and logical steps when solving a problem.

A candidate who communicates ideas clearly and explains their approach is a positive signal.

4. Practicing Pattern Recognition

Pattern recognition is when you solve many problems around a specific topic (e.g., dynamic programming), and in the process, you develop a pattern for recognising the need for an algorithm (e.g., memoization technique) based on the problem description.

The more you practice, the more you train that pattern recognition muscle.

A common mistake that candidates do is open a coding platform (eg., LeetCode) and attempt to solve all Easy problems, then move to Medium problems, and so on. This isn’t practical because A) You don’t have an infinite amount of time, and B) Your job is not to LeetCode.

Here’s my practice strategy:

1. Pick a category (e.g., string manipulation) and select a problem.

2. Spend ~30 minutes on it—try to solve it using the naïve approach, then improve.

3. Look up online solutions and understand how it differs from yours.

4. Revisit the problem few weeks later and solve it again.

5. Repeat this for 2–5 problems per day.

This strategy helped me pass Microsoft and Amazon interviews after six weeks of preparation.

Note: The preparation time depends on how much time you can allocate per day. Some candidates take anywhere from 4 to 12 weeks to prepare.

📖 Study Resources

1. Highly recommend reading HelloInterview.

2. LeetCode is a great platform for practicing problem-solving (by category!).

3. A detailed explanation of 250 problems: Elements of Programming Interviews (C++ edition)

   • Also available in Python edition.

4. A great resource for learning how to solve DSA questions (189 problems) Cracking The Coding Interview, 6th edition by Gayle Laakmann McDowell.

5. An excellent reference for your bookshelf Introduction to Algorithms (by C.L.R.S.)

Disclaimer: Junior / Fresh Grads might be asked more on CS topics beyond DSA like OOP, Design Patterns, SOLID principles, etc. Or to design (not code) a software application (as a replacement for system design interview) like Chess, Book Library, etc.

🌟 Tip: If you’re not sure, email your recruiter and ask what to expect in the interview.

II. Task-based Interviews

More common in early-stage startups and small to mid-sized companies than in big tech.

Task-based interviews come in different forms depending on the company’s domain and are often tailored to specific roles like Backend, Frontend, DevOps, etc.

This format is primarily designed for experienced software engineers (and occasionally fresh grads) to assess their ability to solve real-world problems using a tech stack. Two examples are:

Book Catalog API (eg., Goodreads https://www.goodreads.com/api)

Build a simple REST API that allows users to manage book catalogs.

• Adding a new book with a title, author, and publication year

• Fetching a list of books

• Searching for books by title or author

• Deleting a book by ID

Project Management API (eg., Jira API)

Build a minimal API for managing projects and tasks.

• Allow users to create, update, and delete projects / tasks.

• Retrieve project / task information.

• Mark projects / task as completed

• Retrieve a list of all projects / tasks.

Four Things to prepare for Task-based Interviews:

1. Get Comfortable With Your Tools

2. Learn To Scope

3. Build Personal Projects

4. Read As You’re Building

1. Get Comfortable With Your Tools

One of the goals in task-based interviews is to see how you work as an engineer—how you set up your development environment, which tools/languages/frameworks you use, how you test your solution, how you use documentation, etc.

The first step is to pick a stack you’re interested in (e.g., Python, React, PostgreSQL, Docker, AWS) and practice developing applications while learning about best practices.

Don’t waste time on “mastering” multiple languages. Pick one language you’re comfortable with and deepen your knowledge and expertise in it.

2. Learn to Scope

Some interviews will intentionally give you a vague task to solve. Your role is to ask follow-up questions to gather requirements and make sure you’re clear on what you need to build.

Say you’re asked to implement Amazon Gift Cards API.

Some follow up questions are:

• What are the core features of the Gift Cards API? (e.g., create, redeem, check balance, deactivate)

• What information should be stored for each gift card?

• Are there any expiration rules for gift cards?

• What happens if a user tries to redeem an expired or deactivated gift card?

If you’re making some assumptions, be sure to communicate them back to the interviewer. This helps validate the scope and requirements you’ve gathered. Once everything is clear, you can start building the solution.

🌟 Tip: Make sure to test your solution during the interview. If time runs out, explain your testing strategy out loud and highlight any improvements you would have made if you had more time.

3. Build Personal Projects

To build confidence in task-based interviews, you should be comfortable with:

1. Designing and building CRUD apps, interacting with databases, etc.

2. Testing and debugging apps, integrating third-party APIs, etc.

3. Deploying and monitoring apps.

Building a personal project allows you to go through this cycle. The more you build, the more capable you become. Think of any project or idea you’re interested in, and build a small version of it. Be careful of tutorial hell (i.e., watching tutorials all day without building)

Here’s an inspiration:

1. Budget Tracker – Build an app to track expenses, predict future spending (maybe plug-in an ML model?), visualise monthly spending, etc.

2. Sports Bracket Generator (e.g., Premier League) – Learn how to integrate a Sports API to generate tournament brackets and display live updates for your favourite sports.

3. Messaging App (e.g., WhatsApp) – Learn how to build real-time messaging using WebSockets.

🎁 Practice Test: Here is a document for a project idea, Gift Cards.

🌟 Tip: Having your personal projects available on GitHub is a strong signal in your resume and an opportunity for others to see your quality of work.

4. Read as You’re Building

As you build personal/work projects, you’ll encounter various engineering topics that will challenge you to deepen your understanding, gaining both knowledge and hands-on experience.

Some of these topics are:

• API design: learning about REST, GraphQL, gRPC, and SOAP.

• Testing: Unit vs. integration testing, white vs black box testing, etc.

• Storage: SQL vs. NoSQL, ORM, indexing, isolation levels, transactions, etc.

• Deployment: CI/CD, deployment patterns, and strategies for scalability.

• Observability (o11y): Using logs, metrics, traces, and OpenTelemetry (OTel)

• Performance: Load testing, profiling, and optimisation techniques.

• Security: Data validation & sanitisation, AuthN vs. AuthZ.

• AuthN & AuthZ: token (JWT) vs. session (cookie), OAuth 2.0, SAML, etc.

• Cloud Deployment: EC2 vs Lambda (Serverless) for app hosting.

• Container Orchestration: Kubernetes (K8s) vs. managed service (EKS vs. ECS).

Going through all of them during the interview is not possible. However, be prepared to discuss any of them. I’ve found that reading + hands-on experience from building applications is the best way to internalise new concepts over time.

Wrap up

Tech interviews may include both algorithmic and task-based rounds. In general, these are the two main approaches companies use to evaluate candidates, so make sure to practice both.

If you’re finding this newsletter valuable, share it with a friend, and consider subscribing if you haven’t already.

Subscribe now

Whenever I’m working on a project, I like to first break it down into milestones and see which ones can be shared in the form of demos with relevant stakeholders. This helps me build trust and manage expectations with them. But there’s more to it. Some of the top-performing teams I know or have worked with, believe in having a demo-driven culture within their engineering teams. Below, I’ll share five reasons why.

Examples of demos are:

• Demoing a work-in-progress feature in a website / mobile app.

• Using a Jupyter Notebook to call newly developed APIs.

• Running a set of instructions on the terminal.

1. Fewer meetings

Time is an expensive currency. The more meetings you schedule to share updates, the more expensive it becomes for your technical delivery. Stakeholders can be internal—Engineering Managers, Directors, VPs, CTOs—or external, like new customers.

What if there was a way to cut down meetings to N-1 (or reduce their length) without losing the flow of information? In my experience, demos can do just that.

Say you have a 1-hour weekly meeting to share progress with leadership, with 40 people on the call. That’s 40 hours spent on that meeting every week.

What if we kept the updates short and sweet by demoing something that gives a clear status update without too many verbal details? So,

1. If we trimmed that meeting to 30 minutes, that’s 20 hours saved / week.

2. If we switched to a bi-weekly meeting instead, we’d get back the full 40 hours once every two weeks.

Think about how demos could help in your context. And ask around—would your team appreciate that?

2. Visuals

When preparing for a demo, it’s important to think about your audience and identify the key elements that will help you effectively share progress. One of those elements is visuals.

Most people generally enjoy visuals—they tend to engage more with project updates when they feel tangible, especially if they’re product-specific.

I’ve worked with product managers and designers who found visual demos invaluable, allowing them to pinpoint areas for questions or feedback without diving into technical details.

For example, the goal isn’t to explain how GraphQL works to non-technical individuals but to show how we’re using it to solve a problem—and what that looks like in practice.

That being said, visuals aren’t everything; they’re just one element to consider for your audience. Visuals help you explain:

• The previous state

• The current state

• The future state

I once presented a demo to non-technical stakeholders by simply sharing my code editor and highlighting some Python and configuration files. It was well received—because I was able to clearly explain the three states above relevant to them.

3. Easy to share

One time I worked on a project where the main document was presented as:

# Milestone 1            # Milestone 2
- Goals                  - Goals
- Demo (link)            - Demo (link)

# Milestone 2            # Milestone 4
- Goals                  - Goals
- Demo (link)            - Demo (link)

The way all the project details were centralised made it easy for anyone to follow up without needing to ask around. A recorded demo could be shared across multiple channels if needed, allowing stakeholders to skim through or speed it up to 2x when necessary.

Tip: This is one of the most effective ways to onboard new members onto a project.

4. Team engagement

While this point aligns with themes like inclusion and team empowerment, another key reason is to maximise team engagement.

Technical demos often require engineers to present their work. The goal isn’t just to share an engineer’s screen and click around to show progress. Rather, it’s an opportunity for engineers to explain their work and how it connects to the problem stakeholders care about. If engineers can articulate the purpose of the demo and how it functions, stakeholders can ask more specific questions—maximising team engagement.

5. Faster feedback loops

If I were asked to share a project update, some of my general options would be:

• Writing a document and sharing it via email.

• Scheduling a meeting and sharing it verbally.

• Posting a TL;DR message on Slack/Teams.

• Scheduling a meeting for a demo.

• Sharing a recorded demo.

All of these are viable options, but their value depends on the situation and the type of people requesting the update. Sometimes, your manager just needs a one-sentence update for a slide. Other times, your users want a preview of that new feature.

Demos (4 & 5) are particularly useful for collecting feedback from both technical and non-technical audiences. If your goal is to share progress and gather feedback—do a demo!

Conclusion

Demos are not only a useful way to build trust and relationships with stakeholders; they also increase your project's success rate. Cultivating a demo-driven culture strengthens collaboration between technical and non-technical parties and brings clarity to discussions when delivering projects.

To recap, here are the five reasons:

1. 𝐅𝐞𝐰𝐞𝐫 𝐦𝐞𝐞𝐭𝐢𝐧𝐠𝐬: Demos reduce back-and-forth discussions with stakeholders.
2. 𝐕𝐢𝐬𝐮𝐚𝐥𝐬: People tend to engage more with visual updates.
3. 𝐄𝐚𝐬𝐲 𝐭𝐨 𝐬𝐡𝐚𝐫𝐞: A recorded demo/meeting can be shared across multiple channels if needed.
4. 𝐓𝐞𝐚𝐦 𝐞𝐧𝐠𝐚𝐠𝐞𝐦𝐞𝐧𝐭: Engineers can present their work to stakeholders and answer any immediate questions, maximising team engagement.
5. 𝐅𝐚𝐬𝐭𝐞𝐫 𝐟𝐞𝐞𝐝𝐛𝐚𝐜𝐤 𝐥𝐨𝐨𝐩𝐬: Stakeholders can provide specific feedback much easier on the presented work, creating faster feedback loops.