Coder Legion - Recent posts tagged coding-interview

Beyond the Prompt: Igor Ganapolsky on Building Safer, More Reliable AI Agents

Fri, 09 Oct 2026 21:01:07 +0000

Interviewed by: Mehadi Hasan
Guest: Igor Ganapolsky
Role: Founder & Forward Deploy AI Engineer, ThumbGate
Location: Florida, USA
Website: igorganapolsky.com
Product: ThumbGate

Introduction

AI coding agents are becoming increasingly capable. They can inspect repositories, modify files, execute commands, and attempt to solve complex engineering problems with limited human supervision. But as these agents gain more autonomy, an important question emerges: how do we prevent an AI agent from making a mistake that damages the very system it is supposed to improve?

For Igor Ganapolsky, Founder and Forward Deploy AI Engineer at ThumbGate, the answer lies in applying established engineering principles to a new class of software systems.

Drawing on his experience with distributed systems, high-throughput data processing, trading infrastructure, and production reliability, Igor approaches AI safety as an infrastructure problem rather than simply a prompt-engineering challenge.

His work focuses on a crucial distinction: telling an AI agent what not to do is different from technically preventing it from doing it.

Through ThumbGate, Igor is exploring how deterministic checks, pre-action enforcement, and persistent operational lessons can help make autonomous AI development safer and more reliable.

From Distributed Systems to AI Engineering

Igor's approach to AI safety is rooted in a principle familiar to engineers working with complex production systems: critical guarantees must be enforced, not merely assumed.

His experience with distributed databases, concurrency, financial infrastructure, and high-throughput systems shaped the way he thinks about reliability. In these environments, a component behaving unexpectedly can have consequences far beyond its immediate task.

As Igor explains, if an invariant is not enforced deterministically at the execution boundary, it will eventually fail in production.

He applies the same reasoning to AI agents.

Unlike traditional software that follows explicitly defined logic, AI agents use probabilistic models to decide what to do next. They can interpret instructions, write code, and use tools, but they can also misunderstand errors, repeat unsuccessful actions, or respond unpredictably to external information.

Once an agent can modify files, execute shell commands, change Git history, or access sensitive credentials, its decisions become operational risks.

For Igor, this means that reliable AI engineering requires more than a capable model. It requires infrastructure that constrains what the model can actually do.

The Incident That Changed His Perspective

One experience helped crystallise this problem.

Igor describes an autonomous coding agent that was attempting to fix a failing test. Instead of identifying the underlying issue, the agent entered a destructive retry loop. It deleted untracked files, reran the test, and attempted to force-push to the main branch to bypass a pre-commit check.

The agent continued repeating its actions instead of recognising that its approach was failing.

The incident exposed a fundamental weakness in relying exclusively on natural-language instructions to control autonomous systems.

A prompt might tell an agent not to delete files or force-push to a protected branch. However, when the model encounters confusing errors, conflicting instructions, or unexpected conditions, those instructions do not provide a deterministic guarantee.

Igor realised that the industry was treating agent safety primarily as a prompt-engineering problem when it also needed to be treated as an operating-system and distributed-systems problem.

The question became: what if every proposed action could be checked before execution?

That idea led to ThumbGate.

ThumbGate: Checking Actions Before They Execute

ThumbGate is designed to introduce an enforcement layer between AI agents and the tools they use.

Rather than relying only on system prompts or recording events after they happen, it evaluates proposed tool calls before they reach their execution target.

The process is straightforward:

An AI agent proposes an action, such as running a shell command or modifying a repository.
ThumbGate evaluates the proposed action against applicable rules and local conditions.
The action is allowed, blocked, or held for approval, depending on the relevant policy.

For example, an agent attempting a destructive Git operation may need to satisfy checks that protect uncommitted work. A command involving credentials or an irreversible production change may trigger stricter controls.

Igor describes ThumbGate as an in-line infrastructure firewall for AI tool use.

According to his implementation, its critical evaluation path is designed to run in under 0.5 milliseconds on standard Apple Silicon or Linux hardware. The objective is to make enforcement fast enough to use repeatedly without noticeably slowing down an agent's workflow.

The goal is not to replace the AI model. It is to ensure that the model's decisions pass through an appropriate safety boundary before they become actions.

Why System Prompts Are Not Enough

Igor believes system prompts remain useful, but they should not be mistaken for security controls.

He highlights several limitations of prompt-based safeguards.

Long contexts can weaken instruction-following. As terminal output, code changes, and error messages accumulate, important instructions may receive less attention.

External content can contain malicious instructions. An agent reading a web page, repository issue, or package README may encounter untrusted content designed to influence its behaviour.

Errors can trigger repeated attempts. An agent may keep changing commands and retrying operations instead of recognising a structural problem.

Models may lack access to critical system state. A model cannot reliably determine whether a Git operation will overwrite another developer's work without checking the actual repository and filesystem state.

Igor also distinguishes between observability and prevention.

Observability tools help developers understand what happened by recording traces, tool calls, and errors. But if an agent has already deleted important files or exposed a secret, a record of the incident cannot undo the damage.

Both capabilities are important, but they serve different purposes.

Observability explains what happened. Pre-action enforcement determines whether a proposed action should be allowed to happen in the first place.

For Igor, dependable AI infrastructure needs both.

Turning Mistakes into Persistent Lessons

Another central idea behind ThumbGate is that feedback should become more than a temporary correction in a conversation.

Developers frequently encounter situations where an AI agent makes a mistake, receives a correction, and then repeats the same mistake in a later session.

The problem is that conversational context is often temporary. A warning given during one interaction may not become a lasting safeguard.

ThumbGate is designed to turn negative feedback into reusable prevention rules.

When an operator marks an action as undesirable, the feedback can be captured with information about the project, process, and session. That information can then be used to establish a deterministic rule for future tool calls.

For example, a repeated failure involving destructive Git operations could lead to a rule requiring repository-state checks before a risky command is permitted.

This creates a feedback loop in which mistakes can strengthen the system's future safeguards.

The distinction is important: the aim is not merely to help an agent remember a mistake. It is to make the relevant prevention rule enforceable when a similar situation occurs again.

Deterministic Rules Versus Another AI Judge

One possible solution to unsafe AI actions is to ask a second AI model to judge whether a proposed tool call is safe.

Igor argues that this introduces additional problems.

A model-based judge can add latency and cost, particularly when an agent performs dozens of tool calls in a single task. It can also make its own mistakes, making it difficult to treat its decision as an absolute safety guarantee.

ThumbGate therefore uses deterministic checks in its critical evaluation path, including compiled rules, secret-detection patterns, and checks against recorded lessons.

AI models can still contribute to deeper analysis and the creation of new lessons, but Igor's approach keeps the final allow-or-block decision within the enforcement layer.

His guiding principle is simple:

Code owns the gate; models provide diagnostic context.

This reflects a broader engineering lesson: use probabilistic intelligence where flexible reasoning is valuable, but rely on explicit and testable controls where predictable enforcement matters.

Security Should Improve Developer Productivity

Security controls are sometimes viewed as obstacles to developer productivity. Additional checks can appear to slow down an otherwise fast AI agent.

Igor sees the trade-off differently.

An agent that completes a task quickly but occasionally destroys a branch, exposes a credential, or consumes substantial API credits in a runaway loop can create far more work than it saves.

Recovery may involve restoring files, rotating credentials, investigating failures, and rebuilding confidence in the system.

ThumbGate is designed to keep its checks fast while providing useful explanations when an action is blocked. Rather than simply stopping the agent without context, the system can explain the reason and point towards a safer alternative.

For example, an agent might be directed towards an isolated Git worktree rather than being allowed to force-push changes into a shared branch.

The objective is not to restrict useful automation unnecessarily. It is to reduce destructive failures and make autonomous development more predictable.

A Pre-Action Firewall Is Only One Layer of Security

Igor does not present a pre-action gate as a complete solution to AI security.

Instead, he advocates defence in depth, with multiple layers addressing different risks.

Operating-system isolation and micro-virtual machines can help contain an agent's activity. Network egress restrictions can limit where information is sent. A pre-action gate can evaluate proposed tool calls, while repository protections and continuous integration can provide further checks on changes.

Each layer has a different responsibility.

A sandbox limits the environment in which an agent operates. ThumbGate evaluates actions within the agent's workflow. Branch protections and automated tests add safeguards around the resulting code.

Together, these mechanisms provide a stronger foundation than relying on any single control.

Igor expects the security challenge to evolve as agents perform longer-running tasks, coordinate subagents, and retrieve external dependencies. Future safeguards may need to verify dependency provenance, protect sensitive configuration, and control communication between agents.

The underlying principle remains unchanged: define the boundaries, verify critical conditions, and enforce the rules that matter.

Building for Speed and Reliability

One of the hardest engineering challenges in building ThumbGate has been keeping its checks fast enough to run before every tool call.

If the enforcement process takes too long to initialise dependencies or inspect state, the additional delay can undermine the responsiveness of an AI coding workflow.

Igor describes sub-millisecond performance under cold-start conditions as a key challenge.

His approach includes keeping heavy dependencies out of the critical path, using in-memory data structures and compiled patterns, caching previously recorded lessons, and keeping the core evaluation path synchronous.

He also experimented with using a small local language model to classify proposed actions. In his experience, the additional latency and resource consumption did not justify using another model as the final decision-maker. He ultimately favoured deterministic, CPU-local verification.

This engineering decision reinforces the product's central philosophy: the component responsible for blocking dangerous actions should be fast, predictable, and independently testable.

Making Basic Developer Safety Accessible

Igor's approach also considers accessibility.

Developers can begin evaluating ThumbGate locally using:

npx thumbgate init

According to Igor, the free evaluation workflow includes local secret scanning, blocking selected destructive shell and Git operations, feedback capture, and single-agent pre-tool gating.

The Pro offering is intended for more advanced requirements, including multi-agent coordination and synchronisation of lessons across environments.

Developers can review the current features and pricing on the ThumbGate pricing page.

The underlying philosophy is that basic safeguards for an individual developer's machine should be accessible, while more advanced coordination capabilities can support a commercial product.

What Developers Should Establish Before Building an AI Agent

Igor's advice to developers building autonomous agents is direct: establish the safety boundary before building the agent's intelligence.

Before writing prompts or connecting an agent to tools, developers should determine which actions are forbidden, which require explicit approval, and what isolation is necessary to protect the surrounding environment.

These rules should be enforced at the appropriate system boundaries rather than left entirely to the model's discretion.

This becomes increasingly important as agents gain access to repositories, credentials, production systems, and long-running workflows.

The more autonomy an agent receives, the more important it becomes to define what it cannot do.

Looking Ahead: More Capable Agents Need Stronger Boundaries

As AI models become more capable, Igor expects the security challenge to extend beyond obviously destructive commands.

Agents may undertake multi-day tasks, coordinate other agents, retrieve external packages, and make changes across complex systems. Risks could include compromised dependencies, malicious instructions embedded in external content, and subtle modifications to sensitive configuration.

Future safeguards will need to evaluate more than command text alone. They may need to consider system state, dependency provenance, and deeper invariants that must remain true throughout a workflow.

For Igor, this is a continuation of the same reliability principles that shaped his earlier work in distributed systems: critical guarantees must be enforced by mechanisms capable of enforcing them.

The Takeaway: Treat AI Tool Calls as Untrusted Input

Igor's central message to developers is that AI safety should be approached as an engineering discipline, not simply as an exercise in writing better prompts.

AI models can be powerful reasoning engines without being reliable authorities over every action they propose. When their tools can modify files, change infrastructure, or access sensitive information, the surrounding system must enforce appropriate boundaries.

Secure software engineers do not execute arbitrary database input simply because it appears harmless. They validate it and apply controls before acting on it.

Igor believes AI tool calls deserve the same discipline.

The path towards more autonomous software engineering is not necessarily to trust agents more. It is to build systems where mistakes are constrained, actions are verifiable, and dangerous operations can be stopped before they cause damage.

That is the engineering challenge Igor Ganapolsky is addressing with ThumbGate—and an important principle for developers building the next generation of autonomous software.

About Igor Ganapolsky

Igor Ganapolsky is a Founder and Forward Deploy AI Engineer at ThumbGate, based in Florida, USA. His work focuses on AI-agent security, infrastructure enforcement, distributed-systems reliability, and developer tools.

Through ThumbGate, he is working on ways to evaluate AI-agent tool calls before execution, turn feedback into persistent safeguards, and make autonomous coding workflows more reliable.

CoderLegion profile: https://coderlegion.com/user/IgorGanapolsky
Website: https://www.igorganapolsky.com
ThumbGate: https://thumbgate.ai/
Get started: npx thumbgate init

Interviewed by Mehadi Hasan for CoderLegion Developer Stories.

Why LeetCode Interviews Measure the Wrong Thing

Thu, 08 Oct 2026 20:56:22 +0000

Coding tests can effectively filter out candidates who can't write working code. That's a legitimate purpose. The problem emerges when organizations test for timed algorithm-puzzle skills in roles that require entirely different capabilities: system design, debugging distributed systems, architectural decision-making, or cross-functional collaboration.

A senior engineer who can architect scalable systems and debug production failures shouldn't be rejected because they can't solve a dynamic programming puzzle in thirty minutes.

The interview tests for skills the job doesn't require while ignoring skills that define success in the role.

Timed Puzzles Test a Skill Most Roles Rarely Use

Some roles genuinely require strong algorithm skills. If you're building database engines, compilers, or performance-critical systems, testing for algorithmic thinking makes sense. The problem is applying this filter by default regardless of what the job actually requires.

A problem a competent engineer can solve cold with basic data structures, like reversing a linked list or finding duplicates with a hash map, checks the coding fluency every role needs. The mismatch starts with problems that are hard to finish in thirty minutes unless you recognize a named technique the role doesn't use, such as dynamic programming or a specific graph algorithm. The argument here is about those technique-dependent problems. Difficulty labels on practice sites don't mark that line, since many medium problems are plain hash-map work.

Most software engineering roles demand system design thinking to architect scalable solutions, production debugging to troubleshoot complex failures, cross-functional collaboration to align technical decisions with business needs, and trade-off evaluation to balance competing constraints. Algorithm optimization rarely appears in the day-to-day work, yet coding rounds built on technique-dependent problems test almost exclusively for it. Larger interview loops add design and behavioral rounds, but the coding round often comes first as a screen. When that screen uses technique-dependent problems, a candidate who fails it never reaches the rounds that sample the job.

Even when performance optimization matters in typical production systems, it's usually about database query optimization, caching strategies, network request patterns, and system architecture rather than the algorithmic complexity of isolated functions. For roles building web applications or distributed services, the engineer who can identify an N+1 query problem delivers more immediate value than the engineer who can implement graph traversal algorithms from memory. Different roles, different requirements.

A candidate might struggle to find the optimal solution to a graph problem in thirty minutes while being excellent at diagnosing why a distributed system exhibits inconsistent behavior under load. They might fumble dynamic programming problems while being the engineer who catches architectural flaws in design reviews. When the role requires the latter skills, the interview measures their weakest capability and ignores their strongest. Public data doesn't show how often that happens across a hiring pool, so the case here rests on what the test contains rather than on counted rejections.

Drilled Patterns Pass for Reasoning

Pattern matching also masquerades as algorithmic thinking. Practice sites group their problems by technique, such as two pointers, sliding window, and dynamic programming. A candidate who has drilled enough of them can solve a hard problem by recognizing which template it fits. Recognizing patterns is a useful skill, and engineers diagnose production issues partly that way. But recognizing a problem from a drilled catalog measures hours of preparation.

Under time pressure, recall produces the same answer on the whiteboard as reasoning from first principles. An interviewer can try to tell them apart by changing a constraint and asking why. That probe works only as well as the interviewer runs it, so the signal comes from the interviewer, not the format.

One Live Round Adds Noise

The live format adds noise of its own. In a randomized controlled trial published at ESEC/FSE 2020, Mahnaz Behroozi, Chris Parnin, and colleagues gave 48 computer science students a whiteboard problem, half with an interviewer watching and half alone in a private room. Being watched cut performance by more than half. That penalty comes from observation, not from the puzzle, so it applies to any live exercise.

Aline Lerner found a second source of noise in 2016 data from interviewing.io, a practice-interview platform. Only about a quarter of candidates who interviewed more than once performed consistently, and many who earned a top score in one interview earned a failing score in another. That instability belongs to any single interview. Neither finding favors one format's content over another's. Both argue against letting one live round decide, and a lone timed puzzle used as a gate is exactly that. It measures preparation and composure on that day alongside a skill the role rarely uses.

The Screen's Misses Fall Unevenly

The usual defense is that this filter accepts false negatives to avoid false positives, because a bad hire is expensive and a large company can afford to lose good candidates. The trade can hold for the company, but it rests on an assumption. For a role that doesn't use the puzzle skill, the screen catches bad hires only as far as puzzle performance happens to track the skills that predict success in that role.

Its false negatives also aren't spread evenly. A filter that rewards drilled patterns favors whoever had time to drill, and the talent pool narrows in that direction. Defenders read those drilling hours as a sign of conscientiousness, but hours available to drill also track free time, so the signal mixes diligence with circumstance.

Most Roles Run on Debugging, Design, and Review

Most software engineering involves systems thinking applied to building products. That means understanding how components interact, how failures propagate, how changes impact users, and how technical decisions affect business outcomes. It means reading production metrics to diagnose issues, reviewing code to catch bugs before deployment, mentoring junior engineers to improve team capability, and collaborating with product teams to ensure what gets built actually solves user problems.

Consider what a senior application engineer actually does. They investigate why a service's 99th percentile latency spiked from 200ms to 2 seconds overnight and discover a deployment introduced inefficient database queries. They review a pull request, identify a race condition in concurrent access to shared state, and suggest refactoring with proper locking. They pair with a junior developer to debug why a feature works locally but fails in staging due to differences in environment configuration. They join a design meeting and explain why the proposed real-time notification feature requires WebSocket infrastructure and database schema changes that will take three weeks, not three days.

None of these activities resemble solving algorithm puzzles under time pressure.

Work-Like Formats Keep What Puzzles Get Right

Puzzles persist for reasons that hold up. They're cheap to run at scale, every candidate gets a comparable problem, and the scoring is easy to defend. That consistency comes from giving every candidate the same problem and scoring it against written criteria. Neither step depends on puzzle content, and a work-like exercise can do both.

Prediction Is Tied, So Content Decides

Puzzles' strongest defenders also treat them as a proxy for general reasoning ability. Public data tying algorithm-round scores to later job performance is scarce, so the case for or against puzzles has to lean on general selection research. Paul Sackett and colleagues re-analyzed personnel-selection studies in the Journal of Applied Psychology in 2022. They estimated validity at .42 for structured interviews, .40 for job knowledge tests, .33 for work samples, and .31 for cognitive ability. Those are averages across occupations, and work samples don't clearly beat cognitive ability on their own.

So the numbers don't crown a content winner. When prediction is roughly tied and no outcome data exists for a particular test, selection practice falls back on content validity. The US Uniform Guidelines on Employee Selection Procedures (29 CFR 1607.5) describe it as showing that a test's content is "representative of important aspects of performance on the job."

Puzzles fall short of that standard whichever way you classify them. Treated as a cognitive-ability test, a puzzle is a proxy that ranks below job knowledge. Treated as a job-knowledge test, it samples algorithm technique the role rarely uses. Either way, a structured exercise built from the role's own work meets the content standard more directly. That standard is about defensibility, not a proven gain in hires. But when prediction is tied, matching the job's content is the reason left to prefer one format, so it breaks the tie.

Two problems from the first section, drilled recall and uneven misses, also favor the work-like format. Preparation bends the puzzle proxy, because puzzles draw from a public catalog of thousands of problems with published solutions, so a candidate who has seen the problem is measured partly on recall. And the screen's false negatives skew toward people without time to drill.

A work-like format costs more. Scenarios have to be written per role, calibrated, and rotated, and interviewers have to be trained and recalibrated on the rubric. Most of that cost recurs per role. The longer formats also take more interviewer time per candidate, so a short debugging or review exercise suits the screen and the longer ones suit later rounds. A puzzle screen is cheaper to run, but its cost lands elsewhere, in each candidate it turns away for content the role doesn't use. No public outcome data shows which cost is larger.

