Technical interviews are changing because the work of software engineering is changing. For years, companies relied on algorithm puzzles and timed coding challenges to evaluate candidates. These exercises offered a standardized way to compare applicants, but they did not always reveal how effectively someone could perform the actual job.

AI has made that gap harder to ignore. Coding assistants can now solve many familiar programming challenges in seconds, making it less useful to judge engineering ability solely by how quickly someone can produce an algorithm without assistance.

The bigger question is no longer whether a candidate can solve a coding puzzle. It is whether they can understand a problem, make sound technical decisions, work with AI, identify mistakes, and deliver software that works.

LeetCode-style interviews became popular because they offered companies a repeatable way to assess technical knowledge. Candidates received a problem, worked under time pressure, and were evaluated against a relatively consistent set of criteria.

The weakness is that interview preparation can become an exercise in memorizing patterns rather than developing practical engineering judgment.

Someone might spend weeks solving hundreds of algorithm challenges, learn reusable templates, and perform exceptionally well in an interview. Yet the daily responsibilities of the job may involve understanding an unfamiliar codebase, debugging production issues, reviewing pull requests, communicating with product teams, and maintaining existing systems.

Those abilities are not necessarily demonstrated by solving a puzzle on a whiteboard.

AI adds another challenge. When a coding assistant can generate a solution almost immediately, testing whether someone remembers a particular algorithm becomes less representative of modern engineering work. The more valuable skill is knowing whether the generated solution is appropriate, secure, efficient, and maintainable.

This does not mean algorithm knowledge has become irrelevant. Data structures, complexity analysis, and problem-solving fundamentals still matter, particularly in performance-sensitive systems. The issue is whether a timed puzzle should carry more weight than the practical skills required by the role.

Tip: When preparing for a technical interview, learn the underlying concepts rather than memorizing solutions. Be ready to explain why an approach works, where it might fail, and how you would apply it to a real engineering problem.

Traditional coding interviews have not disappeared, especially at large technology companies.

Organizations such as Google, Meta, Amazon, Apple, Uber, and LinkedIn have historically used algorithm-focused interviews for many engineering positions. One reason is scale. When companies evaluate large numbers of applicants across different teams and locations, standardized exercises can make comparisons easier.

A consistent interview format also gives hiring teams a familiar evaluation framework. Candidates can be assessed on problem-solving approaches, correctness, efficiency, and communication under similar conditions.

However, some companies are experimenting with formats that better resemble actual engineering work.

One example is Google's reported code comprehension interview format. Instead of asking candidates to solve an algorithm from scratch, the exercise gives them an unfamiliar codebase, reportedly around 200 to 500 lines, and asks them to inspect it within a limited period. Candidates may need to identify bugs, explain design decisions, and suggest improvements, with AI assistance allowed.

That changes the nature of the assessment. Rather than rewarding someone for remembering a familiar coding pattern, it examines how quickly they can understand an existing system and reason about its behavior.

For candidates targeting large technology companies, the practical lesson is to prepare for both formats. Algorithm exercises may still appear, but the ability to understand and improve existing software is increasingly relevant.

Tip: Do not abandon algorithm practice if your target companies still use it. Add code reading, debugging, system design, and technical communication to your preparation so you are not relying on one interview skill.

Smaller and mid-sized companies, as well as some AI-focused organizations, may place greater emphasis on practical engineering exercises. There is no universal replacement for coding interviews, but several formats offer a stronger view of how candidates approach real work.

A code review exercise gives candidates an existing piece of software and asks them to evaluate it.

The code may contain intentional bugs, inefficient operations, security weaknesses, unclear naming, or design decisions that deserve discussion. The candidate must identify issues, explain their consequences, and recommend improvements.

This format reveals several important abilities:

Code review is especially useful because engineers rarely build everything from scratch. Much of the work involves understanding existing systems and deciding how to improve them without disrupting what already works.

A candidate who can explain why a piece of code is dangerous, what could happen in production, and how to fix it may provide a more meaningful signal than someone who simply completes an isolated puzzle.

Tip: Practice reviewing unfamiliar repositories. Look beyond whether the code runs. Examine error handling, security, performance, testing, readability, and how changes might affect other parts of the system.

Strong engineers need more than implementation skills. They must understand the problem a product is trying to solve and make technical decisions that support that goal.

A product and technical deep dive combines product thinking, system design, and engineering discussion. Candidates receive a problem, often involving an AI-powered product, and work through possible solutions with the interviewer.

The discussion may cover:

This approach tests whether someone can connect technical decisions to business and user needs.

For example, building an AI-powered customer support tool is not simply a matter of connecting a model to a chat interface. The engineering team must consider response accuracy, data privacy, latency, operating costs, escalation to human support, and how the system handles uncertain answers.

