Software engineering was never about writing code; it’s always been about solving business problems. Despite this, most companies I’ve talked to in the past 12 months are still interviewing with LeetCode and Kubernetes trivia. If an AI agent can pass your technical test, not only is your process broken but you’re also sending a bad signal about your engineering culture.

Instead of testing if a candidate can outperform an agent, we should be testing if they can direct one. The best hires are pragmatic owners who identify the right problems to solve and leverage every tool at their disposal to ship them.

2015-style interviews fail in the AI era

During my career, I’ve been grinding LeetCode challenges, and spending evenings on Cracking the Coding Interview. I got tested on so many different types of questions, from Fizz Buzz to LeetCode hard questions, rapid-fire trivia to open-ended organizational discussions. Finally, I’ve seen how they rarely transpose to our day-to-day job.

I’ve also been on the other side of the table as I ran over a hundred interviews at Canva, and led final decision meetings. By 2025, I transitioned to AI-assisted interviews: very broad and deeply technical challenges to solve in just under an hour. This has completely changed my view on which signals to probe and look for.

Now, the AI coding workflows are becoming more mature and well adopted (more than 36% of Stack Overflow 2025 survey respondents use AI-enabled tools). Shipping fast is the norm, and coding language fluency is harder to probe and no longer a key differentiator. We expect engineers to be broader across domains and exercise critical thinking.

With this change of modus operandi, engineers spend more time reading code, whether that is text-completion or code reviews - than writing it. Being able to audit the code is a large part of the job now. One of my favorite types of interview is to ask the candidate to extend an existing system or do a code review exercise.

Value interviews are now immensely more important than before. They give extra time to probe on soft skills such as leadership, communication and strategy and are absolutely worth extra investment. Try to go deep into past experiences and key decisions, as any discussion too shallow is easily “fakable”.

De-scoping

The most expensive mistake is solving the wrong problem. At this stage, I am not looking for technical details, but for the ability to scope a problem to meet business needs. Can they find the right MVP to solve based on the known constraints?

The more senior the engineer, the more I keep the problem vague and high-level. I expect the candidate to probe and ask clarifying questions. Great engineers make the problem smaller and less ambiguous before diving in. They clearly question and state their assumptions out loud so we can validate them collaboratively.

I particularly appreciate candidates who explicitly call out “out of scope”, and overly expensive or complicated edge cases not worth optimising for.

While tighter scopes are expected for junior roles, we must stay mindful of the new floor: anything already well-defined can now be largely delegated to an agent.

First-Principles Design

Once the scope is clear, we move to high-level design. This isn’t about choosing a specific technology, but about articulating trade-offs and laying down the fundamentals.

I do not care whether a candidate wants to introduce a new MySQL or Postgres database, as long as they can state why a relational database is required. I am looking for the ability to explicitly tie system properties - like consistency or durability - back to the business requirements we just defined.

Many interviewers fall into the trap of asking technology-specific trivia, expecting candidates to recite framework features like magic incantations. For example, I was once asked how I would scale Kubernetes pods based on non-native metrics. A question like this tests my ability to do a Google search. It also sends a negative signal about the company: what kind of micro-management or “check-box” engineering culture is actually happening there?

Frameworks and libraries are transient; architectural patterns and the trade-offs they imply are what stay constant.

AI leverage with ownership

It’s now time to implement a working solution. In a 60-minute exercise, we want to see the deliverable: running code. We deal with all sorts of constraints in the real world, and time is a very clear one here.

I like to spend a few minutes analyzing the candidate’s development environment itself. It’s a great learning piece: How tight is their feedback loop? Is their AI setup leveraging local tooling (MCP, Skills) to be more efficient? What is their reasoning for picking a specific model for this task?

I value engineers who can leverage the best tools, but I am specifically looking for how they direct those tools. Thoughtworks warns that complacency with AI-generated code is a leading cause of technical debt and declining quality, and CISQ has shown that the average developer spends roughly 1/3 of their week addressing tech debt. In short, if the candidate isn’t deeply owning the code during an interview, they aren’t going to day-to-day, and the velocity will suffer.

The best candidates I’ve seen apply Test-Driven Development (TDD) principles to the AI workflow. They focus on reviewing test cases before looking at implementation details. They care about how the interface is exposed and consumed first, ensuring the contract is right before fixing lower-level logic.

Eventually, I start probing harder on the craft skills like attention to edge-cases and other domains such as concurrency, encoding, failure modes, space/time complexity, accessibility, security…

Final take