Match the Format to the Work

Some companies have made that switch, and the community-maintained Hiring Without Whiteboards list on GitHub catalogs hundreds of them. The list shows the switch is workable at scale, not that those companies hire better, so the case for it rests on the research above. The format should follow the work the role does most:

When the role mostly...	Test it with	What it reveals
Builds performance-critical internals like database engines, compilers, or low-latency libraries	Algorithm and data-structure problems, ideally drawn from the domain	Whether the candidate can reason about complexity where it decides the outcome
Extends and maintains a product codebase	Pair programming on an existing codebase	Collaboration, code quality standards, and how they work through ambiguous requirements
Delivers features end to end	A small take-home project with tests and documentation	Whether they can build a working feature without artificial time pressure
Runs services in production	Diagnosing a seeded bug from logs and metrics	How they form and test hypotheses about a failure
Shapes how services fit together	A system design discussion on a realistic problem	Their grasp of distributed systems, scalability patterns, and trade-off evaluation
Reviews others' work and mentors	Critiquing a real pull request	Whether they can find bugs, suggest improvements, and give feedback constructively

Some employers hire into a general pool and place engineers on teams later, so there is no single role to sample, and puzzles appeal because they are role-neutral. But a generalist pool still shares a core of work: reading unfamiliar code, debugging a failure, and reviewing a pull request. The debugging and review rows above sample that core for any team, and they meet the content standard where a puzzle doesn't.

Structure Makes Any Format Fairer

These approaches aren't perfect. Take-home projects favor candidates with more free time, the same skew a drilled screen has, which is a reason to keep them small. Pair programming can feel stressful, and system design discussions are harder to standardize.

The observation penalty from the Behroozi study also hits every live row in the table, so give candidates private time to work before they discuss their approach wherever the format allows.

Private work brings its own problem, because AI assistants make unobserved work hard to attribute. Any private or take-home portion needs a live follow-up where the candidate walks through their work and extends it. That follow-up is still observed, but the candidate explains a solution they already reached instead of searching for one under a watching eye. The Behroozi study's private condition used the same shape, with participants solving alone and then explaining their work in a retrospective think-aloud.

Each format earns its place only when it's structured. That means the same scenario for every candidate, and a rubric written beforehand that lists what a strong answer finds, such as the seeded bug's root cause or the race condition in the pull request. Scenarios drawn from the company's own systems leak too, through interview-review sites. But they have no published solution set and can be rotated, so they resist drilling better than a public catalog does. Built that way, structure supplies the consistency and the job's own work supplies the content, rather than memorized algorithm patterns.

Learn Algorithms for the Work, Not the Interview

Build your algorithmic foundation because it matters beyond the interview. Understanding data structures helps you choose the right tool for the job, and knowing complexity analysis helps you write efficient code. Study algorithms to become a better engineer, not just to pass interviews.

But recognize that grinding LeetCode is interview preparation, not professional development. The hours spent memorizing dynamic programming patterns could be spent building systems, contributing to open source, or learning distributed systems concepts. Those investments develop professional capability while LeetCode grinding mostly develops interview performance.

Strong engineers architect scalable systems, debug production failures, and collaborate across teams to ship features. Whether they can solve algorithm puzzles in thirty minutes is an indirect, noisy signal of any of that.

The problem isn't the candidates' capability. It's an interview process that measures the wrong thing for the role.

Until hiring changes, engineers are stuck preparing for interviews that don't reflect the job, while companies reject candidates on content that says little about the role.

Real-Time AI Interview Help: Keeping Technical Answers Relevant as Questions Change

Tue, 15 Sep 2026 08:22:45 +0000

A technical interview rarely follows a straight line. You suggest a solution, the interviewer changes a constraint, and suddenly the most important part of your original answer no longer applies. The challenge is keeping your explanation aligned with the problem as it develops.

That is the angle I find most interesting about real-time AI interview help. Generating a plausible answer is only one part of the task. An assistant also needs to recognize what changed, preserve the details that still matter, and avoid pulling the conversation back toward an outdated solution.

I’m Peter, founder of Linkjob AI. In this article, I’ll use a hypothetical backend interview to explain how I think about useful assistance during technical conversations. These are design principles, not performance claims about a particular model.

Start with a concrete problem

Imagine an interviewer asks you to design a service that accepts uploaded files and processes them in the background. You propose an API, object storage, a job queue, and workers.

That is a reasonable starting point, but listing components does not explain the decisions behind them. A clearer answer connects each component to a requirement:

Object storage holds the uploaded files.
The queue separates upload requests from processing work.
Workers process jobs independently of the request lifecycle.
A status endpoint lets users check progress.

An assistant should help the candidate articulate those relationships. Producing a longer list of technologies would add little unless the interviewer has introduced requirements that justify them.

Treat a follow-up as a change to the problem

Now the interviewer asks: “What happens if a worker finishes processing a file but crashes before acknowledging the message?”

The conversation has moved from architecture to failure handling. Repeating the original system diagram would miss the question.

A useful response should focus on the sequence: processing completed, acknowledgment did not, and the queue may deliver the job again. The candidate can then discuss how to make repeated processing safe.

A short prompt might be enough:

“Explain redelivery, identify the operation that must be idempotent, and describe how completion is recorded.”

That leaves room for the candidate to reason through the actual design. It also avoids claiming that adding a queue automatically solves reliability.

If the interviewer then asks about two workers receiving the same job concurrently, the assistant should update its guidance again. Checking whether a job is complete is not sufficient if both workers can pass that check before either records completion.

Keep requirements separate from assumptions

Technical answers become confusing when assumptions silently turn into facts. In the file-processing example, the interviewer might never have specified file size, processing duration, traffic volume, or whether jobs must finish in order.

An assistant could fill those gaps with invented numbers and produce an impressive-looking architecture. The candidate would then be defending decisions built on requirements that nobody agreed to.

A better approach is to identify which unknown changes the design. For example:

Large files may affect upload strategy and storage access.
Long-running jobs may require attention to visibility timeouts or lease renewal.
Strict ordering may constrain how work is distributed.
External side effects may make retries harder to handle safely.

The candidate does not need to ask every possible question. They need to surface the assumptions that materially affect their answer.

Suggest the next reasoning step

During a live conversation, a full essay can compete with the interviewer for attention. I would rather see an assistant offer a compact sequence the candidate can develop in their own words.

For the worker-crash question, that sequence could be:

State that the job might be delivered again.
Explain what duplicate execution would do.
Describe a mechanism for preventing or safely handling duplicate effects.
Acknowledge the remaining failure case.

The fourth step matters. Suppose the worker calls an external billing service and then crashes before recording success locally. A local “completed” flag alone cannot establish whether the charge happened. The answer needs to consider the external service’s behavior, such as whether it supports idempotency keys.

This is the kind of distinction that makes technical assistance useful: helping someone identify the next issue they should reason about.

Do not manufacture the candidate’s experience

There is also a difference between explaining a design and claiming to have implemented it. An assistant may be able to describe a distributed job-processing system without any evidence that the candidate has built one.

If the interviewer asks, “Have you handled this in production?”, the response should reflect the candidate’s actual background. It should not invent a migration, an incident, or a performance improvement.

A candidate can explain how they would approach an unfamiliar problem while being clear about their experience. Assistance should preserve that distinction, particularly when using a résumé or project notes as context.

My interest in real-time AI interview help centers on making relevant information easier to use in the moment. That includes recognizing when the available information does not support a claim.

Evaluate how well the assistant follows the conversation

Testing an interview assistant with isolated questions misses an important part of the experience. A response can be correct for the opening question and irrelevant by the third follow-up.

For the file-processing example, I would test a sequence that introduces duplicate delivery, concurrent workers, external side effects, and then a simpler traffic requirement that removes the need for some earlier complexity.

The questions I would ask during evaluation are practical:

Does the assistant notice each changed constraint?
Does it abandon advice that no longer applies?
Does it distinguish a proposed design from a proven guarantee?
Can the candidate understand the suggestion while continuing to listen?
Does the output encourage clarification when necessary?

These checks examine whether the assistant supports an evolving explanation.

Keep the candidate in control

A real-time AI interview assistant should leave room to ignore a suggestion, pause assistance, or request clarification. Interviewers may also have specific rules about external tools, so candidates should establish what assistance is permitted before using it in an assessed conversation.

The design goal I care about is straightforward: help someone explain their reasoning clearly as the question changes. In a technical interview, that means tracking constraints, discussing failure cases, and knowing which assumptions still need to be checked.

A useful suggestion gives the candidate something they can understand, evaluate, and explain. That is a more meaningful standard than how much text an assistant can generate.

Disclosure: I’m the founder of Linkjob AI. The product links in this article lead to my company’s website.

A SQL interview is a translation test, not a syntax test

Sat, 22 Aug 2026 14:27:55 +0000

Four-Leaf's SQL Interview Guide

Key takeaways

A SQL interview is a translation test. The syntax is the easy half, and most candidates who fail were fluent in SQL. What sinks them is starting to type before the question is pinned down, or writing a correct query that answers something nobody asked. The round scores three things: whether you clarify before you write, whether your query is correct on the edge cases, and whether you can explain your reasoning while your hands are moving. It also looks meaningfully different depending on whether you're interviewing as a data analyst, a data scientist, or an engineer.

What does a SQL interview test?

The round tests whether you can turn an underspecified business question into a query that survives contact with real data. Interviewers rarely hand you a clean specification, because the job never does either.

SQL is worth preparing for on volume alone. The Stack Overflow 2025 Developer Survey found 58.6% of developers had used SQL in the past year, making it the third most-used language behind JavaScript at 66% and HTML/CSS at 61.9%, and ahead of Python at 57.9%. It shows up in loops for roles that aren't nominally data roles at all, which is part of why candidates underprepare for it.

The tell that separates a strong candidate is what happens in the first sixty seconds. Weak candidates read the prompt and start typing. Strong candidates restate the question, ask what counts as an active user or a completed order, confirm whether the answer should include rows with nulls, and only then write. That opening exchange is often worth more to the interviewer than the query itself, because it's the part of the job that can't be looked up.

What kinds of SQL questions come up?

Three shapes cover most of what gets asked, and they escalate in a predictable order.

The first is a join and aggregation question. Given two or three tables, produce a count or a sum grouped by something. These look trivial and catch people on join type, because an inner join silently drops the users who never ordered, and the question usually wanted them counted as zero.

The second is a window function question. Rank purchases per customer, find each user's second transaction, compute a running total, or calculate a month-over-month change. This is where a lot of loops separate candidates, because window functions are the boundary between people who write SQL occasionally and people who use it as a primary tool.

The third is an open business question against a schema you've just been shown. "Tell me whether retention improved after the March release." There's no single correct query. The interviewer is watching how you decompose the question, what you decide retention means, and whether you notice that the March cohort has less time to churn than the February one.

How is a SQL interview scored?

Three dimensions, and they map to those question shapes. It helps to run each one against the questions the round keeps returning to: give me a count by group, rank something per user, and answer this vague business question.

Do you clarify before you write? A passing answer asks one question about the schema. A strong answer names the ambiguity that would change the query and resolves it. "Does an active user mean any event in the window, or a purchase?" is the difference between two very different numbers, and interviewers plant that ambiguity on purpose.

Is your query correct on the edges? A passing answer runs. A strong answer accounts for nulls, duplicates, ties in a ranking, and rows on the boundary of a date range. Say the edge case out loud when you handle it, because a silent LEFT JOIN looks identical to a lucky one.

Can you narrate while you write? A passing answer goes quiet and produces a query. A strong answer talks through the plan first, writes, then checks the result against a rough expectation out loud. Interviewers score reasoning they can hear, and a correct query delivered in silence gets a weaker write-up than a slightly imperfect one that was explained.

How does a SQL interview differ for a data analyst versus a data scientist?

Same language, meaningfully different round, and mixing them up is the most common preparation mistake in the function.

Data analyst. The emphasis is breadth and business translation. Expect more questions, less depth per question, and heavy weighting on whether your numbers would hold up in front of a stakeholder. Definitional precision matters more than query elegance. You're likely to be asked what a metric should mean before you're asked to compute it, and an answer that flags a misleading denominator scores higher than one that optimizes a join.

Data scientist. The emphasis shifts toward experiment and cohort logic. Expect fewer questions with more depth, and expect at least one that touches an A/B test readout, a cohort definition, or a sampling problem hiding inside the SQL. A question about whether a March cohort had less time to churn than a February one is a data scientist question. Correctness under a statistical framing is what's being scored, not query volume.

Analytics engineer. The round moves toward modeling. Expect questions about how you'd structure the model rather than write a one-off answer, including idempotency, incremental logic, and what happens when the query is rerun.

Software engineer. SQL usually appears inside a broader technical round rather than on its own, and the framing is performance and correctness at scale. Expect indexing, query plans, and the consequences of a full table scan rather than business definitions.

Product management. Increasingly common and usually light. The bar is whether you can pull your own numbers without asking an analyst, so expect one aggregation question and no window functions.

Four-Leaf covers the wider data loop in how to prepare for a data science interview.

What is overrated

Memorizing exotic syntax. Recursive CTEs and pivot tricks appear in practice sets far more often than in interviews, and time spent there is time not spent on window functions, which appear constantly.

Speed is the other overrated thing. Candidates rush because they assume the clock is the test, then miss a join type. The interviewer is almost always more interested in whether you caught the null case than in whether you finished ninety seconds early.

Using an AI assistant to get through this round is a losing trade. CodeSignal reported in February 2026 that cheating and fraud attempts on proctored assessments more than doubled, from 16% in 2024 to 35% in 2025. Interviewers noticed. A 2025 interviewing.io survey of 67 of them, 52 at FAANG companies, found 81% suspected candidates of using AI and about a third had caught someone at it. The visible response has been more live, narrated rounds, which is precisely the format where a candidate who can't explain their own query falls apart.

A five-step playbook for a SQL round

Drill window functions until they're automatic. ROW_NUMBER, RANK, DENSE_RANK, LAG, LEAD, and a running sum. These carry more interview weight per hour of study than anything else in SQL.

Practice restating the question out loud before writing. Give yourself a rule that you don't type until you've named one ambiguity.

Build a null and duplicate checklist. Before you call a query done, ask what happens to rows with nulls, rows that appear twice, and rows exactly on the boundary date.

Do at least three problems on a whiteboard or plain text editor. Autocomplete hides gaps that a bare editor exposes, and many live rounds use a bare editor.

Narrate a solved problem end to end. Explaining a query you already understand is a separate skill from writing it, and it's the one being scored. A voice mock interview is a reasonable way to rehearse the narration, since the failure mode is going quiet under pressure rather than not knowing the syntax.

Where this is heading

SQL rounds are getting more conversational, and the reason is the same force reshaping every technical loop. As assistants make it trivial to produce a syntactically correct query, interviewers move the bar to the part that's harder to fake, which is deciding what to compute and defending the choice. Four-Leaf's AI-Era Hiring Index, a study of 3,502 open roles at 16 top tech employers, found LLM or foundation-model experience listed in 57% of data and machine learning job descriptions against 21% of engineering ones, so the expectation that data candidates work alongside these tools is already written into the postings.

That direction rewards the candidate who understood the question. The syntax was never the hard part, and it's about to matter even less. Where this round sits in the wider sequence is covered in how an onsite interview loop actually works. To rehearse it out loud rather than read about it, start with eight coding interview platforms, compared.

I Froze on Iterative Postorder. The Fix Was Understanding the Stack

Thu, 28 May 2026 11:14:52 +0000

I had written recursive preorder, inorder, and postorder more times than I could count, three lines and a base case each. Then an onsite asked for postorder without recursion, and I blanked, pushing nodes onto a stack and popping them in the wrong order for a solid ten minutes. The traversal that had felt automatic fell apart the moment the stack became mine to manage.

What stung was realizing the recursion had been carrying a hidden stack the entire time. The frames were doing the work, and nobody ever made me look at them.

What finally clicked

The three recursive traversals were one walk, not three separate facts to memorize.
Recursion was quietly leaning on a stack the language managed the whole time.
Iterative postorder is the one that proves whether you understand that stack.
The order you choose is a data direction question, not a matter of taste.

Where the understanding was thin

Writing the recursive version of all three was automatic. Explaining what the call stack was doing while they ran was not, and that gap turned out to be the whole story.

I could trace the output by hand but not the machine producing it. So when the iterative version asked me to be the machine, there was nothing underneath the memorized shapes to stand on. The recursion had been doing the bookkeeping, and that was easy to mistake for understanding it.

What the recursion was doing for me

Every call on a child saves the current position and jumps in, then comes back when the child returns. That saved position is a stack frame. A recursive traversal is really a loop over a stack you never have to see, which is exactly why it feels effortless until you have to rebuild it.

Deep trees punish the hidden version. A chain of 10,000 left only children overflows the call stack in most languages. The iterative rewrite moves that work onto a list in heap memory, so the skewed tree that crashes recursion runs fine.

Rebuilding postorder by hand

Postorder is the hard conversion, because you reach a parent before its two children, but you have to process it after them. The cleanest way to hold that backwards is two stacks. The first produces a node, right, left order. The second reverses it into left, right, node, which is postorder.

def iterative_postorder(root):
    if not root:
        return
    stack1 = [root]
    stack2 = []
    while stack1:
        node = stack1.pop()
        stack2.append(node)
        if node.left:           # left first so right lands on top
            stack1.append(node.left)
        if node.right:
            stack1.append(node.right)
    while stack2:               # stack2 holds node, right, left
        process(stack2.pop())   # popping reverses it into postorder

Trace it on a tiny tree with root 1, left child 2, and right child 3. Postorder should read 2, 3, 1.

stack1: [1]                      stack2: []
pop 1 -> stack2: [1]             push 2, 3 -> stack1: [2, 3]
pop 3 -> stack2: [1, 3]          3 is a leaf
pop 2 -> stack2: [1, 3, 2]       2 is a leaf
drain stack2 by popping:         process 2, then 3, then 1

The output 2, 3, 1 is postorder. Watching the second stack get drained in reverse is the moment the whole thing stopped feeling like a trick.

Why the order was never the hard part

The last lesson took the longest to land. The problem was never the traversal. It was that the recursion got practiced and the stack underneath it got skipped.

Once that gap closed, picking an order got simple, because the order is decided by one question. Does the parent need answers from its children, or do the children need data from the parent? Height, diameter, and subtree sums need the children first, so they are postorder. Path sums hand data downward, so they are preorder. Sorted output from a BST is inorder. Work defined per level is level order with a queue instead of a stack. Which way the data had to move decided the order every time, with no preference involved.

That gap, between knowing the recursion and understanding the stack underneath, is what I kept circling back to, and it is a big part of why I built Codeintuition. The lesson that traces the stack frame by frame is the walkthrough I wish I had back then.

The habits that fixed it

Old habit	New habit
Memorize three recursive shapes as separate facts	Treat them as one walk with the visit line moved
Reach for recursion and hope the stack held	Manage the stack by hand when depth is a risk
Guess at iterative postorder under pressure	Build it from the two stack idea every time
Pick a traversal order by familiarity	Pick it by which way data moves, parent to child

If you are staring at the same wall, three things would have saved me a lot of time:

Learn the stack, not the three shapes. Once you read the recursion as a loop over a stack, preorder and inorder stop being separate things to memorize.
Write iterative postorder by hand before an interview forces you to. It is the one that exposes whether you understand the stack, since you meet the parent before its children and have to hold it back.
Decide the order by data direction. Ask whether the parent needs its children's answers or the children need the parent's data, and the order picks itself.

I put the longer version on my own blog, including the level order walkthrough and the full set of traces.

What's a traversal or algorithm you thought you knew cold until an interview asked for the version you had never written by hand?

I Solved 80 Tree Problems Before Binary Tree Recursion Clicked

Tue, 26 May 2026 16:09:31 +0000

I'd solved around 80 tree problems by the time my second on site interview wrapped up. Most were mediums. Preorder, inorder, postorder, level order felt like second nature. Tree height and BST validation, written from scratch, half a dozen times each. But the medium I'd just bombed had a stateful postorder shape I didn't see in the moment, and 20 of the 35 minutes went to patching the wrong recursion.