A candidate who immediately starts discussing frameworks without clarifying the product requirements may overlook the actual problem. Someone who asks thoughtful questions, identifies constraints, and explains trade-offs demonstrates a more complete engineering approach.

Tip: When discussing a technical solution, start with the user problem and requirements. Explain the architecture only after establishing what the system must accomplish and which constraints matter most.

Another alternative is to give candidates a practical task that resembles their expected responsibilities.

A backend engineer might implement an API endpoint or service. A frontend engineer might build a user-facing feature. A candidate working on web applications could be asked to create a functional landing page.

The exercise can take place as a collaborative pair-programming session, with the candidate sharing their screen and working through the task alongside an interviewer.

Importantly, candidates can be allowed to use the tools they would normally use on the job, including AI coding assistants, documentation, IDEs, and search engines.

The objective is not simply to inspect the final code. It is to observe the decisions made along the way.

Does the candidate clarify unclear requirements? Do they break the problem into manageable steps? Can they guide an AI tool with useful instructions? Do they inspect generated code before accepting it? Can they write tests and investigate unexpected behavior?

AI assistance should not automatically be treated as a shortcut or a weakness. In modern engineering environments, knowing how to use these tools effectively is part of the job. However, using AI does not remove the responsibility to understand the result.

A candidate who generates a large amount of code but cannot explain its behavior may create more problems than they solve. A candidate who uses AI selectively, checks assumptions, and catches mistakes demonstrates stronger technical ownership.

Companies can also combine exercises: one task without AI to examine foundational skills, followed by another where AI is permitted to assess tool usage and verification.

Tip: If you are interviewing, explain your reasoning while working. Show how you clarify requirements, use AI when appropriate, test the output, and respond when something does not work. The quality of your decisions matters as much as the final implementation.

One of the most useful interview formats is a conversation built around projects and problems relevant to the role.

Instead of asking every candidate to solve the same abstract challenge, interviewers explore how someone has handled difficult engineering situations and how they would approach realistic problems.

Questions can include:

The follow-up questions are particularly important. A candidate might describe a successful project, but the details reveal whether they genuinely understand the work.

For example, asking what alternatives were considered helps uncover whether the person evaluated different approaches or simply followed the first suggestion. Asking how correctness was verified reveals whether testing and validation were part of the process.

These conversations also expose communication skills. Engineers regularly explain technical decisions to colleagues, managers, designers, and stakeholders. Being able to communicate a complicated idea clearly is part of delivering good work.

The goal is not to find someone who always has an immediate answer. It is to understand how they think when the answer is uncertain.

Tip: Prepare a few detailed project examples. Be specific about your contribution, the decisions you made, the challenges you encountered, the results, and what you learned. Avoid taking credit for work completed by the entire team.

Take-home assignments can give candidates more time to demonstrate their abilities, but AI has made their results harder to interpret.

A candidate can submit a polished implementation generated with substantial AI assistance without necessarily understanding every part of it. The finished repository may look impressive while providing limited evidence of how the person would perform during everyday engineering work.

This does not make every take-home assignment useless. They can still provide value when the task is realistic, appropriately scoped, and followed by a discussion in which candidates explain their decisions.

Interviewers can ask why a particular architecture was chosen, what alternatives were rejected, how the code was tested, and what would need to change before production deployment.

Without that discussion, the final submission may reveal more about the candidate's ability to produce a deliverable with available tools than their ability to own the solution.

For candidates, the same principle applies: never submit work that cannot be explained or maintained. A working demonstration is only one part of engineering competence.

Tip: If you receive a take-home assignment, keep the implementation focused and document important decisions. Be prepared to explain the code, limitations, testing strategy, and improvements you would make with more time.

LeetCode is not dead. Large companies may continue using algorithm interviews because they offer a familiar and scalable way to assess candidates. Anyone targeting those organizations should still prepare for that possibility.

But the definition of technical ability is becoming broader.

An engineer's value is not limited to writing code quickly. It also comes from understanding existing systems, identifying risks, translating product requirements into technical decisions, collaborating with others, and verifying that a solution works.

For hiring teams, this means designing interviews around the actual responsibilities of the role. A backend engineer, frontend developer, infrastructure specialist, and AI engineer may need different assessments. A single standardized puzzle cannot measure every skill equally well.

For candidates, the opportunity is to demonstrate the complete engineering process: understanding the problem, choosing an approach, using tools intelligently, checking the results, and explaining the decisions.

AI can make producing code easier. It does not automatically make someone a better engineer.

The strongest candidates will be those who can combine technical foundations with sound judgment, practical experience, and the ability to take responsibility for what they build.

Hit reply and tell me: has AI changed how you interview engineers, or how you prepare when you're the candidate? I read every answer.

Keep going, one small spark at a time.

Erwin