This isn’t 2015 anymore. Asking an experienced candidate to answer framework trivia questions or white-board a sorting algorithm is a complete disconnect from the real world.

On the other hand, hiring someone who relies on AI without deep ownership or architectural understanding is shooting yourself in the foot in the long run as you’re trading short-term speed for long-term debt such as bottlenecks in performance, reliability and maintainability issues.

Tools and frameworks are changing faster than ever. Embrace AI, but make sure to probe for the ability to understand the business problem, articulate the trade-offs they are making, and ship fast with ownership.

A few years ago, shortly after joining a scale-up, I was handed a task as part of my onboarding: “Add an autoscaler to this ECS service to reduce the cost of unused compute. It shouldn’t take more than half a day.”

At first, it sounded straightforward. The service was significantly overprovisioned with very little load. A rough estimate suggested we could reduce the fleet size by 80% and immediately cut costs. It looked like an easy win, so I implemented it.

Before calling the task complete, I ran a load test approximating production traffic. The autoscaling logic triggered correctly, and new tasks started launching. But then, requests started failing, and clients began seeing 502 and 504 errors.

Digging deeper, I found a few issues:

• The concurrency model (Gunicorn/gevent) lacked proper monkey patching.
• Neither the client nor the Traefik proxy layer implemented retries.
• New ECS tasks took up to 8 minutes to become ready to serve traffic.
• Health checks and timeout configurations were misaligned.

After talking more with the core maintainer, latency wasn’t the primary constraint as this service handled long-running jobs, but availability was.

In short: the system was not designed to scale horizontally in a safe way.

Instead of delivering immediate business value, I had to spend our limited time budget proving why the prescribed solution was insufficient, and investigating what actual architectural changes were needed. Ultimately, the cost of refactoring the service outweighed the immediate infrastructure savings, and we made the pragmatic business decision to move on to higher-priority initiatives. These machines are still burning money today.

The Anti-Pattern: Prescribing the “How”

What went wrong here? I was handed a prescriptive solution that ignored the system’s historical context.

When organizations prescribe exact solutions to their engineers, they unintentionally build a culture of dependency. We train teams to wait for instructions rather than think critically, shifting the engineer’s role from a problem-solver to a mere implementer.

More importantly, when an engineer just executes a predefined task, they don’t own the deliverable. If the solution fails, the accountability falls on whoever wrote the ticket. You cannot hold someone accountable for an outcome if they had no say in the methodology.

This is entirely incompatible with a culture of true engineering ownership, which a lot of companies claim to have.

A Better Way: Framing the “Why”

We could have achieved a much better outcome simply by phrasing the task differently:

“In the Bar project, our image-processing machines are largely underutilized and costing us money. Could we aim to reduce this bill by 80%, or do the best we can within a 2-day timebox?”

This approach provides context, states the business goal, and sets a measurable constraint. Most importantly, it delegates the methodology to the engineer.

In this case, simply optimizing the client to handle failures gracefully and setting a fixed, smaller number of nodes would have met the goal.

Influencing Through Inquiry

As a tech lead, it is tempting to push for the solution you see in your head. But the best way to ensure an implementation actually solves the root issue is to collaborate.

Instead of dictating, ask:

• What approaches have you considered?
• How should we handle the edge case when X happens?
• What do you see as the biggest roadblock here?
• What is the engineering effort of solution Z compared to the business benefit?

Beside, guiding an engineer to the solution themselves gives them a sense of achievement and total ownership.

Scaling Ownership: A Canva Success Story

While working as a Staff SRE at Canva, I led a year-long initiative to discover and remediate systemic reliability risks across a platform serving 250 million MAUs.

We built an automated system that parsed incident postmortems, Slack context, and Service SLOs using data science and LLMs. This allowed us to build a comprehensive and continuous backlog of reliability risks.

SREs translated these risks into well-framed problem statements for the owning teams. We ensured every ticket had:

1. Clear user impact, linked to previous incident metadata.
2. Measurable outcomes, tied directly to observability metrics.
3. A framing of business risk.

By the time I left, we had accumulated a backlog of over 80 well-framed reliability risks, with half successfully adopted onto product team roadmaps. We rarely saw pushback because we weren’t telling them how to write their code; we were showing them a critical business problem and trusting them to solve it.

Even better, the engineers who were able to solve this risks could measure their impact through real business metrics. How good!

Conclusion

When people are trusted to design their own solutions, they become deeply invested in making them work. Solutions are often better and engineers grow in their craft and develop autonomy.