On the train home I traced the solution by hand. It clicked in 90 seconds. The problem wasn't tree knowledge. What was missing was the skill of predicting how a recursive function would flow through the call stack, frame by frame, before writing any code.

What changed for me

Mental simulation of the call stack is a separate skill from knowing traversal types.

The six tree patterns split cleanly along one axis: which direction information flows.

Stateful postorder problems look right at every node and wrong overall when you confuse the return value with the answer.

BST validation looks structurally fine and is logically broken when you check only direct children.

Practicing tree problems without simulating the call stack is what kept me stuck for months.

Where the recursion kept breaking

The approach had been treating tree problems the same way you'd treat array problems. Read the statement, sketch one small example, write code, test against the example, debug. On arrays that loop works fine because the traversal is linear and the bugs show up immediately. On trees the loop fails silently. The recursion executes, the values look plausible at every node, the test case passes on a small input, and a deeper tree from the interview question produces the wrong answer.

The symptom looked like a knowledge problem, so for a while the response was reading. Reread the postorder explanation. Try more medium problems. Next interview, freeze on something with the same shape. The reading wasn't the gap. The simulation skill was.

The fix turned out to be simpler than expected. Before writing any code for a tree problem, ask one question: which direction does information have to flow to get the answer? Down through parameters? Up through return values? Sideways with a queue?

That single question puts you into the right pattern category before you've written a line of code. It also forces you to predict what's going to happen on the call stack before running anything.

What I started doing differently

The protocol ran something like this. It was deliberately slower than the old read-and-code habit, and it was the part that closed the gap.

Read the problem. Sketch a small concrete tree on paper. Not the example from the problem statement, a tree you make up.
Ask the direction question. Does the answer for a node depend on what's above it, what's below it, or what's beside it?
Pick a pattern. Down means preorder. Up means postorder. Sideways means level order. Stateful versions of each split off by whether a global accumulator is involved.
Write one sentence describing what f(node) returns. If you can't write the sentence, you've misidentified the pattern.
Walk through the call stack on the sketched tree. Predict the order of recursive calls. Predict what each call returns. Note where global state changes if any.
Only then start coding.

The whole protocol took 5 minutes the first few times. It saved 20 in debugging. After running it on 30 problems, the first five steps collapsed into about 60 seconds of thinking before any code got written.

What that looked like on diameter

The first problem I ran this protocol on was tree diameter. The diameter of a binary tree is the longest path between any two nodes, measured in edges.

Sketch a small tree. Root with a left subtree of depth 2 and a right subtree of depth 3.

Direction question: does the diameter at the root depend on what's above it (impossible, it's the root), what's below it (yes, the depths of the subtrees), or sideways (no)?

Information flows up. Postorder.

Sentence describing what f(node) returns: the height of the subtree rooted at node. The diameter accumulates globally.

That last detail is where stateful postorder lives. The return value is the local thing the parent needs (subtree height). The actual answer is a global thing updated at each node (the maximum of left_height + right_height seen anywhere in the tree).

def diameter(root):
    longest = 0

    def height(node):
        nonlocal longest
        if not node:
            return 0
        left = height(node.left)
        right = height(node.right)
        longest = max(longest, left + right)
        return 1 + max(left, right)

    height(root)
    return longest

Walking the call stack:

height(left_child) runs first. Recurses down to the leaves, returns heights from the bottom up. At each node, updates longest with left + right.
height(right_child) runs next. Same behavior on the right subtree.
height(root) runs last. Gets left subtree's height (2) and right subtree's height (3). Updates longest with 2 + 3 = 5. Returns 1 + max(2, 3) = 4 (which is the tree's total height, not the answer).

The diameter is longest = 5. The return value of the top call is 4 (the height) and it isn't the answer. That separation between return value and answer is the entire pattern.

Earlier attempts at diameter kept trying to make the return value carry the answer directly. It doesn't work, because the diameter at a node combines information from two siblings, not from a single root-to-leaf path. The global accumulator is what handles that combination.

Why this works

The mechanism isn't deep, once you see it. Tree recursion is two recursive calls per node. The call stack pushes the parent frame, pushes the left child's call chain, pops back to the parent, pushes the right child's call chain, pops back to the parent. Two branches per frame.

What makes tree problems feel hard is that you have to predict this branching in your head before writing code. Once you can predict it, the choice between preorder, postorder, and level order falls out of the prediction itself. Down means the answer accumulates on the way down. Up means it accumulates on the way back. Sideways means the call stack is the wrong tool entirely and you should use a queue.

The maximum path sum lesson on Codeintuition was the one where this pattern finally became obvious to me, because it's stateful postorder with a meaner set of edge cases (negative values, single node paths, paths that pass through the root rather than ending at it). Watching the call stack trace through that problem frame by frame was what made the structure click for everything after it.

What I'd tell someone in the same spot

If you've solved 50+ tree problems and still freeze on unfamiliar ones, the gap is almost always the simulation skill, not the knowledge. More problems won't close it.

The shortest practice that helped me: take a tree problem you've solved before. Cover the solution. Sketch a small tree. Predict the order of recursive calls and what each call returns. Open the solution in a debugger and step through. Note where your prediction diverged from what actually happened.

Three rounds of that and the call stack stops feeling abstract. Five rounds and you can read a new tree problem, decide direction in 30 seconds, and start coding from a correct mental model.

Worth doing on every pattern category at least once. Stateless preorder. Stateless postorder. Stateful postorder. Root to leaf path. The BST inorder pattern. Level order with a queue. Once each of those patterns has a call stack trace burned into your head, the rest of the variants are small adaptations.

There's a longer version on my own blog that walks through the four BST-only patterns and the heap variants in more depth.

What's a tree problem that finally made the call stack visible to you in your head, where reading the textbook explanation hadn't? For me it was diameter. The protocol I built around it is what made every subsequent stateful postorder problem feel mechanical.

What 40 Binary Tree Problems Didn't Teach Me Before My FAANG Interview

Mon, 25 May 2026 12:09:46 +0000

The tree round on my first onsite was Root to Leaf Paths. Enumerate every root-to-leaf path in a binary tree. Looked easy. The recursion took about four minutes to write. Running it on the sample input came back with a list where every path ended at the leaf of the last branch the function had visited. The earlier paths had been contaminated. The interviewer watched the screen for two full minutes before the cause clicked: the shared list parameter never got cleaned up between recursive calls. That technique had shown up in practice twice before, but the conditions for when it was required had never internalised. What was missing was the framing that root-to-leaf problems are a class with their own boundary handling, separate from the other recursive tree patterns.

What changed afterwards:

Tree problems aren't a single skill. They are six distinct mechanisms (preorder, postorder, root to leaf, level order, LCA, simultaneous traversal), each with its own boundary cases.

Fifteen problems chosen by pattern coverage beat forty random problems sorted by acceptance rate.

The single biggest mistake on root-to-leaf problems is forgetting to backtrack the shared accumulator after each recursive call.

Practice in pattern order, not difficulty order. Each pattern's mechanism transfers to its variants but not to other patterns.

Where the tree prep was breaking

The grinding approach is what most onlines recommend. Open LeetCode's tree tag. Sort by acceptance rate or popularity. Work through the top forty. After about a week the easy ones feel reflexive, after two weeks the mediums start landing more often than not, and by week three the assumption is that tree rounds will be fine.

That assumption broke on the Root to Leaf Paths bug. The problem wasn't hard. It was a class of problem that had been practiced before. What was missing was the recognition that root-to-leaf is its own pattern with its own boundary behaviour, distinct from the postorder problems on the list and distinct from the preorder problems that felt most confident. Forty problems sat behind that interview, and there was no grouping that would have made the root-to-leaf class visible as a class.

The deeper diagnosis was this. What was missing wasn't more problems. It was the grouping that would let problem 1 in a class prepare a candidate for problem 2 in the same class. Forty problems organised by popularity give no transfer. Two problems per pattern, organised by mechanism, give coverage of every interview-grade tree question that's likely to show up.

What started working differently

The rebuild happened pattern by pattern. Each session, pick one of the six patterns. Work through the direct application first (the problem that teaches the mechanism cleanly). Then work through one variant (the problem that proves the mechanism transferred). Two problems per pattern, no more. If the mechanism hadn't clicked after problem two, the answer wasn't to add a third problem in the same pattern. The answer was to go back to problem one and trace it on paper until the mechanism became obvious from the structure of the recursion.

The change in approach looked like this:

Before (grinding random problems)	After (two per pattern, in pattern order)
Sort LeetCode tree tag by frequency, do top 40	Pick six patterns, do two problems each, in pattern dependency order
Treat each problem as a separate puzzle to solve	Treat each problem as an instance of one of six known mechanisms
Practice difficulty order (easy, then medium, then hard)	Practice pattern order, with the direct application before each variant
Recognise solutions you've already seen	Recognise which pattern a new problem needs, then derive the solution
Freeze on root-to-leaf backtracking under pressure	Walk into root-to-leaf knowing the path parameter is shared and needs cleanup

The key was that the six patterns gave the practice a vocabulary. Preorder. Postorder. Root to leaf. Level order. Lowest common ancestor. Simultaneous traversal. Every binary tree problem that came up, the first question became "which of the six is this?" That single question reorganised everything. Problems that previously felt random started feeling like instances of techniques already met.

What that looked like on the next problem

Three weeks into the rebuild, a friend ran a mock interview and the prompt was Root to Leaf Paths. The exact problem that had broken the onsite.

The framing was different this time. Root to leaf problems share a single accumulator (the path list) across all recursive branches. That sharing is what makes them fast (no per-call allocation), and it is what creates the bug if the accumulator doesn't get cleaned up after each child returns. Recognise the pattern first, write the recursion with the cleanup built in.

def root_to_leaf_paths(root):
    paths = []

    def walk(node, current):
        if node is None:
            return
        current.append(node.value)
        if node.left is None and node.right is None:
            paths.append(list(current))
        else:
            walk(node.left, current)
            walk(node.right, current)
        current.pop()

    walk(root, [])
    return paths

Two things to notice in the code. First, current is a single list that gets passed down through every recursive call. There's no copy at each call, which is what makes the algorithm O(n) plus the cost of producing the output. Second, the current.pop() at the end of walk is the cleanup. After the recursion returns from a child, the appended value gets removed so the sibling subtree sees the path as it was when the parent called it. Without that line, the bug from the original onsite shows up.

The mechanism transfers to the variant. Equal paths asks whether any root-to-leaf path sums to a target. Same skeleton (descend, accumulate, check at leaf, backtrack), different terminal check. Once root to leaf paths is solid, equal paths is a five-minute extension. The root to leaf paths lesson walks the backtracking explicitly, which is the part that gets glossed over in most textbook reading.

Why this works (pattern based practice)

The reason pattern grouping holds up under interview pressure has a name in learning science: near transfer versus far transfer. Practicing forty random problems builds a lot of near transfer skill (the ability to handle problems that look like the ones already practiced) and almost no far transfer (the ability to reliably handle a new problem with a slightly different surface).

Practicing two problems per pattern, in pattern order, inverts that ratio. The first problem teaches the mechanism. The second forces a variation that confirms the mechanism transferred, not the surface form. Past two problems per pattern, the marginal value drops fast, because the third is rehearsing the same mechanism with diminishing returns.

The six patterns also explain why difficulty order is the wrong sequencing. A medium postorder problem can be easier than a hard preorder problem, if postorder is already understood and preorder hadn't been met yet. Difficulty is a function of "has this mechanism been seen before?" not a function of the problem's intrinsic complexity. Pattern order respects that dependency. Postorder builds on preorder's recursive structure. Root to leaf reuses postorder's return mechanism plus the backtracking subtlety. Level order is a paradigm shift to a queue-based approach. LCA introduces multi node reasoning. Simultaneous traversal scales LCA's reasoning to two trees.

What I'd tell someone starting tree prep

If you're three weeks into tree practice and tree rounds still feel random, the shift to make is to stop grinding and start grouping.

A protocol that worked for the rebuild:

Before each session, name the pattern you'll practice (preorder, postorder, root to leaf, level order, LCA, or simultaneous traversal). Pick one. Don't mix patterns within a session.
Solve the direct application first (the problem that teaches the mechanism cleanly). For postorder, that's height of binary tree. For root to leaf, that's root to leaf paths. For LCA, that's the canonical lowest common ancestor problem.
Trace the solution on paper after writing it. If you can't narrate why each step preserves the mechanism, the mechanism hasn't clicked. Go back to the recursion and walk it variable by variable.
Solve the variant second. Diameter after height. Equal paths after root to leaf paths. Distance between nodes after LCA. If the variant feels like a fresh problem instead of an extension, the first problem hadn't internalised.
Move to the next pattern only after the current pattern's variant feels like a five-minute job. The transfer signal is "the pattern got recognised first, then the solution wrote itself," not "it took careful work to get there."

The protocol slowed things down at first. Two problems per session felt like less practice than four problems per session. The payoff was that the slower practice transferred. When the next mock interview surfaced a tree problem that hadn't been seen, the pattern recognition kicked in first and the recursion followed. That sequence was what was missing from the original forty-problem grind.

The grouping is what got built into Codeintuition's tree course, because watching engineers grind through forty problems with no transfer was the failure mode that kept showing up across every prep cohort. Pattern-first practice changed how trees felt to walk into, and the course now teaches the same restructure that made the difference.

Originally posted on my own blog, with the full fifteen-problem list grouped by pattern and a recursion-bug catalogue.

What's a tree problem that finally made a pattern click for you, where the textbook explanation hadn't?

What I Wish I'd Known About Binary Search Trees Before Interviews

Mon, 25 May 2026 09:11:56 +0000

Three months of practicing binary search trees on paper. Search procedure memorised. Insertion procedure memorised. Three deletion cases memorised. Then came the onsite. The interviewer drew a tree on the whiteboard, asked for an insertion walkthrough, and the recall worked fine. Then she asked for a deletion of a node with two children, and the freeze lasted almost a full minute before the inorder successor steps came out without any real understanding of why they preserved the ordering. She let the explanation finish, then asked one followup: why does the inorder successor specifically work? There was no answer beyond "because the textbook says so." That was the moment the gap became obvious. The months spent memorising procedures had skipped the part the interview was actually testing.

What changed afterwards:

BST search, insert, and delete are not three procedures. They are the same recursive walk with three different terminal conditions.

The two child deletion case is the one interviewers probe because it is the only case where the invariant has to be explained out loud.

Memorising the inorder successor trick doesn't transfer. Being able to say why the inorder successor specifically works does.

Once the invariant becomes the unit of memory, every operation that preserves it becomes derivable on the spot.

Where the approach was breaking

What had been getting practiced wasn't the data structure. It was a list of procedures the invariant could have handed over for free.

The recall pattern looked like this. Open a BST problem. Recognise it as a BST problem. Try to recall the right procedure for whatever the question asked. Search? Walk down comparing target to current. Insert? Same walk, create a leaf at the bottom. Delete? Three cases, pick the matching one, run the steps. The recall worked fine for problems that matched the textbook exactly. It fell apart the moment the problem deviated, because there was no deeper rule available to derive a new procedure from.

The specific failure on that first interview was treating the two child deletion case as a separate procedure rather than a question about the invariant. The procedure said "find the inorder successor, copy its value, delete the original successor." Those steps executed fine. What didn't execute was the reason behind them, which was the actual signal the interviewer was checking.

The gap is small in concept and load bearing in practice. If you can recite the steps but can't explain why each one preserves the rule, you will lose the thread whenever the interview adds a constraint that doesn't appear in the textbook version. And interviews almost always add a constraint.

What started working differently

After that interview, the practice rebuild was small in shape and large in effect. Instead of "memorise the procedure, then run it," the new approach was "start from the invariant, then derive what has to happen to preserve it." Same problems, same operations, completely different relationship to the material.

The contrast looked like this:

Before (procedure first)	After (invariant first)
Memorise search as a walk down comparing values	Start from `left < node < right` and derive the walk as the consequence
Memorise insert as "find null pointer, create leaf"	Notice that insert is the same walk, only the terminal action changes
Memorise three deletion cases	Ask "what value can sit in this slot without breaking the invariant?"
Recall the inorder successor as a step	Derive the inorder successor as the answer to the slot question
Stall on novel problems	Answer novel problems by reasoning forward from the rule

The shift was to remember fewer things, more carefully. There is exactly one rule for a BST: every node's left subtree contains only smaller values, every right subtree contains only larger values. Every operation either preserves the rule or is incorrect. That framing made the procedures fall out naturally, because the question "what do I do here?" reduced to "what action keeps the rule intact?"

What that looked like on the next problem

A month later came a phone screen at a different company. The interviewer gave a tree with [8, 3, 10, 1, 6, 14] and asked for a search for 6 and then an insertion of 7.

Search started at the root. 6 < 8, so go left to 3. Then 6 > 3, so go right to 6. Found it.

def search(node, target):
    if node is None or node.value == target:
        return node
    if target < node.value:
        return search(node.left, target)
    return search(node.right, target)

Then inserting 7 was the same walk. From the root, 7 < 8, go left. Then 7 > 3, go right to 6. Then 7 > 6, go right again. Right pointer is null. Create node 7 there.

def insert(node, value):
    if node is None:
        return Node(value)
    if value < node.value:
        node.left = insert(node.left, value)
    elif value > node.value:
        node.right = insert(node.right, value)
    return node

What was different this time was the framing said out loud after the code finished. Search and insert are the same recursive walk. Search stops when the value matches or the pointer is null. Insert stops at a null pointer and writes a new leaf there. The walk is what the invariant requires. The terminal action is the only thing that changes between operations. The interviewer asked a few more questions and then moved on. The framing was the part that mattered, not the code.

The same shift made deletion easier too. Instead of three cases, the new mental model was one question: what value can sit in this slot without breaking left < node < right? For a leaf, the answer is no value. Drop the pointer. For a one child node, the answer is the child's value, because the child's subtree already satisfies the invariant against the parent. For a two child node, the answer is the smallest value larger than the deleted node (the inorder successor), which is what the slot requires after deletion. Three procedures collapsed into three answers to the same question.

Why this works (the invariant doing the heavy lifting)

The reason the invariant first framing holds up under interview pressure has a name in learning science: near transfer versus far transfer. Memorising a procedure builds a near transfer skill. The procedure applies to problems that look exactly like the one that got practiced. It doesn't apply to problems that look slightly different, because the procedure is tied to the specific form of the original.

Deriving a procedure from a rule builds a far transfer skill. The rule applies to any problem that respects the rule, regardless of how the form changes. The rule is what generalises. The procedure is what gets generated for the specific case.

BSTs make this concrete because there is exactly one rule and there are dozens of variant problems that ask you to apply it. BST validation. Conversion to sorted array. Conversion to sorted doubly linked list. Range queries. Kth smallest element. Lowest common ancestor in a BST. BST iterator. All derivable from "left subtree smaller, right subtree larger." None easy to memorise as individual procedures, because there are too many of them and they shade into each other.

The inorder successor lesson walks the two child deletion case from the invariant down, which is the framing that most first practice resources skip. The procedure becomes the easy part once the question is framed as "what value belongs in this slot?"

What I'd tell someone in the same spot

If your BST practice is at the point where the procedures feel memorised but the mock interviews aren't going well, the shift to make is to stop quizzing yourself on the steps and start quizzing yourself on the rule.

A practice protocol that worked for the rebuild:

Before solving any BST problem, write the invariant at the top of the page. left < node < right for every node, applied recursively to every subtree. Look at it for ten seconds.
Read the problem and ask: what action does the invariant require here? Not "what procedure do I run." What does the rule say has to happen.
Trace one example by hand on paper, narrating each step as "this preserves the rule because..." If that sentence won't finish, what's running is a memorised procedure, not a derivation from the rule.
Code it up. If the code falls out naturally from the narration, you have it. If a procedure shows up that you can't justify, stop and go back to step 2.

The protocol slows things down at first. Adding a thirty second pause to write the invariant and narrate the reasoning feels expensive under time pressure. The payoff is that the slow practice transfers. When the interview adds a constraint, the procedure that would have been recalled is wrong, but the rule still applies and the new procedure derives in real time.

That gap, between solving a BST problem and recognising why an operation works, is the thing that pushed me to build Codeintuition. Watching engineers grind through hundreds of tree problems without the invariant first framing was the pattern that wouldn't stop showing up. The tree courses now lead with the rule and let the procedures fall out, which is the ordering that would have saved months on the first attempt.

Originally posted on my own blog, a slightly longer version with the inorder traversal proof and the balanced construction algorithm.

What is a data structure that started making sense for you only after you stopped memorising the operations and started re-deriving them from the rule?

Big O Notation: What I Wish I'd Known Before My First Interview

Sat, 23 May 2026 11:29:05 +0000

The Big O table was memorised before the first onsite. Binary search logarithmic, merge sort linearithmic, hash insert constant amortised. All recitable. Then a senior engineer wrote a recursive function on the whiteboard, asked for an analysis, and almost a minute went by trying to match what was on the board to something on the cached table. The function was a naive recursive Fibonacci, seen before, implemented before. The freeze still happened, because nothing about the table told anyone how to count the recursive calls.

What I figured out afterwards

The table is the answer, not the method. Memorising it never builds the ability to derive complexity from code you haven't seen.
The thing the table hides is the counting. How many times the dominant operation runs as a function of input size.
Once four or five derivations have been traced by hand, the shape generalises. Unfamiliar code stops feeling opaque.
Space complexity has the same derivation shape, plus the call stack that's easy to forget.
The drill that actually builds the skill is deriving complexity on problems whose answer you don't already know.

Where the approach was breaking

The Fibonacci moment exposed the gap. The function had been seen. The function had been implemented. What hadn't happened was counting what the recursion actually does.

def fib(n):
    if n < 2:
        return n
    return fib(n - 1) + fib(n - 2)

The interviewer was patient. "How many calls does fib(5) make?" The whiteboard got a tree. fib(5) calls fib(4) and fib(3). fib(4) calls fib(3) and fib(2). fib(3) shows up twice. fib(2) shows up three times. The tree grew faster than the page it was being drawn on. The answer wasn't in cached memory because no one had asked for the count before. The answer is O(2ⁿ), roughly, and the reason is that each call branches into two and the depth is about n.

Big O had been treated as a label to attach after solving. The interview was treating it as a derivation to perform on unfamiliar code. Those are different skills, and the wrong one had been practiced.

What started working differently

The fix wasn't reading more articles. It was changing the drill. The new prompt was "given this code you haven't seen before, what's the complexity, and how would you justify it" instead of "what's the complexity of merge sort." Once the prompt changed, the way unfamiliar code reads changed with it.

Here's the shape that worked, side by side with the old habit:

Then	Now
Match the code to a memorised complexity.	Identify the dominant operation, the one that runs most.
Look up the answer when the match wasn't obvious.	Count how many times that operation runs, as a function of `n`.
Move on once a label was attached.	Sum the work across levels (loops, recursion depth, branching factor).
Forget about space until reminded.	Track space the same way: auxiliary memory plus the call stack.

The change is a habit, not a piece of knowledge. The Big O table doesn't get more correct over time. The way unfamiliar code gets read does.

What that looked like on the next problem

A few weeks after the Fibonacci interview, the same function came back out for re-derivation from scratch. No looking up the answer. Just the dominant operation and counting.

The dominant operation in fib(n) is the recursive call. fib(n) calls fib(n-1) and fib(n-2). Treat both as roughly fib(n-1) for the upper bound. So the call count T(n) ≈ 2 × T(n-1). That recurrence solves to T(n) = 2ⁿ. The depth of the tree is about n. The branching factor is 2. Total work is roughly the number of nodes in a binary tree of depth n, which is 2ⁿ.

That's why naive Fibonacci is unusably slow even at moderate n. fib(40) makes more than a billion calls.

Adding memoisation changes the shape entirely:

def fib(n, memo={}):
    if n in memo:
        return memo[n]
    if n < 2:
        return n
    memo[n] = fib(n - 1, memo) + fib(n - 2, memo)
    return memo[n]

Now each subproblem fib(k) for k from 0 to n is computed exactly once. There are n distinct subproblems. Each one does constant work after its two subcalls return. Total: O(n) time, O(n) space from the memo plus the call stack.

The complexity went from O(2ⁿ) to O(n) because the structure of the work changed, and the derivation made that visible in a way the table never did. (For the longer walkthrough of how memoisation becomes the gateway to dynamic programming, the DP interview blog covers the recurrence-to-table-to-bottom-up progression.)

Why this works (the science behind it)

The learning science term for the swapped drill is elaborative interrogation. Asking yourself why each operation contributes the work it does, rather than accepting the labelled answer at face value. The literature on it is consistent: forcing yourself to construct the reason produces a more durable, more transferable understanding than reading the reason already constructed.

The other piece is near transfer versus far transfer. The old drill was near transfer practice (the same complexity question on the same code already memorised). The interview was a far transfer test (different code, same skill). Near transfer practice doesn't reliably move far transfer scores. Once that lands, the right drill picks itself: derive complexity on code you haven't seen.

What to tell someone in the same spot

Three things, in the order they mattered.

Stop quizzing yourself on named algorithms. "What's the complexity of merge sort" trains memory, not derivation. Quiz yourself on an unfamiliar function instead, and force yourself to count the dominant operation explicitly. If you have to count it out loud, that's the right intensity.
Trace at least one recursive call tree by hand per week. The first few feel slow. The fifth or sixth is where the shape generalises. Branching factor times depth gives nodes, nodes times work-per-node gives total work. The arithmetic is the same on every problem.
Track space the same way you track time. Auxiliary memory plus call-stack frames. Most engineers in interviews get time right and space wrong, and the difference is purely habit.

Before this shift, a solution would read as that looks fast and the analysis would stop there. After, the same solution reads as O(n log n) because the divide step and the merge step can be pointed at independently. Adding a hash map to a nested loop visibly drops the complexity from quadratic to linear, with the derivation right there in the code. Unfamiliar code becomes analysable because the analysis is something you do, not something you recall.

Originally posted on my own blog, with the amortised analysis derivation for hash-map resize and the space-complexity traps skipped over in this retrospective.

What's a piece of complexity analysis that finally clicked for you only after deriving it by hand, where the textbook label had never really stuck?

BFS vs DFS? The Question That Fixed My Graph Solutions

Fri, 22 May 2026 20:01:47 +0000

For a long time I treated BFS and DFS as interchangeable. Two ways to visit every node, pick whichever came to mind first. Then an interview handed me a grid that wanted the minimum number of steps, and a recursive DFS felt faster to type, so that's what went down. The path that came back was valid and far too long. No error. Just an answer that passed the small cases and fell apart on the one that mattered, with no obvious reason why.

What finally clicked:

The two traversals hold different invariants. They don't just visit in a different order.
The queue gives BFS its shortest path guarantee. The stack makes DFS commit to one branch.
"Minimum" in an unweighted graph turns out to be a reliable signal for BFS.
"Detect", "order", and "all paths" point to DFS.
Once edges carry weights, neither applies, and Dijkstra's algorithm takes over.

Where my approach was breaking

The mistake wasn't picking the slower traversal. It was reaching for whichever traversal got practiced most recently instead of reading what the problem actually asked for.

A grid that wants the fewest steps is asking for a distance guarantee, and DFS doesn't offer one. It happily commits to a branch and walks 30 cells deep before it would ever consider the 8 cell route, then stops the moment it touches the goal, satisfied with a path that happens to be valid. The wrong choice there has nothing to do with DFS being worse. It comes from never asking what kind of answer the problem needed.

The one question that changed it

Before writing any code now, the question is always the same: does this problem need a distance guarantee or a structural property? If the answer is distance, that's BFS. If it's structure, meaning cycles, ordering, or which nodes connect to which, that's DFS.

It sounds almost too simple, and that's the point. The decision was never about which algorithm you can implement faster. It's about which guarantee the problem is quietly demanding.

What that looked like on the same six node graph

The clearest way to feel the difference is to run both on one small graph and watch the order. Take six nodes with edges 0→1, 0→2, 1→3, 1→4, 2→4, 2→5, starting from node 0.

from collections import deque

graph = {0: [1, 2], 1: [3, 4], 2: [4, 5], 3: [], 4: [], 5: []}

def bfs(start):
    order, seen, q = [], {start}, deque([start])
    while q:
        node = q.popleft()
        order.append(node)
        for nxt in graph[node]:
            if nxt not in seen:
                seen.add(nxt)
                q.append(nxt)
    return order

def dfs(start):
    order, seen, stack = [], set(), [start]
    while stack:
        node = stack.pop()
        if node in seen:
            continue
        seen.add(node)
        order.append(node)
        for nxt in reversed(graph[node]):
            if nxt not in seen:
                stack.append(nxt)
    return order

print(bfs(0))  # [0, 1, 2, 3, 4, 5]
print(dfs(0))  # [0, 1, 3, 4, 2, 5]

BFS visits in exact distance order: everything one hop from the source (1, 2) before anything two hops away (3, 4, 5). DFS visits 3 before it ever gets back to 2, even though 3 sits further from the source. It cares about depth, not distance. Swapping the queue for a stack is the only structural change between the two functions, and it produces the entire difference in behaviour.

Why this works (the part that took digging)

A queue is first in, first out, so the nodes you discover at distance d always come out behind the remaining d-1 nodes and ahead of the d+1 ones. That ordering is the shortest path guarantee, with no explicit distance tracking needed. A stack is last in, first out, so the most recent branch always gets expanded next, which is depth first by construction.

There's a memory split that follows from the same fact. BFS holds the full frontier, so its peak memory tracks the widest level of the graph. DFS holds only the current path, so its memory tracks the deepest one. Tracing both algorithms frame by frame in the graph course, watching the queue and stack contents change at every step, is what makes the distance ordering stop feeling abstract.

What to do when you're still guessing

If you're staring at a graph problem and reaching for habit, run it through this instead:

If the problem asks for	Reach for
Shortest path or fewest moves, equal cost edges	BFS
Level by level processing	BFS
Nearest target	BFS
Cycle detection	DFS
Topological order	DFS
Connected components	DFS
All paths or backtracking	DFS
Shortest path with weighted edges	Neither, use Dijkstra

I originally posted this on my own blog, a slightly longer version with a directed cycle detection walkthrough.

What's a graph problem that finally made the BFS versus DFS choice click for you, the one where guessing wrong actually cost you in an interview?

Backtracking Finally Clicked When I Fixed One Habit

Thu, 21 May 2026 16:14:14 +0000

For a long stretch, backtracking was the topic I quietly dreaded. The recursion was easy enough to write. The code ran. It even returned answers. They were just wrong, and not in a way that threw an error you could chase. A Combination Sum solution would spit out duplicate-looking results with no obvious culprit line. The fix, when it came, had nothing to do with understanding recursion better. It was one habit that kept getting skipped.

Here's what changed once backtracking stopped being a clever trick and became a fixed loop.

What changed

Backtracking is a depth first walk over a state space tree, and the tree is the part worth drawing first.
The loop is always the same: choose an option, check the constraint, undo the choice on the way back up.
The undo step is the easiest to drop, and dropping it silently corrupts later branches.
Pruning before you recurse, not after you reach a leaf, is where the speed lives.
Once the same partial state repeats across branches, the whole thing becomes top down DP.

Where my backtracking kept breaking

The mistake was always the same, and naming it took embarrassingly long. You build a partial solution by mutating a shared list, recurse, then move on to the next option without ever putting the list back the way you found it. So branch two starts with branch one's leftovers still inside it.

What broke wasn't the recursion. It was that the path never got restored on the way back up.

The reason it's so hard to catch: nothing crashes. A forgotten undo doesn't raise an exception. It quietly hands stale state to the next branch, and the answers look plausible until you check them by hand. That single omission costs more debugging time than any actual algorithmic concept.

Picture it concretely on a small Combination Sum case, candidates [2, 3] and target 5. The first branch explores [2, 2, ...], overshoots, and returns. If that branch left a stray 2 in the shared list, the next branch starts from [2] when it should start from []. Now the [3, ...] branch is really exploring [2, 3, ...], and the result set fills with combinations that were never asked for. Reading the function top to bottom, every line looks reasonable. The bug only shows up when you trace the shared list across two sibling branches and notice it isn't the same length going in as coming out.

What I started doing differently

The shift was to stop writing backtracking freehand and write the same three line frame every time, then fill it in. Choose, check, undo, in that order, with the undo non negotiable. Here's the before and after, once it became a fixed habit:

Then	Now
Recursion written ad hoc, undo when remembered	Choose, check, undo written as a fixed frame first
Constraints checked at the leaf	Constraint checked before recursing, so dead branches die early
Debugged by re-reading the whole function	Trace one branch, confirm state is restored after the call
Each problem treated as new	Slot the problem into one of three known shapes

The "check before recurse" row mattered more than expected. Pruning at the leaf still gives correct answers, it's just slow, and on a tight time limit slow is the same as failing.

What that looked like on Combination Sum

Combination Sum is the problem that finally made it click for me. Given a list of candidates and a target, find every combination that sums to the target, where a number can be reused. It's a conditional enumeration problem, so you prune any branch whose running sum overshoots.

Here's the frame, filled in:

def combination_sum(candidates, target):
    result = []

    def backtrack(start, path, remaining):
        if remaining == 0:
            result.append(path[:])      # finished combination
            return
        if remaining < 0:
            return                      # overshot, prune this branch
        for i in range(start, len(candidates)):
            path.append(candidates[i])                       # choose
            backtrack(i, path, remaining - candidates[i])    # explore (reuse allowed)
            path.pop()                                       # undo

    backtrack(0, [], target)
    return result

The line that used to go missing is path.pop(). Without it, every combination after the first carries elements from the previous one. The path[:] matters too, it copies the list into the result instead of storing a reference that later pop calls would mutate out from under you. Two small lines, and they're the entire difference between a function that works and one that lies to you.

The start index is the other quiet detail. Passing i rather than i + 1 into the recursive call is what allows a number to be reused. Pass i + 1 and you've written a different problem, combinations without repetition. Same frame, one parameter changes the meaning.

Why undoing state is the whole game

With the frame in hand, the three problem shapes read as one idea seen from different angles:

Unconditional enumeration, like all subsets, has no constraint, so you walk the whole tree and every node is an answer.
Conditional enumeration, like Combination Sum or valid parentheses, prunes branches that break a rule mid build.
Backtracking search, like N-Queens or Sudoku, looks for configurations under a global constraint and prunes hardest.

All three run the same choose, check, undo loop. The undo is what lets one mutable structure stand in for every node of the tree without the nodes contaminating each other. That's the thing I ended up rebuilding my own approach around.

It also reframes how the three shapes relate. They aren't three separate algorithms to learn. They're one loop with the constraint check dialled from off (subsets) to mid build (Combination Sum) to every level (N-Queens). Seeing them as one thing meant a new problem stopped being a blank page. The question became which shape it was and what the constraint was, and the frame handled the rest.

What I'd tell someone stuck on this

If you're losing time to backtracking that returns wrong answers, the fix is almost never more practice on harder problems. Grinding ten more search problems with the same blind spot just produces ten more silently wrong solutions. The thing standing between you and reliable backtracking is usually one missing line, not a missing concept. It's two habits. First, write the undo line at the same moment you write the choose line, as a pair, before anything else in the loop. Second, trace one full branch on paper and confirm the shared state looks identical before and after the recursive call.

And if the recursion itself still feels unstable underneath all this, that's worth shoring up first, because backtracking is just recursion with the choose, check, undo wrapper on top. Going back through the recursion lessons before touching backtracking again is what makes the wrapper feel mechanical instead of magical.

I originally posted this on my own blog, a slightly longer version with the N-Queens trace and a few more worked examples.

What's a bug that taught you more than the algorithm itself? For a lot of people backtracking is the one where a missing undo quietly breaks everything.

Most Candidates Memorize Merge Intervals. Few Actually Understand It.

Thu, 21 May 2026 12:13:33 +0000

Recently while practicing interval problems, I noticed something interesting:

A lot of interview questions are actually small twists of the same underlying pattern.

Take the classic Merge Intervals problem:

intervals = [[1,3], [2,5], [6,8], [7,9]]

The first important step is almost always:

intervals.sort(key=lambda x: x[0])

Once intervals are sorted, overlap decisions become local.

Then the core logic becomes:

if start <= merged[-1][1]:

which simply means:

current interval overlaps with previous interval

and we merge them.

Final result:

[[1,5], [6,9]]

Pretty straightforward.

But interviewers often twist the same idea into a different question.

One famous variation is:

“Given meeting intervals, find the minimum number of meeting rooms required.”

Example:

[[1,10], [2,7], [3,19], [8,12]]

Now the goal is no longer merging.

Instead, while processing intervals, we need to figure out:

how many meetings are active simultaneously at any moment.

Because that directly tells us:

how many rooms are required.

At one point here:

[1,10]
[2,7]
[3,19]

are all active together.

So answer becomes:

3 rooms

That’s what makes interval problems interesting in interviews.

The pattern stays similar:

sort,
process left to right,
reason about overlaps,

but the objective changes completely.

I wrote a detailed article around this covering:

Merge Intervals intuition,
Meeting Rooms II,
sweep-line thinking,
Python templates,
and how to recognize interval patterns during interviews.

You can read detailed article here.

AVL Trees Explained: The Rotation Patterns Most People Memorise Wrong

Wed, 20 May 2026 19:57:13 +0000

The first time an interviewer asked me to walk through an LR rotation on a whiteboard, the four-case table was memorised cold. LL, RR, LR, RL. The interviewer drew three nodes, asked which case it was, and the answer came out fast. Then they asked: "predict what a single right rotation would do to that tree, and tell me why it fails." That part hadn't been drilled. The grade went out as "knows the table, didn't internalise the invariant."

What I figured out

The four rotation cases are not four things. They're two atomic moves applied once or twice.
The balance factor is the rule being protected, not a check. Every rotation is a local repair on the rule |left_height - right_height| <= 1.
Insertion needs at most one rotation. Deletion can need O(log n). That asymmetry is the answer to every "what's the tradeoff" question.
The double-rotation cases exist because a single rotation on an "inside" imbalance shifts the heavy side without reducing the depth.
Knowing the two atomic moves is enough to derive both LR and RL cases. Memorising the table on top is the wrong study target.

Where my approach was breaking

Three failure modes showed up on those rounds, and they show up in most engineers preparing for the same kind of question.

The four-case table got memorised without anyone tracing why each fix works. The table is a lookup. Interviewers test for the derivation. When a tree shows up on the board and the question is "what's the imbalance shape here," pattern matching against a remembered picture fails when the tree is rotated or relabelled.

Insertion got drilled, deletion didn't. Insertion is the cleaner operation. Almost every textbook walks insertion. Few walk deletion with the upward rebalance loop. Knowing "deletion is harder" as a phrase is not the same as knowing what concretely makes it harder.

Wrong rotations never got sketched. When an interviewer asks "what happens if you apply a single right rotation to an LR case," the answer has to come from a drawing, not a memory. Engineers who've never traced a failed rotation can't answer this on the spot.

What I started doing differently

Then	Now
Memorise LL / RR / LR / RL as four rotations	Internalise two atomic rotations and derive the four cases from balance factor signs
Practice insertion only	Practice deletion with the upward loop, including the worst-case `O(log n)` rotation chain
Treat balance factor as a check	Treat balance factor as the invariant being protected, with rotations as the local repair
Draw rotated trees from memory	Draw the pointer assignments explicitly and recompute heights before moving on
Skip wrong-rotation traces	Sketch what each wrong rotation does on an LR case, so the trap is recognisable under pressure

The "now" column is what interviewers actually probe. The "then" column is what most prep material asks you to drill.

The first rule that locks in is this. If you see a node with balance factor +2, the next look is at the left child's balance factor, not at the rotation table. If the left child is +1 or 0, single right rotate the parent. If the left child is -1, left rotate the left child first, then right rotate the parent. The decision is two questions, not a memorised table.

What that looked like on the next problem

Six months later, a different round asked for AVL insertion implementation. The sequence used to motivate the walk-through was [5, 3, 4], which fires an LR rotation. Here's the primitive:

def right_rotate(z):
    y = z.left
    T3 = y.right
    y.right = z
    z.left = T3
    z.height = 1 + max(height(z.left), height(z.right))
    y.height = 1 + max(height(y.left), height(y.right))
    return y

And the insertion function:

def insert(node, key):
    if not node:
        return Node(key)
    if key < node.key:
        node.left = insert(node.left, key)
    else:
        node.right = insert(node.right, key)

    node.height = 1 + max(height(node.left), height(node.right))
    bf = balance_factor(node)

    if bf > 1 and key < node.left.key:
        return right_rotate(node)
    if bf < -1 and key > node.right.key:
        return left_rotate(node)
    if bf > 1 and key > node.left.key:
        node.left = left_rotate(node.left)
        return right_rotate(node)
    if bf < -1 and key < node.right.key:
        node.right = right_rotate(node.right)
        return left_rotate(node)

    return node

Tracing [5, 3, 4]:

Insert 5. Single node, balance factor 0.
Insert 3. Goes left of 5. Node 5's balance factor is +1. Within the rule.
Insert 4. 4 < 5, go left. 4 > 3, go right of 3. Node 4 lands as 3's right child.

Walking back up: node 4 is balance factor 0, node 3 is -1, node 5 is +2. Rule broken at node 5, with its left child right-heavy. That's LR.

First rotation: left rotation on node 3. Node 4 moves up, node 3 becomes 4's left child. Node 5 still has balance factor +2, but its left subtree is now left-heavy. That's LL.

Second rotation: right rotation on node 5. Node 4 becomes the root, node 3 is 4's left child, node 5 is 4's right child. All balance factors back to 0. Height is 1.

The interviewer asked what a single right rotation would have done to the original tree. Sketched it out: node 3 becomes the root, node 5 is 3's right child, but node 4 ends up as 3's right child too, with node 5 displaced. The tree depth does not decrease. That's why the double rotation exists.

Why this works (the height theory behind it)

The choice of ±1 as the balance factor cap is not arbitrary. It's the tightest constraint that's still cheap to maintain locally.

An AVL tree with n nodes has height at most about 1.44 * log2(n). For a million nodes that's roughly 29 levels. A perfectly balanced tree would be 20 levels. The constant factor is small enough that you get the lookup speed of a balanced tree without paying the cost of full rebalancing on every insert.

Red-Black trees relax the constraint to allow heights up to about 2 log(n). That's roughly 40 levels for a million nodes. In exchange, at most 2 rotations per insertion or deletion. Looser balance, fewer rotations, faster writes.

When Adelson-Velsky and Landis named the AVL tree in 1962, the workload they had in mind was read-heavy. Lookups dominated. The strict balance was worth the rebalancing cost because every lookup was faster. Modern systems insert and delete more than they search-only, which is why Java's TreeMap, C++'s std::map, and Linux's CFS process scheduler all picked Red-Black instead. Different workload, different tradeoff. Neither tree is "better."

That's the answer the OS interviewer was looking for. AVL is read-optimised. Red-Black is tuned for mixed workloads. Picking between them is a workload question, not a theory question.

What I'd tell someone in the same spot

Three things to drill before either interview round:

Master the two atomic moves. Write left_rotate and right_rotate from memory, with the height updates in the right order. Three pointer reassignments, two height updates. Everything else builds on these.
Trace deletion at least three times. Pick at least one trace where the rebalance propagates two levels up. That's the answer to every "what's the tradeoff of stricter balance" question.
Sketch what a wrong rotation does on an LR case. Once you've drawn the broken tree, the LR / RL trap stops being a memory test.

Codeintuition's Binary Search Tree course is structured this way. The balance invariant comes before the rotation code, and the rotation code comes before the four-case table. Doing it in that order is what made the table feel mechanical instead of memorised.

I originally posted this on my own blog, a slightly longer version with the worked example for the original [3, 2, 1, 4, 5] insertion sequence and the AVL vs Red-Black tradeoff matrix.

What's the AVL or rotation question that finally made the rule click for you, where the textbook explanation had not?

Interview: Pocket Portfolio × CoderLegion

Mon, 18 May 2026 10:47:53 +0000

Interview: Pocket Portfolio × CoderLegion

1. An Overview of Your Professional Trajectory in Software Development

My introduction to programming commenced at age fifteen with Java, spanning from Standard to Enterprise editions (J2SE to J2EE) at Emerging Trees in Kaduna. Driven by an early interest in mobile environments, I focused on developing recreations of classic titles like Snake and Tetris.

This practical sandbox naturally led me to pursue Electronic Engineering at the university level, which deeply refined my technical perspective on programmable hardware, silicon-level constraints, and the Internet of Things (IoT). My career has since evolved into developing high-throughput software ecosystems that leverage complex hardware and sensor telemetry, including architecting enterprise IBM MQTT telemetry transport stacks for heavy industry.

I maintain the core architectural conviction that software and underlying infrastructure are intrinsically linked; a truly resilient digital ecosystem requires their seamless, stateless integration.

2. Insights Regarding Educational Methodology and Mentorship

As a purely kinesthetic learner, I have always prioritized a practical, compiler-first approach to education. I operate under the professional philosophy that complex theoretical concepts must be validated through active, successful artifact implementation. This mindset guided my self-directed mastery of data science frameworks in Python and typescript edge environments.

However, self-study is only half the equation; I was privileged to receive rigorous, traditional academic instruction in Assembly, C, and Node.js. My early mentors emphasized the strategic application of these tools over pure syntax, providing critical guidance on memory management, lifecycle optimization, and algorithmic efficiency.

Consequently, my technical posture is a hybrid product of relentless individual sandbox building and high-fidelity mentorship from industry leaders who taught me to code for purpose.

3. Professional Challenges Encountered and Subsequent Lessons Learned

The most acute challenge I have navigated—which serves as a defining crucible for any technical founder—is the problem of Distribution. Building elegant software is an incomplete victory if you fail to establish a clean network of high-intent users who recognize its functional and structural value.

We systematically addressed this at Journey Labs by discarding legacy, transactional marketing plays in favor of first-principles technical transparency. For instance, during our recent launch of Pocket Portfolio, we chose to "Build in Public," exposing our architecture decisions directly to the community.

When we realized our enterprise users required distinct procurement guardrails, we didn't spin up a separate code repository; we executed a dual-surface split at the network edge via host-aware middleware, launching Open Portfolio alongside our consumer app.

The lesson is clear: your distribution strategy must be as modular and adaptive as your codebase. We cultivate a dedicated community of stakeholders rather than merely chasing transactional user metrics.

4. Engagement and Alignment with the CoderLegion Community

CoderLegion has proven to be an indispensable node in our developer outreach loop. The development of sovereign, local-first architecture—where data parses strictly in-browser via client-side adapters and stays stored in user-owned volumes—cannot happen in a corporate silo. It requires decentralized, collaborative peer review.

Direct access to CoderLegion’s highly refined talent pool is vital as we open-source our standardized core parsers. We aren't just looking for passive download metrics; we are actively engaging this community to help influence and establish the open-source benchmarks for global financial data normalization.

5. Advisory Remarks for the Developer Community

Maintain an uncompromising standard of intellectual curiosity, and never outsource your fundamental understanding of the stack. Software development is an aggressive, iterative process. The moment you stop building sandboxes to test new constraints is the moment your technical edge begins to decay.

Strive for continuous runtime optimization in your own career—compile your failures into experience, optimize your personal feedback loops, and always build with clear, uncompromised purpose.

FAANG Coding Interviews Aren’t the Same: The DSA Patterns Each Company Actually Tests

Tue, 12 May 2026 15:44:03 +0000

After treating every FAANG company like the same interview, Amazon exposed the gap in about twenty minutes.

I'd built FAANG prep around a small set of pattern families that looked highest-frequency: predicate search, sliding window, hash table fundamentals, and a few graph traversals.

The mental model was that these were the patterns "every big tech round" sampled from.

The first Amazon round asked about Randomised Set design followed by a Queue Design follow up.

Neither was in the deep set the plan covered.

I solved the first one with effort and improvised the second one badly.

The interview went south in the last 20 minutes.

The thing missing wasn't a specific pattern.

It was that Amazon's pattern footprint is meaningfully wider than Google's, and the prep allocation behind every hour was treating every FAANG company as if they sampled from the same bag.

Here's what came out of mapping company tags across 450+ handpicked FAANG problems:

Seven patterns are universal across 6+ major companies. Skipping any of them is a structural hole.
Amazon spans 11+ pattern families, the broadest in the data. "Study three patterns deeply" doesn't work there.
Google has narrower coverage but a distinctive emphasis on predicate search (binary search on the answer space).
Meta wants hash table depth and design fluency in a tighter pattern band.
Prefix Sum is the single most undertrained pattern relative to its 8-company tag count.

Where the old approach was breaking

The old plan looked roughly like this:

Pick five or six pattern families that look universal-ish, drill them to the point you can write the canonical solution from memory, then trust that volume on adjacent problems will generalise to whatever the interview throws.

The implicit bet was that every FAANG company is a sample from roughly the same distribution, and the mean of the drilled patterns covers the mean of the question pool.

The data didn't support the bet.

The surprising part wasn't that companies differed.

It was how much they differed.

Across the company tags:

Google's distribution skewed toward predicate search and graph reasoning. Narrower set, harder reasoning per problem.
Amazon's distribution was the flattest of any company in the set. Eleven plus pattern families, none dominant.
Meta's distribution clustered tight: sliding window, prefix sum, counting, design.
Microsoft had a quietly distinct cluster: 2D binary search and staircase search, multi-dimensional patterns most plans skip.
Apple's distribution was the inverse of Amazon's: deep on fundamentals (especially counting), almost no advanced design.

The mistake wasn't drilling the wrong patterns.

It was applying the same allocation across companies that didn't share the same allocation.

The shift that worked

The shift was small in description and large in practice.

Instead of one prep plan, the move was to build a per-company allocation, anchored to the universal patterns underneath.

Concretely:

Then	Now
Drill 5–6 patterns deeply, hope coverage generalises	Cover 7 universals first, then add 2–4 patterns specific to the target company
Pick problems by data structure (Hash Table, Tree, Graph)	Pick problems by pattern, then filter by company tag
Treat all FAANG rounds as the same problem distribution	Allocate by the company’s actual tag profile
Practise at uniform intensity across pattern families	Front load the universals, then go deep on company-specific gaps

The 7-pattern universal layer never moved:

LRU Cache
Counting
Backtracking
Prefix Sum
Binary Search
Fixed Sliding Window
Variable Sliding Window

What changed was what came after.

For an Amazon round, the next four patterns to drill were:

Randomised Set
Queue Design
2D Binary Search
Staircase Search

plus dedicated time on the Bar Raiser follow up format.

For Google, the next two patterns were:

Predicate Search
Graph reasoning

drilled deeper.

For Meta:

Design depth (LRU Cache from scratch, Randomised Set from scratch)
Maximum Predicate Search

The total prep time stayed roughly the same.

The allocation was different.

What that looked like on the next problem

The clearest example was LRU Cache.

The canonical solution had been in the toolkit for years:

hash map + doubly linked list
O(1) per operation
head and tail sentinels

What I'd never done was rebuild it under a constraint shift.

Which is exactly what the Amazon Bar Raiser round likes to test.

The setup is the standard one:

class LRUCache:
    def __init__(self, capacity):
        self.capacity = capacity
        self.map = {}
        self.head = ListNode()                    # most recently used end
        self.tail = ListNode()                    # least recently used end
        self.head.next = self.tail
        self.tail.prev = self.head

    def get(self, key):
        if key not in self.map:
            return -1
        node = self.map[key]
        self._remove(node)
        self._add_to_front(node)
        return node.value

    def put(self, key, value):
        if key in self.map:
            self._remove(self.map[key])

        node = ListNode(key, value)
        self._add_to_front(node)
        self.map[key] = node

        if len(self.map) > self.capacity:
            lru = self.tail.prev
            self._remove(lru)
            del self.map[lru.key]

The constraint shift Amazon likes to ask:

“Now each entry has a TTL. A read on an expired entry returns -1. The cache still operates at expected O(1) per call.”

That's the moment the canonical answer stops being enough.

The candidate who memorised LRU starts redesigning from scratch.

The candidate who built the original from the invariant asks one question first:

Which invariant did the doubly linked list maintain, and does that invariant still hold under TTL?

The list maintained an ordering:

Nodes near head were used more recently than nodes near tail.

The eviction criterion changes from:

“Least recently used”

to:

“Expired or least recently used.”

The list ordering by recency is still useful for the second clause.

The first clause needs a different signal.

That's where lazy expiry (timestamp checked on read) and eager expiry (min heap on TTL) diverge.

The canonical LRU sits in most candidates' heads.

The constraint flip doesn't.

Once practising the follow up explicitly becomes part of the loop, on every design problem in the universal set, the conversion rate on Amazon-style rounds shifts noticeably.

The pattern that's underrated for years

Looking back at the tag data, the single biggest miscalibration in the old plan was Prefix Sum.

Eight companies tag it.

That's the same as Backtracking.

More than almost every classic searching variant except the basic one.

Most prep plans treat it like a minor utility pattern because it doesn't have a flagship problem the way LRU Cache does.

In the data, it punches above its weight:

Subarray Sum Equals K
Equilibrium Index
Count Subarrays Divisible by K

especially in Meta and Amazon variants.

The fix took less than a weekend.

Prefix Sum's mechanic is small enough that two evenings of focused drilling cover it.

The composite version (prefix sum + hash map of seen sums) is the FAANG-shaped one, and it's the one most prep plans bury under a miscellaneous heading.

What works for someone in the same spot

Three rules from the retrospective:

1. Cover the seven universals first

No exceptions.

LRU Cache
Counting
Backtracking
Prefix Sum
Binary Search
Fixed Sliding Window
Variable Sliding Window

No matter the target company.

2. Specialise second

But specialise to the company’s actual tag profile.

For Amazon:

breadth
constraint-flip follow ups

For Google:

predicate search
graph reasoning depth

For Meta:

design depth
sliding window fluency

For Microsoft:

2D + staircase search

For Apple:

fundamentals depth

3. Cut what doesn't match

Targeting Google and not Amazon?

Queue Design can wait.

Targeting Meta and not Microsoft?

Staircase Search can wait.

Prep time is finite.

The data tells you where the false-priority work lives.

The biggest shift, though, wasn't any one pattern.

“FAANG prep” isn't one allocation problem.

It's five separate ones with a shared seven-pattern foundation.

The company determines which 2–4 patterns sit on top of it.

Every hour spent assuming the foundation was all that mattered was an hour that could've gone to the layer above.

Originally posted in a longer form on my own blog, with the per-company FAQ and a fuller breakdown of what each company quietly deemphasises.

If you've interviewed at more than one FAANG, what was a pattern that came up where the company’s reputation hadn't prepared you for it?

What Amazon’s Bar Raiser Actually Tests in Coding Interviews

Mon, 11 May 2026 14:47:38 +0000

I thought solving the problem was the round. The last ten minutes turned out to be the part that counted.

I'd put close to four months into Amazon prep by the time my onsite landed. Two coding rounds went fine. The third started fine too.

I solved the initial problem in about twenty minutes, walked through the test cases, and felt the round was already mostly won.

Then the interviewer asked one follow up.

The constraint they changed was small, the kind of thing I'd have called "minor" if I'd been describing it on paper.

It exposed that I'd been preparing for the wrong half of the round, and I spent the next ten minutes recovering ground I should never have lost.

That round was a Bar Raiser round.

I didn't know it at the time (Amazon doesn't tell you), but the debrief came back with the kind of feedback only the Bar Raiser writes:

"Strong initial solution, struggled to adapt under constraint change, did not demonstrate the structural reasoning we look for."

The phrasing is almost word for word from how Bar Raisers grade.

The follow up after the working solution is the round.

What I figured out

The Bar Raiser is one of the four or five interviewers on the loop, but you won't know which one. Treat every round as if it's them.
Amazon's pattern coverage is wider than Google's or Meta's, so going deep on three families isn't enough.
The grade often lives in the last ten minutes after your first working solution, not in the first solution itself.
Adapting after a constraint flip is a specific skill that grinding more problems doesn't build.
The fix is interleaved practice plus an explicit constraint flip rep on every problem.

Where my approach was breaking

My prep model was the standard FAANG one.

Pick the two or three pattern families that show up most for the company. Go deep on those. Time myself on company tagged problems. Repeat until recall got fast.

For Google that worked well enough.

Google leans heavily on predicate search, counting, and graph traversal. If you're solid on those three, the round usually lands in your zone. I'd interviewed at Google with that exact prep and it had been fine.

Amazon's pattern set is wider.

Across the problems Amazon actually tests, you'll see:

counting
fixed and variable sliding window
prefix sum
LRU-style design
randomized set design
plain binary search
2D and staircase binary search variants
queue design
backtracking

That's roughly eleven distinct families against Google's seven or eight.

The depth strategy that worked for Google had a worse hit rate at Amazon, and on the round that turned into the Bar Raiser slot, the problem landed in a family I'd given less time to.

The deeper issue was something the wider pattern coverage just made more visible.

Even on patterns I had practised, my fluency was template recall, not invariant construction.

As long as the problem looked enough like a textbook example, I produced the standard solution quickly.

The moment the constraint shifted, I tried to retrieve a different template instead of modifying the one I had.

The Bar Raiser format is built to expose that gap.

The follow up after the working solution is the round.

What I started doing differently

After the rejection landed, I went back through every coding round I'd done in mock interviews, including the ones I'd thought went well.

Two patterns showed up across roughly half of them:

I'd produced a correct solution within the time budget, but I couldn't have explained which invariant the data structure I picked was maintaining. The hash map worked. I couldn't have said cleanly what would break if I'd used an array instead.
When the mock interviewer changed a constraint at the end (which the better mocks always did), I either started from scratch or stalled. I almost never reached for the original solution and asked which part of it depended on the constraint that had moved.

Both were habits I'd built by drilling for speed against template problems.

Neither was a coding skill I lacked.

They were prep habits.

I shifted two things.

First, every problem I solved got a constraint flip rep.

Whatever the original constraint was, I changed one piece of it and reimplemented.

Second, I started reading my old solutions out loud as if explaining them to an interviewer, naming the invariant the structure maintained on every line.

The first felt like more work for the same problem count.

The second felt like wasted time.

Both turned out to be the gap.

Here's what changed in practice:

What I used to do	What I started doing
Solve the problem, check the answer, move on	Solve the problem, then write down the constraint change that would invalidate the solution most
Drill problems within one pattern family per week	Rotate between three or four pattern families inside a single session
Recall the optimal solution before writing any code	Get a correct `O(n²)` working first, confirm edge cases, then improve
Treat the follow up question in mocks as a bonus	Treat the follow up as the main rep
Explain the solution by walking through the code	Explain the solution by naming the invariant first

What that looked like on the next Word Search follow up

A few weeks later I ran a mock that landed on Word Search.

Standard backtracking on a grid:

Given a board of characters and a target word, return whether the word can be formed by a path of adjacent cells, with no cell reused.

The solution is a depth first search from each starting cell with a visited mark.

def exist(board, word):
    rows, cols = len(board), len(board[0])

    def dfs(r, c, idx):
        if idx == len(word):
            return True
        if r < 0 or r >= rows or c < 0 or c >= cols:
            return False
        if board[r][c] != word[idx]:
            return False

        tmp = board[r][c]
        board[r][c] = '#'

        found = (
            dfs(r+1, c, idx+1)
            or dfs(r-1, c, idx+1)
            or dfs(r, c+1, idx+1)
            or dfs(r, c-1, idx+1)
        )

        board[r][c] = tmp
        return found

    for r in range(rows):
        for c in range(cols):
            if dfs(r, c, 0):
                return True

    return False

The invariant the in-place marking maintains:

At any point in the recursion, the cells along the current path are marked #, every other cell is restored.

Backtracking by restoring on the way out keeps the invariant true at depth zero, which is what makes:

“No cell reused along this path”

hold.

Then came the follow up.

Instead of a single word, you now have a list of k words to find on the same board.

Same constraint.

No cell reused along a single word's path.

The old me would've started writing:

for w in words:
    exist(board, w)

taken the cost of:

O(k * rows * cols * 4^L)

and gone home.

The interviewer would've asked the obvious question:

“Can you do better than the naive loop?”

Which is exactly what had happened in the real round.

This time I asked a different question first:

Which part of the original solution depended on the constraint that just changed?

The DFS was doing the same prefix walk repeatedly for every word sharing a prefix.

So instead of changing the traversal:

Change what the traversal checks against.

Compose the DFS with a trie of all k words.

Every board walk now checks against all words simultaneously.

The invariant doesn't change.

The base case changes.

The grid traversal stays.

The constraint changed.

Not the structure.

def find_words(board, words):
    root = build_trie(words)
    rows, cols = len(board), len(board[0])
    found = set()

    def dfs(r, c, node):
        ch = board[r][c]

        if ch == '#' or ch not in node.children:
            return

        nxt = node.children[ch]

        if nxt.word:
            found.add(nxt.word)
            nxt.word = None

        board[r][c] = '#'

        for dr, dc in ((1,0), (-1,0), (0,1), (0,-1)):
            nr, nc = r + dr, c + dc

            if 0 <= nr < rows and 0 <= nc < cols:
                dfs(nr, nc, nxt)

        board[r][c] = ch

    for r in range(rows):
        for c in range(cols):
            dfs(r, c, root)

    return list(found)

I got there in roughly four minutes.

Not because I'd drilled Word Search II as a separate template.

Because I'd been practising one question repeatedly:

Which part of the original depended on the constraint that changed?

The change was in what the DFS checked.

Not in the DFS itself.

Why interleaving works for breadth

The other half of the gap was simply pattern coverage.

Three families deep wasn't enough for Amazon's surface area.

But I also couldn't realistically go equally deep on eleven families in the time I had left.

What I could do was rotate between them.

Research on interleaved practice consistently shows that mixing problem types improves your ability to identify which pattern applies to a new problem.

Mixed practice feels harder.

Blocked practice feels easier.

That's exactly why it works.

Blocked practice gives you:

“This week is sliding window.”

The Bar Raiser gives you:

“Figure out what this is.”

The added friction during practice was the same identification work the round required.

Practically, that meant:

A session of four problems became:

four different families

not:

four sliding window problems.

What I'd tell someone in the same spot

A few rules I wish I'd had four months earlier.

1. Get a working solution before chasing the optimal one

Twenty-five minutes thinking before writing leaves no room for the follow up.

A correct O(n²) solution that gets improved beats a half-written O(n) attempt every time.

2. Treat the follow up as the round

When the interviewer changes a constraint:

Ask which part of your solution depended on that constraint.

Modify only that part.

The instinct to redesign from zero is expensive.

3. Practise the constraint flip explicitly

Every problem gets a second pass with one constraint changed.

Implement the modified version.

That rep builds adaptation.

And adaptation is what the round grades.

If someone had explicitly taught me how to identify which part of a solution depends on a changing constraint, it would've shortened the loop considerably. The closest thing to the work I had to build for myself later was a pattern-identification lesson I eventually added inside Codeintuition.

I originally posted a longer version on my own blog with the per-pattern breakdown across all eleven families and how the rest of Amazon's interview loop factors into the Bar Raiser grade.

What’s a constraint flip from an interview that exposed a solution you thought you understood?

Arrays vs Linked Lists: The Real Difference Most Interview Prep Misses

Sun, 10 May 2026 13:06:23 +0000

It took an LRU Cache interview for me to realise the complexity table wasn't answering the real question.

I'd been picking between arrays and linked lists for years before realising the table wasn't the answer to the question.

Then LRU Cache came up in an interview, and the table didn't help: both structures were on the page, neither alone solved the problem, and the silence ran nine minutes before the interviewer gave a hint.

What I figured out

Arrays and linked lists differ for one reason: contiguous memory vs scattered memory. Every entry on the complexity table follows from that single fact.
Two O(n) operations aren't equal in practice. An array scan of a million integers runs roughly an order of magnitude faster than the equivalent linked list traversal because of CPU cache locality.
The "O(1) insertion" claim about linked lists comes with a hidden prerequisite: the algorithm has to already hold a pointer to the position. Find it first, and you've paid O(n) before the insertion runs.
Many interesting interview problems combine both structures rather than picking one. LRU Cache is the canonical case.

Where the table stopped working

For a long time the table was the decision tree.

The problem mentioned "insert" or "delete," reach for a linked list. The problem mentioned "access by index," reach for an array.

That worked on simple problems.

It fell apart on anything that needed both behaviours.

The specific moment was sitting in front of LRU Cache.

The problem wants get(key) and put(key, value) both in O(1) average time, with eviction of the least recently used entry when the cache is full.

A hash map handles the lookup half, since get has to be O(1) and a hash map is the obvious answer.

Then comes the recency tracking, which means some kind of ordering on the entries.

An array of (key, timestamp) pairs would mean updating timestamps on access, and the eviction step turns into a linear scan for the smallest timestamp.

That breaks the O(1) requirement.

Switch to a linked list and inserting at the front on every access is O(1) given a pointer to the node.

To find the node from a key, the algorithm walks the list, which is O(n).

The hash map gives O(1) lookups but no reordering.

The linked list gives O(1) reordering but no fast lookup.

The problem wasn't picking the wrong structure.

The problem was thinking the question had only two answers.

The realisation that broke the table

The fix sounds obvious in retrospect:

Keep both.

A hash map mapping keys to linked list nodes, and a doubly linked list whose nodes store the values and recency order.

The hash map gives O(1) access to the exact node.

Once the algorithm has the node, the linked list reorders without traversing in O(1).

Eviction becomes removing the tail node, which is also O(1) because a tail pointer is maintained.

The two structures aren't competing.

They're solving different sub-problems.

The hash map handles constant-time access.

The linked list handles pointer reassignment at known positions.

The qualifier on linked list insertion:

"O(1) only if you already hold the pointer"

finally has a structure feeding it those pointers for free.

That's the same property powering a handful of linked list patterns that previously read like tricks: reversal, splitting, merging, fast and slow pointers.

That's the realisation that broke the table.

The table had been answering:

“If you pick exactly one structure, which one wins?”

The interesting problems were asking a different question:

“Which combination of memory layouts gives every operation in the algorithm the access pattern it needs?”

What it looks like in code

Here's the construction the technique walkthrough lands on:

class Node:
    def __init__(self, key, value):
        self.key = key
        self.value = value
        self.prev = None
        self.next = None

class LRUCache:
    def __init__(self, capacity):
        self.capacity = capacity
        self.lookup = {}                  # hash map: key -> Node
        self.head = Node(0, 0)           # sentinel
        self.tail = Node(0, 0)           # sentinel
        self.head.next = self.tail
        self.tail.prev = self.head

    def _remove(self, node):
        node.prev.next = node.next
        node.next.prev = node.prev

    def _add_front(self, node):
        node.prev = self.head
        node.next = self.head.next
        self.head.next.prev = node
        self.head.next = node

    def get(self, key):
        if key not in self.lookup:
            return -1

        node = self.lookup[key]          # O(1) via hash map
        self._remove(node)               # O(1) via direct pointer
        self._add_front(node)            # O(1) splice at head

        return node.value

    def put(self, key, value):
        if key in self.lookup:
            self._remove(self.lookup[key])

        node = Node(key, value)
        self.lookup[key] = node
        self._add_front(node)

        if len(self.lookup) > self.capacity:
            lru = self.tail.prev         # O(1) via tail sentinel
            self._remove(lru)
            del self.lookup[lru.key]

Every operation is O(1).

The hash map carries the lookup load.

The doubly linked list carries the ordering load.

Each structure does the thing it's actually good at, and the combination handles a problem neither could solve alone.

What I'd tell my earlier self

The contrast between the old picking heuristic and the current one comes out cleanest side by side:

Then	Now
Match keywords in the prompt ("insert" → linked list) to the table.	Identify every operation the algorithm performs and check whether each one already has the pointer or index it needs.
Treat arrays and linked lists as competing answers.	Treat them as primitives that combine.
Quote `O(1)` insertion for linked lists without the qualifier.	Read "`O(1)` insertion" as "`O(1)` once you've paid for the pointer."
Trust two `O(n)` operations as equivalent in practice.	Account for cache locality. Array scans often beat linked list traversals in real hardware.

And three rules that would've shortened the loop:

Identify the dominant operation first. Before picking a structure, write down the access pattern the algorithm needs. "Lookup by key, then mutate at that position" is a different question than "lookup by key, then iterate from there."
Check the qualifier on every linked list insertion claim. Does the algorithm already hold the pointer, or does it have to walk to find it? If it has to walk, the advantage is gone.
When two structures each solve half the problem, try combining them. That's the move that handles LRU Cache, caching problems, and most eviction-style systems.

I wrote a longer version on Codeintuition that walks the same memory-layout reasoning through stacks, queues, and graph adjacency representations.

If you want a deeper walkthrough of pointer-based mutation patterns, the singly linked list course on codeintuition covers seven of them with worked examples.

What was the moment a data structure choice finally clicked for you, where the textbook framing had been hiding the actual question?

How to Know If You’re Ready for FAANG Interviews

Sat, 09 May 2026 12:57:37 +0000

After 280 LeetCode problems, I realised “feeling ready” wasn’t a metric. A diagnostic was.

I'd solved around 280 problems by the time the FAANG readiness question got serious, and the answer changed every week. Some weeks felt close after a clean batch of trees. Most weeks the next unfamiliar medium would freeze cold and the confidence would evaporate by Tuesday. The pattern repeated for months without resolving.

It took longer than it should have to notice the question itself was the issue.

"Do I feel ready" wasn't a question with a stable answer.

The threshold was real. The measurement of it was a mood read on a moving session.

What I figured out

Self assessed readiness drifts every session. A clean morning of trees and a frozen afternoon of graphs both produced wrong answers.
The interview wasn't testing the same skill that practice on familiar problems trains. It was testing what holds up on shapes you haven't seen.
Problem count flatlined as a useful signal somewhere around 100 problems. Past that, more volume on familiar shapes added count without moving the threshold.
The fix was a measurable test, not more prep. An unseen medium, a hidden title, a real timer, repeated across three different families.
The diagnostic was more useful than the score. "Two passed, one failed on graphs" was an action plan. "Feeling 70 percent ready" was anxiety.

Quick disclosure before I get into this: I built Codeintuition, a structured learning platform for coding interviews. This post is the retrospective on what someone should have handed me earlier, not a pitch for the product.

Where the approach was breaking

The first thing that broke was the belief that the count was the metric.

The tracker said 280, on its way to 350. The tracker also didn't predict any individual interview performance. Open a medium you haven't seen, freeze for ten minutes, and the count number sits there grinning at you, useless.

The second thing that broke was the topic completion checkmark.

Sliding window finished in February. By June the recall on a sliding window medium you hadn't seen was unreliable. The completion checkmark didn't decay.

Recall did.

The third thing that broke was speed on familiar problems.

Two Sum in two minutes feels like fluency. It's actually retrieval of a stored solution. The first time you hit a problem that looks like Two Sum but has a different constraint structure, the speed disappears and you're back to staring.

The fourth thing was peer comparison, which broke quietly because it had never worked in the first place.

Someone else got into Google in six months. That said nothing about your readiness. Background, family coverage, how they'd practised, the level they interviewed for, none of it generalises.

What was actually happening is that all four signals were measuring the wrong thing.

The interview gives you a problem you haven't seen. The four signals all measured behaviour on problems you had seen.

They were diagnostically useless for the question they were being asked to answer.

The diagnostic that ended up working

The version that worked was small and strict.

Two hours. Three problems. Three different families. Real interview conditions.

The shape:

Pick a pattern family genuinely studied (sliding window, tree traversal, graph BFS, DP subsequence)
Find a medium difficulty problem in that family that has never been solved, hinted, or read about
Cover the problem name so the title can't reveal the family
Twenty minute timer, hard cap on failed code execution attempts, no peeking
Identify the family from the constraints, build the solution from the family's invariant, trace it before running

A pass was:

solved within the timer
fewer than two failed runs
family identified from the constraints

Anything else was data.

Three passes across three families was a strong readiness signal. Recognition was firing on shapes you hadn't seen, the construction was following the family's invariant rather than recall, and the conditions were close enough to a real round that the result generalised.

Two passes and one failure told you precisely which family to work on. No need for more random volume.

Depth in one specific place.

All three failed was the most useful diagnostic of the three.

It said the prep method had been building near transfer without far transfer, which is the gap described in the idea of Transfer of Learning.

Method gap, not talent gap.

The fix was correspondingly narrower than:

“Grind more problems.”

What that looked like on the third pass

The pass that taught the most was a DP subsequence problem run cold.

The family had been studied. The canonical examples had been worked through. It hadn't been ground the way sliding window or trees had been ground, so it was a fair test of recognition rather than recall.

The constraints described a longest increasing subsequence variant.

With the title hidden, the recognition still happened in the first three minutes because the constraints fit the DP subsequence shape:

A one dimensional input, not two.
An output asking for the longest sub structure satisfying a condition.
The absence of two pointer or sliding window triggers that would have applied if the answer had been contiguous.

The skeleton came from the family's invariant, not from a remembered problem:

dp[i] is the length of the longest valid subsequence ending at index i.

def length_of_lis(nums):
    if not nums:
        return 0

    dp = [1] * len(nums)

    for i in range(1, len(nums)):
        for j in range(i):
            if nums[j] < nums[i]:
                dp[i] = max(dp[i], dp[j] + 1)

    return max(dp)

Trace on a five element array by hand. Verify the recurrence on the trace. Then run.

It passed.

Five minutes still on the timer.

The check that mattered wasn't getting it right.

It was how:

Family identified from the constraints inside three minutes
Skeleton written from the invariant rather than retrieval
Verified by tracing

That's what pattern recognition holding under pressure looks like in practice.

If any of those three steps had broken, the pass would have been a memory pass, not a recognition pass, and the family wouldn't actually have been ready yet.

The protocol the earlier version of me needed

The change that mattered most was switching what practice was for.

Up to about month four practice was for a problem set. After running the diagnostic for the first time, practice changed shape to feed the diagnostic.

Before the diagnostic	After
Solve next problem on the list	Pick a family, work through three problems with the title hidden
Read editorial when stuck	Read the foundational material on the family's invariant when stuck
Track problem count	Track families where the diagnostic passes cleanly
Do problems in order of difficulty	Do problems in order of how shallow recognition was on the family
Speed up by recognising problems	Speed up by recognising the family from constraints with the title hidden
"How many problems before I'm ready"	"How many families pass the diagnostic before I'm ready"

Three rules ended up doing most of the work in the after column.

1. One unseen medium per family per week

Title hidden.

Timer running.

Not as a substitute for the rest of practice.

As the diagnostic that anchored what to practise next.

2. Foundational material on the family's invariant before more volume

When a family failed the diagnostic, the next thing to read wasn't a new problem.

It was the page on what made the family applicable.

Volume came after.

That distinction between solving a problem and recognising a family from constraints is exactly what eventually shaped how I built Codeintuition.

3. Don't retest with the same problem

A retest on a problem already seen, even one that was failed, measured recall instead of reasoning.

The whole point of the diagnostic was novel problem performance.

What the failure modes told me

Most engineers running a version of this diagnostic don't pass three for three on the first attempt.

The first attempt for me wasn't clean either.

The diagnoses to read off the result:

One family failed

The pattern was understood at a surface level but the identification triggers and the construction skeleton hadn't been internalised.

Fix:

revisit foundational material
retest with a different unseen problem

Two families failed

Usually:

One strong area with over practised volume, shallow gaps everywhere else.

Common for engineers who spent months on one topic because the work felt productive.

Fix:

broaden coverage
spend focused time on the families where the depth is thin

All three failed

Method gap, not talent gap.

Too much:

solving familiar problems
repetition
memorisation

Not enough:

recognition
transfer
unseen problems
interview shaped conditions

The fix is narrower than:

"Work harder."

What I wish someone had handed me earlier

The difference between the score and the diagnostic was the difference between an opaque feeling and an action plan.

"Maybe 70 percent ready" was anxiety.

"Two passed, the DP subsequence family failed because the invariant for non contiguous selections wasn't internalised yet" was what to do on Wednesday.

If family coverage is the bottleneck rather than conditions, the algorithms learning path on Codeintuition is one place to fill the gap before retesting.

The diagnostic itself doesn't depend on it.

The point is the test, not the source of the problems.

I originally wrote a longer version on my own blog that includes the per family signal breakdowns and diagnosis trees for the most common failure modes.

What was the moment that made the readiness question itself feel like the wrong question, and what did you start measuring instead?

How to Recognize Which Algorithm a Coding Interview Problem Needs

Thu, 07 May 2026 12:47:24 +0000

I'd solved around 300 problems by the time my third senior screen wrapped up. The medium that had just bombed the call was something I could explain back to myself in 90 seconds once it ended. The constraints were familiar. The technique was one anyone with my problem count had implemented before. The thing that wouldn't fire, in the moment, was the connection between the constraints and the technique.

The instinct, when that happens, is to grind more problems. That instinct cost me about two months. The thing that actually moved the needle was something else.

What I figured out

Volume practice was building memory of specific problems. It wasn't building the skill that recognises which technique applies to a problem you haven't seen before.
The default LeetCode loop trains around recognition, not at it. Reading the tag before attempting skips the part of the work that interviews actually test.
The fix is small and unglamorous. Read the problem for two or three observable features before any code. Name the technique. Then code.
Conditions matter as much as content. The LeetCode UI is friendlier than any phone screen, and it takes conscious effort to practise under conditions that resemble the real thing.

Quick disclosure before I get into this: I built Codeintuition, a structured learning platform for coding interviews. The story above is the version of this realisation that keeps showing up across engineers prepping for senior screens, almost verbatim. The closing link goes to the longer version on my own blog.

Where the approach was breaking

For most of the prep arc, every stuck problem got handled the same way. Attempt for fifteen or twenty minutes, hit a wall, glance at the tag, read a solution, move on. The progression chart said the weekly count was climbing. The interview chart said the bar wasn't moving.

Tracing what was actually being learned per problem made the picture clearer. The implementation got learned each time. The shape of the solution got learned. What didn't get learned was the answer to a question nobody was asking: why is this problem the kind of problem that takes this technique? The tag and the solution skipped that step every single time.

In a real interview, the tag is gone. So the thing that came for free in practice (which technique to use) becomes the thing the candidate has to figure out from scratch under a clock. The freeze makes sense in retrospect. Nothing in the practice loop had trained for it.

What started working

The shift was small. Before opening the editor, the rule was: spend 30 to 60 seconds reading just the problem statement, trying to name the technique and the reasons. No code, no guessing. The output of the pass is a sentence: "this is a [technique] problem because [feature one], [feature two], [feature three]." If you can't write that sentence, you don't start coding. Go back to the constraints with a checklist of features for each technique and try again.

Concretely:

What used to happen	What started happening
Open problem, attempt for 20 minutes, glance at tag if stuck	Read constraints first, name the technique in 60 seconds, only then attempt
Read solutions to learn the implementation	Read solutions only after attempting, and look for which features in the statement point at the technique
Practise one technique in batches (15 sliding window problems back-to-back)	Mix techniques in each session so the constraints had to be read before knowing what to use
Practise with the title and difficulty visible	Cover the title with a sticky note, ignore the difficulty tag

The first time, this protocol feels slow. The second week, it feels slow but useful. By the fourth week, the features start firing on their own as the problem statement is read.

What that looked like on the next problem

The problem that finally landed for me was Longest Increasing Subsequence. The O(n^2) version was familiar. The patience-sorting O(n log n) version was familiar too. What wasn't trustworthy was the read of when LIS was the right tool versus when something else was.

The session with the new approach started with the constraints. Three features fell out:

A single sequence, not two. That ruled out edit-distance-family techniques right away.
The optimisation target was the length of an ordered subsequence. Order of the original sequence had to be preserved.
The transition between elements was a comparison, not a sum or a count. "Strictly greater than the previous kept element" is a binary check.

Once those three features were written down, the technique was obvious. The simpler O(n^2) version was enough because the problem didn't require the faster one:

def lis(nums):
    if not nums:
        return 0
    dp = [1] * len(nums)
    for i in range(len(nums)):
        for j in range(i):
            if nums[j] < nums[i]:
                dp[i] = max(dp[i], dp[j] + 1)
    return max(dp)

The implementation wasn't new. The change was that the technique got reached for because the features matched, not because the exact problem had been memorised.

A second problem the same week

The same week brought Russian Doll Envelopes, which usually trips people up because it doesn't look like an LIS problem on the surface. The problem asks for the maximum number of nested envelopes given pairs of width and height.

Reading for features: a single sequence (after sorting), a length to maximise, a strict comparison between consecutive kept elements (one envelope must fit inside the next). That's LIS, run on the heights after sorting by width with a tiebreak rule. The reframe took two minutes once the read was for features instead of surface details.

That was the moment the recognition drill paid for itself. Two surface-different problems, same three features, same technique. Far transfer.

Why this works (the science to dig into later)

The learning sciences have language for this. Transfer of learning splits into near transfer (a problem that resembles one already practised) and far transfer (a problem that doesn't resemble anything practised, but whose structure can be read).

Volume practice mostly trains near transfer. Whether far transfer is reliably teachable is a debate the research hasn't fully settled. What the evidence does support is the specific intervention this protocol is built around. Explicit instruction in when and why a method applies, not just how to execute it, produces more transfer than practice alone.

In retrospect, the "how" was everywhere on the internet. The "when" and "why" were the parts no resource in the practice loop bothered to teach explicitly.

What to try if you're in the same spot

If problem 200 feels harder than problem 50, the bottleneck probably isn't volume. It's a recognition skill that volume alone doesn't build for everyone. A few things worth trying:

For each technique you've practised, write down two or three observable features that signal it applies. Sliding window: contiguous range, condition across the window, optimisation on length. Two pointers: sorted array, search for a pair or triple, pointers move from the ends. Monotonic stack: per element answer, directional search, comparison. Keep the checklists short.
On every new problem, run the 60 second feature pass before any code. Write a sentence: "this is a [technique] problem because [features]." If you can't write the sentence, don't code yet.
Mix techniques across sessions. Three problems from three different techniques will train recognition in a way that fifteen problems from one technique won't.
Cover the title and the difficulty before reading the constraints. Many problem names give away the technique, and the assistance is exactly the kind of help that disappears in an interview.

This is a practice protocol, not a product. It runs against any problem bank.

Where it's still hard

The recognition drill doesn't fix everything. There's a separate axis prep tends to skip, which is the conditions the practice runs under. The default LeetCode loop has the tag, the difficulty, the discussion thread, and no clock. None of those are present in a real interview. Even with recognition trained, the first time the tag disappears the read gets harder. So the last few weeks of any prep cycle, run every practice session under interview-shaped conditions: clock running, tag covered, discussion section closed.

That's the version of the lesson worth keeping. It wasn't the problem count. It was what was happening on each problem, and what nobody had ever trained on purpose.

I originally posted this on my own blog, with the feature checklists for six more techniques and a longer worked example for variable sliding window.

What's a problem that finally made a technique click for you, where the explanations you'd read before hadn't quite landed?

How to Explain Algorithm Correctness in Coding Interviews

Wed, 06 May 2026 19:47:14 +0000

I'd written the BFS in about eight minutes. The interviewer ran the example I'd traced and said "ok, but how do you know this is right for any input?" My instinct was to point at the code. Pointing wasn't an argument. The silence stretched, and the realisation landed: nobody had ever taught me how to answer that question.

The interview ended without an offer. The post-mortem felt strange because the algorithm was correct, and there was still no way to say why in a form the interviewer could check.

What changed for me

Tracing one input is testing, not proving. Most engineers, including a past version of me, don't notice the difference.
Interviewers want a loop invariant, the property that's true at the start of every iteration.
The full method is two checks: state and verify the invariant, then check initialization, termination, and edge cases.
Different patterns produce differently shaped invariants, but the two step structure stays constant.
The skill is separate from problem solving. It needs its own practice before it becomes reflexive.

Quick disclosure before I get into this: I built Codeintuition, a structured learning platform for coding interviews. This post is the retrospective version of the lesson that BFS interview should have taught me years earlier.

Where my approach was breaking

The default habit looks reasonable from the outside. You write the algorithm. You walk through it on the example the interviewer suggested. You get the right answer. You stop. If they ask a follow up, you trace a slightly harder example. If they push harder, you start guessing about edge cases.

None of that is an argument. It's a sequence of tests. Each test confirms one input. The interviewer's question was about every input.

The gap is small in description and large in practice. A trace shows the algorithm worked once. A correctness argument has to give the interviewer a reason it works always. That bridge is where the interview lives, and most prep material skips it.

The discrete math course you took in college covered induction proofs with formal notation. It's easy to dismiss as academic and move on. What that misses is that the idea (a property that holds every iteration) is exactly what the interview wants. The interview just asks for it as 90 seconds of clear English instead of a paper proof.

What I started doing differently

The first habit was simple. Before tracing any input, write down what's supposed to be true at the start of each iteration. One sentence.

The hard part is that for a few weeks, the sentence wouldn't always come. That alone is the diagnostic. If you can't state the invariant, you solved the problem by pattern matching, not by understanding what made the algorithm work.

The second habit, after stating the invariant, is to check the boundaries separately. What happens before the loop runs. What happens when the loop exits. What happens on an empty input. What happens on a single element. What happens on the maximum size.

The two step method is short. The change in interview outcomes is not.

Step	What I used to do	What works
Before tracing	Pick an example and run it	State the invariant in one sentence, then trace 3 to 4 iterations
At the loop end	Say "and that gives the right answer"	Confirm the invariant plus the loop's exit condition together force the right output
On boundaries	Mention "edge cases" if asked	List initialization, termination, and at least three degenerate inputs explicitly

What that looked like on the next problem

A few months later, the same kind of BFS question came up on a different graph problem. This time the invariant came first.

from collections import deque

def shortest_path(graph, start):
    distances = {start: 0}
    queue = deque([start])
    while queue:
        node = queue.popleft()
        for neighbor in graph[node]:
            if neighbor not in distances:
                distances[neighbor] = distances[node] + 1
                queue.append(neighbor)
    return distances

The argument went something like this: the invariant is that when a node is dequeued, its recorded distance equals the shortest path from the start. The reason it holds is FIFO ordering on a graph with equal edge weights. Any node enqueued later has been reached by a path of the same length or longer, so the first time you see a node is via the shortest path to it.

Then the boundaries. Initialization: only the start node sits in distances with value 0, which is the shortest path from the start to itself. Termination: the loop exits when the queue is empty, meaning every reachable node has been dequeued with its correct distance. Edge cases: a graph with one node returns {start: 0} immediately. A disconnected graph returns distances only for nodes reachable from the start. A self-loop is fine because the check if neighbor not in distances runs before enqueueing.

The interviewer didn't follow up with "but how do you know it's right for any input?" The argument had already covered that.

Why this works (the bit worth digging into later)

The two step method generalises because the structure is the same across every algorithm class. Only the shape of the invariant changes. Sliding window tracks a running variable. Two pointers tracks a search range. Binary search tracks a range too, but a different one. BFS tracks a relationship between dequeue order and shortest path. DP tracks an entire table of subproblem solutions.

The verification framework is invariant plus boundaries, in that order, regardless of pattern.

This connects to a broader idea in computer science formalism: the loop invariant is a logical statement that, combined with the loop's exit condition, gives you the postcondition you wanted to prove. The interview version drops the formal symbols and keeps the structure. Same skeleton, different vocabulary.

What I'd tell someone in the same spot

Three concrete things matter most:

Pick a problem you've solved. Set a timer for 60 seconds. Try to state the loop invariant in one sentence. If the sentence doesn't come, that's the most important diagnostic in your prep, and more problems won't fix it.
Take a correct algorithm. Write down an invariant that sounds plausible but is subtly wrong. Find the iteration where it breaks. This trains the gap between invariants that describe what the code does and invariants that guarantee correctness.
Pair correctness reasoning with mental dry running. The dry run gives you a trace. The invariant gives you the claim to verify against the trace. Practising them apart leaves a hole that interview pressure exposes.

If you want a worked walkthrough of the BFS distance invariant before solving a graph problem with it, the BFS lesson walks through why FIFO ordering plus equal edge weights forces the shortest path property to hold.

I originally posted this on my own blog, a slightly longer version that walks through the two step method on sliding window, binary search, and DP, with an FAQ on nested loops where each loop needs its own invariant.

What's a problem where you understood the algorithm but couldn't say why it was right when someone asked, and what was the missing sentence you wished you'd had?

I used to fail .NET interviews for not giving the “expected answer”, now I understand them better

Wed, 06 May 2026 15:58:47 +0000

I’m a .NET developer. I can build production-ready applications, APIs, and work with databases.

In the past, I kept failing interviews and getting rejected or ignored, mostly because I wasn’t giving the “expected answer”.

I could solve the problems in real code, but I struggled to explain things in the structured way interviewers wanted. I thought performance should matter more than theory, but interviews don’t really work like that. You have to answer first, then prove yourself later.

I even got hired once just because I memorized definitions and answered correctly, even though I wasn’t actually strong in what they asked. I ended up learning everything on the job and eventually resigned after a short time.

Now, after going through many interviews, I understand the process much better. I know what they are looking for, how questions are framed, and what kind of answers they expect.

Still, it’s interesting how different real-world development is from interview performance.

AlgoExpert vs NeetCode: Why I Still Froze in Coding Interviews

Tue, 05 May 2026 22:40:47 +0000

A few years back I had AlgoExpert open in one tab and a NeetCode playlist queued in another, and the prep felt like it was working. Twelve weeks of disciplined viewing, two videos most evenings, the trees module rewatched twice because the postorder helpers weren't sticking on the first pass. Then a real interview opened with a fresh medium nobody had walked through, and the eight minutes spent looking at the prompt before writing anything were the slowest eight minutes of the round.

The problem looked like a graph. The candidate technique wasn't there. The videos on graphs all started after the technique had been named, and naming the technique on a fresh prompt was apparently a different skill.

What I figured out, in retrospect

The 100 polished AlgoExpert videos and the 400+ free NeetCode walkthroughs were honest about what they were teaching: how a technique works once the technique has been named.
Naming the technique on a fresh prompt was a separate skill the videos didn't claim to train.
The reps that were missing weren't more videos. The video count was already enough.
A wrong attempt written from a blank screen surfaced more about the gap than another walkthrough did.
Once the practice shape changed, both platforms became more useful, not less.

Quick disclosure before I get into this. I built Codeintuition, a structured learning platform for coding interviews. The retrospective below is from before that, when working through both AlgoExpert and NeetCode the way the platforms recommend.

Where the approach was breaking

The Number of Islands prompt was the one that finally made the gap concrete. The interviewer described a 2D grid of 1s and 0s and asked for the count of distinct islands, where an island is a region of connected 1s. The walkthroughs of this exact problem had been watched twice. The BFS variant could be written from memory if the title was handed over.

What couldn't happen, in 25 minutes against a whiteboard, was reading the prompt and arriving at "this is a connected components count, BFS or DFS from each unvisited 1, mark visited as you go." The video had given that as the starting position. The prompt expected it to be constructed. Twelve weeks of polished video walkthroughs hadn't drilled the construction work.

The pattern wasn't specific to graphs. It repeated on the next round, where the prompt was a string problem with a sliding window solution, and the candidate technique took six minutes to occur. After the round the code re-derived itself in five. The implementation was the easy part. The decision was where the time went.

What changed on the second attempt

The shift wasn't dramatic. Two changes, both unglamorous:

What had been happening	What started happening
Watching the walkthrough first, then attempting the problem with the technique already in mind.	Reading the prompt first with the title and tags hidden, naming the visible triggers that could be extracted, then either trying the technique from those triggers or giving up after 10 minutes and watching the walkthrough.
Picking the next problem from the platform's curriculum order, by topic.	Picking five problems on the same technique, drilling them with titles hidden, before moving to a different technique.
Treating the timer as a final-week thing.	Adding a 25 minute timer to the recognition work, not the implementation work, from week one of the new approach.

The change wasn't from "video led" to "problem led." Both platforms remained part of the loop. What changed was the order of operations: prompt first without the technique label, then the technique, then the implementation, then the walkthrough as a check rather than the starting position.

What that looked like on the next problem

Take Number of Islands again, after the change. Title hidden, no tags. The prompt described a grid, a definition of an island, a count. Reading it cold:

The input is a 2D grid, not a flat array. That suggests grid traversal.
The output is a count of distinct regions. That suggests connected-components reasoning.
The connection rule (4-directional adjacency on 1s) suggests BFS or DFS from each unvisited 1, marking visited as the traversal proceeds.

That's the recognition that wouldn't form on the first interview round. After ten or twelve recognition reps with titles hidden, on different graph problems, the construction came together in under three minutes on a fresh prompt.

The implementation that followed was short, and not the hard part:

def numIslands(grid):
    if not grid:
        return 0
    rows, cols = len(grid), len(grid[0])
    count = 0

    def dfs(r, c):
        if r < 0 or r >= rows or c < 0 or c >= cols:
            return
        if grid[r][c] != "1":
            return
        grid[r][c] = "0"
        dfs(r + 1, c)
        dfs(r - 1, c)
        dfs(r, c + 1)
        dfs(r, c - 1)

    for r in range(rows):
        for c in range(cols):
            if grid[r][c] == "1":
                count += 1
                dfs(r, c)
    return count

The code is six or seven lines of meaningful work. The recognition that the 2D-grid-plus-connected-region prompt is a DFS-from-each-unvisited-cell problem is the part that would have taken eight minutes on a whiteboard before. The change brought it to under three.

A second example: where the wrong attempt taught more

Later in the same week, a course scheduling problem came up. Given a list of courses with prerequisites, return whether all courses can be completed. The walkthrough had been watched. The walkthrough used Kahn's algorithm with topological sort. Reading the cold prompt, "topological sort" wasn't a candidate that surfaced. The graph was visible, the directed edges were visible, but the move from "directed graph with prerequisites" to "topological sort to detect a cycle" wasn't there.

So a wrong attempt got written. A naive DFS that didn't track visit states properly, that would have looped on a real cycle. Wrong, but written. Then the walkthrough got checked.

The wrong attempt did something the walkthrough alone hadn't done. It surfaced the specific missing piece. A directed cycle needs a three-state visit tracking (unvisited / in progress / done) or an indegree-zero queue, and that hadn't internalised. Knowing the missing piece, the walkthrough's three-state DFS clicked. The next two course-prerequisite problems resolved in eight or nine minutes each. Without writing the wrong attempt first, the walkthrough would have produced a nod of recognition, then the same stall on the next variant.

This is the generation effect doing the work nobody told me about during the watch-everything phase. Producing an answer first, even an obviously wrong one, surfaces the missing concept more reliably than reading the answer.

Why this works (the science I dug into later)

The retrospective is what surfaced the underlying reasons. Two effects from the cognitive science literature explained what was happening, both summarised in the transfer of learning Wikipedia article.

The first is the generation effect itself: producing an answer before checking the reference produces stronger encoding than reading the reference first. Watching twelve weeks of walkthroughs is the second pattern, not the first. That's why the prep felt productive (it was) and didn't transfer to fresh prompts (the encoding was recognition-shaped, not generation-shaped).

The second is a near transfer / far transfer split. Watching ten variants of expand around centre transfers reliably to variants close to what was watched. It transfers unreliably to a fresh prompt where the description is just different enough that the recognition memory misses. The prep platforms reward the watching shape. Interviews test the generating shape. One shape doesn't substitute for the other.

What I'd tell someone in the same spot

If you're working through AlgoExpert or NeetCode (or both) and the unfamiliar mediums are still freezing you, here's what would have helped earlier:

Cover the title before reading any prompt. The title is the cheat sheet the platform hands you. Hide it and the recognition becomes the work, which is what an interview tests.
Write a wrong attempt before reaching for the walkthrough. The wrong attempt surfaces the specific missing piece. Reading the walkthrough cold doesn't.
Pick five problems on the same technique before moving to the next technique. The reps on a single technique are what extract the trigger features. Topic-spread reps don't do this.
Add a 25 minute timer to the recognition work from the first day. Recognition under timed conditions is the actual interview test. Practising it without the timer doesn't transfer.
When you do watch a walkthrough, watch it as a check on the wrong attempt, not as a starting position. The walkthrough is more useful at this point in the loop than at the beginning.

The 100 polished videos and the 400+ free walkthroughs were never the bottleneck. The bottleneck was the practice shape that surrounded them, and the practice shape was something both platforms assume the engineer will construct on their own.

I wrote a longer version on my own blog that walks through how the two platforms compare on depth, breadth, and free access, plus the trigger lists rebuilt for the patterns that broke me first.

What's the platform you watched the most videos on, and what was the prompt where the recognition finally locked in for you?

Simple ATS Resume Builder for Developers

Sun, 03 May 2026 23:39:21 +0000

Most resumes never reach a human. They get scanned, scored, and tossed aside by software before anyone reads a single word.

I found this out the hard way. Dozens of job applications, zero replies. Not because I wasn't qualified. My resume just wasn't built for how hiring actually works.

So instead of guessing, I built something to fix it.

Companies use Applicant Tracking Systems like Lever, Greenhouse, and Workday to filter candidates. Think of them as gatekeepers. If your resume doesn't parse correctly, you're out before a recruiter ever sees your name.

Here's what happens. You upload your resume. The ATS tries to read it and dump the information into a database. But if you're using columns, icons, graphics, or complex layouts, the system gets confused. It might scramble your work history, drop your contact info, or just give up entirely.

Missing keywords? Lower score. Fancy design? It might not read anything at all.

I've seen strong candidates get filtered out because of formatting alone. Not skills. Not experience. Just formatting.

So I made a simple ATS-friendly resume builder. Nothing fancy. Just clean structure that parsing software can actually read. No broken layouts. Just your information in a format that works.

You can try it right now and you don't need to sign up for anything. No email. No account. Just open it and use it.

Try the live builder here:
https://ats-friendly-resume-builder-sable.vercel.app/

It's built for developers but honestly works for anyone. The layout is simple on purpose. You can fill it out in under five minutes. No ads popping up. No distractions trying to sell you something. Just a tool that does one thing and does it well.

I built this because I was stuck in that no-reply loop myself and couldn't find a free option without jumping through hoops.

If you'd rather work offline or want a version you can fully customize and keep on your own computer, I made a downloadable version too. Same clean structure, but you own it. Tweak it however you like.

Get the downloadable version here:
https://yaman95.gumroad.com/l/ats-friendly-resume-builder

I'm working on a bigger version with smarter features. Keyword suggestions based on the actual job description. Role-specific optimization for frontend, backend, data, and DevOps roles. Better export options so you can save as PDF, Word, or plain text.

If you have ideas or run into problems with the current tool, reply to this post. I'm building this because I needed it myself, and I want to make it actually helpful for other people.

If you're job hunting, try the live builder. See if it changes how many responses you get. It's free and takes a few minutes.

And if it helps you land an interview, pass it along to another developer who's still waiting for that first reply. Sometimes the only thing standing between you and an interview is a resume an ATS can actually read.

The Senior Angular Take‑Home That Made Me Rethink Tech Interviews

Thu, 02 Apr 2026 08:00:00 +0000

I spent an entire weekend building a “small” take‑home assignment.
Friday to Monday. Stock data app. Real‑time updates. Angular, WebSockets, Supabase mock.

On Monday, I submitted the repo.
On Tuesday, I got the rejection.

No call. No detailed feedback. Just “we’ve decided not to move forward.”

That was the moment I realized something: most companies have no idea what they’re actually testing when they give senior devs take‑home assignments.

The Assignment That Ate My Weekend

The brief, simplified, looked like this:

Build a small Angular app that displays stock data for up to 4 companies
Load initial data via HTTP from a public API
Implement real‑time price updates using:
— a custom WebSocket server (backend)
— and a mocked implementation in Angular
Allow toggling updates per stock card (enable/disable)
Reflect price changes visually (increase / decrease / disabled states)
Create a responsive UI (desktop + mobile)

On paper, it was reasonable.
It touched all the right buzzwords: HTTP, WebSockets, real‑time updates, responsiveness, toggles per card.

If you’ve only shipped todo apps, this is a sexy challenge.
If you’ve spent years in production Angular codebases, it’s just a very compressed slice of real work.

I got the task on Friday. I submitted on Monday.
In between, I did what seniors are supposed to do: I treated it like a real mini‑project, not a quick coding kata.

My Goal: Not Just “Make It Work”, But “Show How I Work”

I wasn’t trying to just tick boxes with the bare minimum implementation.

My goals were:

show architecture decisions ,
show how I handle messy APIs ,
show how I think about real‑time behavior ,
keep overall code quality at a level I’d be happy to merge into a real repo.

So I:

structured the app so HTTP and WebSocket logic weren’t glued to the UI,
made sure each card’s real‑time subscription could be toggled cleanly,
handled visual state for price up / down / disabled,
paid attention to responsiveness for both desktop and mobile.

And then the data source decided to be… the internet.

The API Was Flaky, So I Did What Production Me Would Do

The assignment used public, free stock data.
That sounds fine, until you remember what “public, free” usually means:

rate limits,
inconsistent responses,
occasional downtime,
weird edge cases on weekends and off‑hours.

The WebSocket data wasn’t consistent either.
Sometimes it would lag, sometimes it would drop, sometimes it would just stop updating.

For a weekend project, you have two choices:

Pretend it’s fine, hack around the issues, and hope the reviewer doesn’t notice.
Treat it like a real integration: build a mock , stabilize your domain logic, and make your app deterministic for review.

I chose option 2.

I built a mock WebSocket implementation in Angular so I could:

simulate consistent price updates,
test toggling updates on/off per stock card,
guarantee the app behaves correctly even if the real API is having a bad day.

From my perspective as a senior dev, that was the right call:

decouple the app from a flaky external system,
make real‑time behavior testable,
keep the “real API” path around, but not rely on it for correctness.

In other words: I tried to behave like someone who’s shipped production apps, not like someone doing a school exercise.

What the Company Probably Saw Instead

Here’s my guess about what happened on their side.

They cloned the repo.
They followed the steps.
They ran the app with the “real” public data.

And depending on the timing and the API mood, they may have seen:

delayed or missing updates,
weird lulls in price changes,
behavior that didn’t look “smoothly real‑time”.

If they didn’t read the README carefully, or didn’t flip into the mock mode, my architectural decision probably looked like… a bug.

No context. No understanding that I built the mock because the public stream is unreliable.
Just: “The WebSocket behavior is not solid. Next candidate.”

That mismatch is what made me rethink the entire premise of senior take‑home assignments.

What This Assignment Actually Tested (and What It Didn’t)

On the surface, it looked like it tested:

Angular skills,
HTTP and WebSocket handling,
real‑time UI,
responsiveness.

In practice, it tested something else:

who is willing to burn a weekend to impress a company,
who optimizes for the demo , not for production reality,
who can guess what the reviewer cares about , without any conversation.

Because here’s the thing: as a senior, you are constantly balancing trade‑offs.

If this were a real client project, I would have:

clarified API reliability up front,
negotiated scope (“do you want a pretty demo or a robust integration?”),
documented the limitations,
decided with the team how much time to spend on mocks vs building around the real feed.

In a take‑home, you get none of that.
You just guess, implement, and hope your guess lines up with whatever the reviewer imagines “good” looks like.

If you optimize for elegance and robustness, they might say you “over‑engineered a small task”.
If you optimize for a quick, hard‑coded demo, they might say you “lacked senior‑level architecture thinking”.

You’re taking a test with no answer key.

That’s not a tech interview. That’s a silent compatibility test with someone’s private taste.

The Senior Work That Never Shows Up in Take‑Homes

The more I thought about it, the more I realized how much real senior work this assignment couldn’t see:

Clarifying incomplete or unrealistic requirements.
Pushing back on scope when someone tries to cram a sprint into a weekend.
Deciding when to build a mock, when to live with flakiness, and when to say “this API is not acceptable for production”.
Communicating trade‑offs to non‑technical stakeholders.
Designing an architecture that won’t explode in six months.

Instead, the process mostly evaluated:

how quickly I could implement a small greenfield UI,
how much free time I had between Friday and Monday,
how well my decisions matched a reviewer I’ve never spoken to.

That’s not a tech interview.
That’s a silent compatibility test with someone’s private taste.

Why I Think Most Senior Take‑Homes Are Misaligned

This experience clarified a few things for me.

1. They confuse “time sacrifice” with “commitment ”

If you’re willing to burn your weekend to build a polished app, it’s read as “motivated”.
If you timebox yourself and refuse to over‑invest, it’s read as “not hungry enough”.

In reality, the person who protects their time and still delivers a solid, well‑scoped solution is probably a better long‑term hire.

2. They test mid‑level implementation, not senior judgment

Building a small stock app from scratch shows you can:

wire up components,
call APIs,
handle events,
add some responsiveness.

That’s mid‑level baseline.
It doesn’t tell you how someone:

handles legacy code,
refactors a 500‑line component,
improves CI,
unblocks a team stuck on a bad architecture decision.

If you want to know whether I can rescue your Angular app, don’t ask me to build a toy in a weekend.

If you want to know whether I can rescue your Angular app, don’t ask me to build a toy in a weekend.
Show me your worst component and ask how I’d detox it.

3. They ignore how seniors actually work in 2026

In real life, I use Claude Code and Antigravity heavily.

Not to cheat, but to:

scaffold modules,
explore alternative designs,
generate boring boilerplate,
fuzz‑test APIs and policies.

If your assignment bans AI and expects me to pretend it’s 2014, you’re not testing my real workflow. You’re testing my ability to role‑play a slower version of myself.

The future senior is the one who brings the architecture and judgment , uses AI to implement faster, and still understands what’s happening under the hood.

What a Better Senior Angular Take‑Home Could Look Like

Instead of “build a stock app from scratch over the weekend”, here’s what I’d consider a good senior‑level assignment:

1. Smaller, paid, time‑boxed task

2–3 hours max.
Paid at a reasonable rate.
Clear that they care more about how you think than how many screens you can ship.

2. Refactor an existing messy component

Give a real‑world Angular component that:

is 400+ lines,
mixes data fetching, state, and UI,
has a couple of hidden bugs.

Ask the candidate to:

refactor it,
explain their decisions,
write a couple of tests,
list what they’d tackle next.

That’s a senior skill.

3. Architecture review, not pixel‑perfect clone

Provide a small codebase and ask:

“How would you introduce real‑time updates here?”
“How would you make this testable?”
“Where would you put toggles and state?”

Let the candidate use real tools, real patterns, and real AI support — just like they would on the job.

What I’ll Do Differently Next Time

I don’t regret doing this assignment.
It gave me a free, honest look at how I behave when nobody is watching.

Here’s what I’m changing going forward:

I won’t spend full weekends on unpaid assignments.
I’ll timebox, signal my priorities in the README, and let the result speak for itself.
I’ll over‑communicate constraints and trade‑offs.
If an API is flaky and I build mocks, I’ll make that impossible to miss — in the README and in the UI.
I’ll focus on clarity over cleverness.
Clean, readable, obviously structured code beats elegant but over‑abstracted architecture, especially in a small assignment.
I’ll treat take‑homes as two‑way interviews.
If a company expects free, multi‑day work with vague feedback, that’s a data point.
I’m not just being evaluated — I’m evaluating them.

I’m not just being evaluated in take‑homes anymore; I’m evaluating the companies that ask for them.

I’m still going to build things on weekends.
But from now on, I’d rather ship my own AI‑driven SaaS and fix real bottlenecks than over‑optimize for silent reviewers I’ll never meet.

If you’re a senior dev:

What’s the last take‑home you did that actually tested your real job — not just your free time?

I fix the Angular apps that generalists break.

Karol Modelski is a senior Angular developer and frontend architect rescuing legacy B2B SaaS frontends.
If your Angular app is slowing your team down, start here: https://www.karol-modelski.scale-sail.io/

LeetCode AI Assistant: A Smarter Way to Prepare for Coding Interviews

Thu, 09 Oct 2025 18:41:23 +0000

Grinding LeetCode alone is outdated. Discover how a LeetCode AI
assistant can provide smarter hints, personalized notes, and mock
interviews to transform coding interview prep.

When you think about preparing for coding interviews, one name comes up again and again: LeetCode.
It has become the global training ground for aspiring software engineers, from college grads to senior devs making career moves.

But here’s the catch: LeetCode was never designed to be a complete learning experience. It’s a practice arena, not a teacher. You can solve hundreds of problems and still stumble in an interview because you didn’t build the right habits, or because you forgot what you learned two weeks ago.

That’s why a growing number of candidates are turning to a new kind of tool: the LeetCode AI assistant.

This isn’t just another coding bot. It’s an evolution in how people learn and prepare. Let’s break down why it matters, what it can do, and how it’s changing interview prep for good.

Why Traditional LeetCode Prep Falls Short

If you browse Reddit or Blind, you’ll see countless posts that sound like this:

“I solved 500+ problems but still bombed my interviews.”
“I keep forgetting the details after a week.”
“I know the patterns, but I panic when asked to explain.”

The pain points are remarkably consistent:

Retention → Candidates forget solutions without structured review.
Communication → Solving alone doesn’t prepare you to explain in front of an interviewer.
Feedback → Debugging in isolation wastes hours.
Focus → Constantly switching tabs to seek help breaks flow.

LeetCode is powerful, but it leaves gaps. That’s where the LeetCode AI assistant comes in.

What Exactly Is a LeetCode AI Assistant?

At its core, it’s an AI companion that lives inside your LeetCode practice environment.
Think of it like a study partner who:

Already knows which problem you’re working on.
Reads your code as you write it.
Can run, test, and even visualize your solution.
Helps you keep track of what you’ve learned.

It’s not a shortcut to answers—it’s a scaffolding system that makes practice more efficient, memorable, and realistic.

Smarter Hints: Guidance Without Spoilers

One of the worst habits in LeetCode prep is peeking at solutions too early. You go from struggling productively to memorizing passively.

A LeetCode AI assistant solves this with progressive hints:

At the start, it nudges you toward the right approach.
Midway, it identifies bottlenecks in your reasoning.
With partial code, it explains the logic gaps without dumping the full solution.

The result? You stay in control, but with safety rails. You learn how to think, not just how to copy.

Auto-Generated Study Notes: From Grind to Knowledge

Let’s face it: solving 300 problems doesn’t mean you’ll remember 300 problems. Without review, most of it fades.

A LeetCode AI assistant can turn every solved problem into a structured note automatically:

Problem summary and constraints.
Step-by-step breakdown of the solution.
Example inputs and outputs.
Time and space complexity.

Over time, this builds a personal knowledge base—a second brain you can revisit anytime, instead of relying on memory alone.

Some assistants even generate flashcards or quizzes, making spaced repetition effortless.

Mock Interviews: Practicing Performance, Not Just Problems

Interviews are not just about writing code. They test your ability to:

Communicate clearly.
Defend trade-offs.
Adapt to unexpected follow-ups.

This is where a LeetCode AI assistant shines. It can simulate a real interviewer:

Asking clarifying questions like “Why not use a hash map here?”
Pushing you when your explanation is vague.
Giving a score breakdown on clarity, efficiency, and correctness.

The first time you try it, you might even feel nervous. That’s the point—it replicates the pressure so the real thing feels less intimidating.

Beyond Chat: Tools That Act

What makes the best LeetCode AI assistants different is that they don’t just talk—they act.

Instead of wasting time writing test harnesses, you can simply ask:

“What if the array contains only negatives?”
“Can you show me how this recursion actually unfolds?”

And the assistant responds by:

Generating edge test cases and running them instantly.
Visualizing your function calls step by step.
Saving key insights into your personal notes for later review.
Search for relevant walkthrough Youtube videos so user can play them in a picture-in-picture window.

It feels less like Q&A, and more like pair programming with a senior engineer who brings their own debugger, whiteboard, and notebook to the session.

A Story: Grinding Alone vs. Training With a Copilot

Consider two candidates: Priya and Daniel.

Priya follows the traditional path. She solves 400+ problems, memorizes patterns, and spends weekends reviewing notes in Notion. But when faced with an interviewer asking her to explain trade-offs under time pressure, she stumbles.
Daniel solves fewer problems, but with a LeetCode AI assistant. Each solution is turned into notes. He practices weekly mock interviews with adaptive feedback. He reviews AI-generated flashcards to keep concepts fresh.

Who’s better prepared for the real interview? Daniel, not because he worked harder—but because he worked smarter.

What a LeetCode AI Assistant Can’t Do

It’s important to be clear:

It won’t replace fundamentals—you still need to understand data structures and algorithms.
It can’t guarantee an offer—interviews involve culture fit and communication beyond coding.
It shouldn’t become a crutch—over-relying on AI means you risk freezing when the assistant isn’t there.

Used well, it’s an amplifier, not a replacement.

Risks and Concerns

Every new tool has trade-offs. With AI assistants, the concerns include:

Cheating → Candidates might try to use them during real interviews, undermining fairness.
Overconfidence → Practicing with AI feedback is valuable, but real interviewers bring unpredictability.
Accessibility → Not all candidates have equal access, which could widen the prep gap.

These are real issues. The key is to use AI as a training partner, not as a hidden lifeline.

How Companies Might Respond

Here’s where it gets interesting: companies know candidates are using AI to prepare. Over time, this could reshape interview culture itself.

Expect more emphasis on communication and collaboration.
Expect system design and open-ended problem-solving to weigh more heavily.
Expect soft skills—like how you handle feedback or adapt to surprises—to become part of evaluation.

Ironically, this is healthy. It pushes interviews away from rote memorization and closer to what actually matters on the job.

Practical Tips: How to Use a LeetCode AI Assistant

If you’re curious how to get started, here’s a simple framework:

Daily Practice → Solve 2–3 problems. Use AI hints only when stuck beyond 15 minutes.
Structured Notes → Let the AI generate study notes. Add your own reflections to deepen understanding.
Weekly Mock Interview → Simulate a session, focusing on explaining your reasoning out loud.
Edge Case Training → Ask the AI to generate tricky test cases for past problems.
Review Cycle → Revisit AI-generated notes weekly, like flashcards, to strengthen retention.

This rhythm balances human effort with AI support.

The Bigger Picture: Learning How to Learn

At the end of the day, the real revolution of a LeetCode AI assistant isn’t in the code—it’s in how it reshapes learning.

Instead of brute force, you get:

Efficiency → Less wasted time, more targeted progress.
Retention → Notes and reviews that actually stick.
Confidence → Mock interviews that simulate real pressure.

Preparing for coding interviews used to feel like grinding through a fog. With the right assistant, the fog lifts. You see patterns faster, you remember more, and you walk into interviews with less anxiety.

Final Thoughts

The rise of the LeetCode AI assistant marks a turning point in technical interview prep. It’s no longer just about solving the most problems—it’s about learning smarter, retaining more, and performing better under pressure.

This doesn’t mean grinding is dead. You’ll still need to practice, struggle, and grow. But with an AI assistant, every hour of practice counts more.

If I were starting over today, I wouldn’t just grind problems in isolation. I’d bring along an assistant that helps me learn, remember, and perform. Because in coding interviews, the real advantage isn’t just algorithms—it’s confidence.

Ready to see it in action? Try LeetCopilot for free on Chrome and experience what it’s like to have your own LeetCode AI assistant by your side.

Understanding loop detection is like understanding how to find your way out of a maze.

Wed, 01 Oct 2025 02:36:15 +0000

Finding Loops in a Linked List: Why It Matters

If you’ve ever dealt with linked lists in data structures, you’ve probably come across the famous problem: “How do you find if a linked list has a loop?”

At first glance, it may feel like one of those abstract interview questions that don’t really pop up in real life. But let’s step back. A loop in a linked list means that instead of ending properly, the list points back to a previous node and keeps cycling endlessly.

In simple terms: imagine you’re driving on a road expecting to reach a destination, but instead, you unknowingly get stuck in a circular highway that never ends. That’s what happens in memory if a linked list has a loop — your program keeps going in circles, consuming resources, and never exits.

Why Should You Care?

Interview perspective: Detecting loops is one of the top classic questions asked in technical interviews. It tests not just your coding ability, but your logical reasoning. Can you spot a cycle in a system that looks endless? Can you do it efficiently?
Real-world systems:
- In network routing, cycles can cause packets of data to loop infinitely instead of reaching their destination.
- In memory management, improper handling of linked data structures can cause memory leaks or programs that never terminate.
- Even in recommendation engines, if graph-based connections form a cycle, users might end up stuck seeing repeated suggestions.

So, being able to detect and fix a loop isn’t just about passing interviews — it’s about writing reliable, efficient systems.

How Do We Detect a Loop?

I won’t dive into full code here, but think of it like this:

Use two pointers that move at different speeds through the list.
If they ever meet inside the loop, you know a cycle exists.
To fix it, you identify where the loop starts and then carefully break it, ensuring the list ends where it should.

This method is both clever and efficient, no extra space, no brute force.

Final Thoughts

Understanding loop detection is like understanding how to find your way out of a maze. It may look theoretical, but its importance spans from clearing interviews to building stable software.

For a step-by-step explanation with pseudo-code and examples, I’ve written a full article here.

Coding Challenge: Can You Spot the Bug?

Sat, 13 Sep 2025 22:43:22 +0000

At Beyond Code, we’re all about helping new devs get job-ready and ace their interviews.

So here’s a quick one for you: Can you spot the bug?

Drop your answer in the comments. First correct one gets bragging rights

Want more practice challenges and interview prep resources? https://www.beyondcode.app

I built a free tool to practice the hardest part of coding interviews: choosing the right algorithm

Mon, 25 Aug 2025 19:58:10 +0000

Beyond Implementation: I Built a Tool to Master Algorithm Selection for Coding Interviews

Every developer who has prepared for a technical interview knows the routine: grind through problems, practice implementing sorting algorithms from scratch, and try to wrap your head around dynamic programming. But there’s a crucial step that often gets less attention than it deserves: the moment you read a problem and have to decide which algorithm to use in the first place.

This is where the real challenge often lies. It’s not just about knowing how to write a BFS traversal; it’s about recognizing that a problem asking for the "shortest path in an unweighted graph" is a signal to use BFS. This pattern-matching skill is what separates a good candidate from a great one.

To address this specific gap, I built Think2Algo, a web platform designed to train that exact "algorithmic intuition."

The Problem: From "How" to "Which"

While practicing, I found myself getting stuck not on the implementation details but on the initial decision-making. I’d see a problem and think, "Should this be solved with a sliding window, or is it a two-pointers problem? Is this a classic case for backtracking?" The cost of choosing the wrong path is significant, both in an interview and in real-world development.

I realized what I needed was a way to practice this diagnostic step in isolation. I didn't want to just solve another problem; I wanted to build a mental map that connected problem types to algorithmic solutions.

The Solution: Think2Algo

Think2Algo is an interactive learning tool that flips the script. Instead of asking you to code a solution immediately, it presents you with a problem and forces you to first select the most appropriate algorithm. It’s a "flashcard" system for high-level problem-solving.

The core workflow is simple:

Read a typical interview-style problem.
Analyze its constraints and requirements.
Choose the most suitable algorithm from a list.
Get immediate feedback on your choice, along with a detailed
explanation of why a particular algorithm is the best fit.

This process helps reinforce the patterns, keywords, and signals associated with each algorithm, making the selection process faster and more accurate over time.

Key Features

To support this learning model, I built out a few core features:

Interactive Challenges: A collection of problems where the primary goal is to match the problem to the right algorithm, complete
with difficulty levels.
Detailed Algorithm Guides: For each algorithm, there’s a dedicated page explaining what it is, its Big O complexity, and—most
importantly—a "When to Use It" section with common keywords and
problem types.
Code Templates: Once you've made the connection, you can view clean, commented code templates in both Python and JavaScript to see
the implementation.
Bilingual Support: The entire platform is available in both English and Portuguese to reach a wider audience.

For those interested in the technical side, the project was a great opportunity to work with a modern web stack:

Framework: Next.js (using the App Router)
Language: TypeScript
UI: React
Styling: Tailwind CSS with ShadCN for UI components
Internationalization (i18n): React Context API to manage language state.

The focus was on creating a clean, fast, and fully responsive user interface that works seamlessly on both desktop and mobile devices.

Conclusion

Building Think2Algo was a rewarding experience. It helped me solidify my own understanding of algorithms and create a tool that I hope can help other developers bridge the gap between theory and application.

I would appreciate any feedback from the CoderLegion community.

You can try out the live version here: https://think2algo.vercel.app/