Most AI hiring plans are trying to fix an interface problem with resumes.

If product, platform, and applied AI are not built as one operating system, new headcount adds motion but not leverage. The constraint is usually not talent scarcity. It is system design.

Recruiting Alone Cannot Fix a Broken Stack

AI organizations often describe their issue as “we need stronger talent.” In many cases, they already have capable people. What they lack is a clear operating contract across teams.

The pattern is familiar:

• product optimizes for release velocity
• platform optimizes for reliability and control
• applied AI optimizes for model behavior and evaluation quality

Each goal is rational. The breakdown happens at the handoffs.

When interfaces are unclear, every launch becomes a negotiation. When interfaces are explicit, the same teams produce compounding output.

The Three-Layer Talent Stack

A healthy stack has three interlocking layers with distinct responsibilities:

1. Product — owns user outcomes and business success metrics.
2. Platform — owns safe defaults, deployment paths, and observability.
3. Applied AI — owns workflow behavior, retrieval/prompting/routing choices, and evaluation quality.

These are not departments in competition. They are system components with different jobs.

If product outruns platform, quality debt accumulates. If platform outruns product, infrastructure becomes generic overhead. If applied AI outruns both, you get technically impressive demos that never operationalize.

Where Organizations Usually Break

Most failures are boundary failures, not individual failures.

Common symptoms:

• no explicit owner for the model-to-product handoff
• platform operating as a ticket queue instead of an enablement layer
• applied AI measured by demo novelty instead of adoption in live workflows
• product committing features that infra cannot support safely

A concise diagnosis: org debt is usually interface debt with better branding.

Design the Stack Intentionally

The fix is not “more syncs.” The fix is explicit decision rights.

• product owns problem selection and business tradeoffs
• platform owns reliability guardrails and release safety
• applied AI owns workflow performance and evaluation integrity
• leadership owns escalation rules when tradeoffs conflict

Once this is explicit, hiring quality improves. You stop searching for mythical generalists and start hiring operators who can perform inside a coherent system.

What to Evaluate Before Adding Headcount

Before opening new roles, run this short check:

1. Are cross-team handoffs documented and current?
2. Does each layer have clear success metrics it actually controls?
3. Are escalation paths clear when speed, reliability, and quality disagree?
4. Are teams rewarded for system outcomes rather than local optimization?

If those answers are weak, fix interfaces first. New hires will scale the current operating model, good or bad.

Key Takeaways

• Strong AI organizations are designed as a system, not staffed as silos.
• Product, platform, and applied AI need explicit interfaces and decision rights.
• Boundary clarity is a bigger lever than raw headcount.
• Hiring works best after the operating contract is clear.

The best AI hires are not the people who can narrate the model stack. They are the operators who can turn ambiguity into a system, make the failure mode legible, and keep shipping when the first answer is wrong.

That is why judgment matters more than hype. Teams that hire for excitement get enthusiastic meetings. Teams that hire for operator discipline get leverage.

The Operator Profile

Strong AI operators usually have four traits:

• they can turn a vague brief into a tractable plan without waiting for perfect inputs
• they know enough about systems tradeoffs to challenge weak assumptions early
• they care about verification as much as output
• they can move between engineering, product, and executive language without flattening the nuance

Model trivia is cheap. Operator judgment is what survives contact with production.

The market is full of people who can name the newest framework. The shortage is people who can keep a system healthy when the workload changes, the vendor shifts, or the first release misbehaves.

What Most Teams Hire Wrong

AI hiring goes off the rails when teams reward signals that are easy to notice but hard to run with.

Teams over-index on:

• prompt fluency without operational discipline
• research taste without delivery habits
• architecture opinions without incident literacy
• product instinct without measurement rigor

None of those traits is bad. The problem is imbalance.

A strong AI team needs people who will own the boring parts: evals , fallback logic, access boundaries, cost control, and documentation precise enough that someone else can operate the system later.

If a candidate can talk fluently about models but cannot explain how they would debug a bad release, they are not ready to own production AI.

The Interview Questions That Matter

You do not need a clever hiring process . You need questions that force real evidence.

Ask candidates to walk through:

1. A system they had to stabilize. What was broken, how did they know, and what changed after they touched it?

2. A decision they reversed. Strong operators do not defend bad ideas forever. They update when the evidence changes.

3. A workflow they measured. If they cannot show how they connected work to metrics, they probably did not own the outcome.

4. A failure they made safer. In AI, good operators do not eliminate failure. They bound it.

A useful answer is concrete, a little messy, and grounded in actual work. The worst answer sounds polished and empty.

Hire for the Shape of the System

AI teams do not need the same operator profile in every context. Research-heavy, production-heavy, and regulated enterprise teams all demand different instincts.

If you want a research-heavy team, hire for exploration and rigor. If you want a production-heavy team, hire for stability and operational discipline. If you want a regulated enterprise team, the bar is not “exciting.” The bar is whether this person can help you ship safely, repeatedly, and without heroics.

That is the real operator profile:

• can handle uncertainty without freezing
• can make tradeoffs explicit
• can leave behind a system other people can run
• can keep pace without turning every launch into a performance

Key Takeaways

• Hire AI operators for judgment, not model vocabulary.
• Ask about stabilization, reversal, measurement, and safer failure.
• The strongest people leave behind systems, not just stories.
• If a candidate cannot explain how they debug and bound failure, keep looking.

That sounds harsh. It’s also true.

The Ownership Gap

Here’s how it usually goes. A company decides to “do AI.” They hire an ML engineer, maybe two. Those engineers build a demo. Leadership is impressed. Then someone asks, “Who owns this in production?” and the room goes quiet.

The ML engineer built the model. The product team didn’t spec the success criteria. The data engineer wasn’t involved. The designer has no idea what happens when the model gets it wrong. And nobody defined what “getting it wrong” even means.

I’ve seen this exact pattern at large enterprises and small startups. The blocker isn’t technology. It’s structure.

Three Models That Work

Every successful team I’ve seen fits one of three structures, and the core tradeoff has not changed.

Embedded. AI engineers sit inside product teams. They ship features directly, own the evaluation, and live with the consequences of their choices. This works when AI is a feature, not a platform. The downside: practices drift across teams because there’s no central coordination.

Platform. A central team builds shared infrastructure – model serving, evaluation harnesses, prompt management, observability. Product teams consume that platform. This works when multiple products need AI. The downside: the platform team gets pulled in every direction and loses focus on any single product.

Hybrid. A platform team builds the core. Embedded engineers in product teams customize it. This is the most common pattern at companies that have scaled this successfully. It also requires the most coordination. Without clear ownership boundaries, it degenerates into blame-passing between platform and product.

Pick the model that matches your current scale, not the one you hope to need in two years.

Who to Hire

The best AI engineers I’ve worked with share a few traits that don’t show up on resumes.

They can explain how their system fails. Not just how it works, but how it breaks and what happens when it does. This is the best interview signal I’ve found.

They think in systems, not models. The model is one component. The retrieval layer, validation step, fallback path, and monitoring are just as important. A candidate who talks only about model architecture is missing the point.

They build evaluations before they build features. If you can’t measure whether the thing works, you’re guessing. The best engineers treat eval sets like test suites. They version them, maintain them, and refuse to ship without them.

They’ve shipped something to real users. Not a notebook. Not a demo. Something people used, complained about, and forced them to iterate on. Production experience changes how you think about every design choice.

The Operating Loop

Fancy process frameworks aren’t necessary. A tight loop between four phases covers it:

Discovery. Define success in measurable terms. What does “good” look like? What are the edge cases? Is the data available? A clear definition of success is worth more than a long list of ideas.

Prototyping. Run small experiments with real examples. Document the failures, not just the successes. Bring domain experts in early – they know the edge cases you’ll miss.

Development. Build the evaluation suite first. Version prompts and retrieval logic as code. Test against known failure cases whenever models or data change.

Production. Roll out gradually. Monitor quality and cost in the same dashboard. Treat regressions as product issues with named owners, not vague “the model changed” explanations.

What Actually Goes Wrong

The problems I see most often aren’t technical:

• Nobody owns evaluation for a specific feature. There’s a shared checklist but no named person.
• Success criteria are undefined, so feedback becomes opinion. “This doesn’t feel right” isn’t actionable.
• The pipeline is too complex for the use case. Someone built a multi-agent system for what should have been a single prompt.
• Knowledge stays in people’s heads. When someone leaves, the team loses context that took months to build.

Fix these four problems and you’re ahead of most AI teams. No new tools required. No new hires. Just clarity about who owns what and how you know it’s working.

That’s the whole secret: clear ownership, reliable evaluation, and the discipline to maintain both. Everything else is detail.

Stop hiring ML researchers to do integration work. AI engineering is the craft of turning probabilistic models into reliable product features. Different job, different skills, different mindset.

After a year of working on AI integration across different organizations, the pattern I keep seeing is the same: a team hires a machine learning engineer, points them at a product feature, and wonders why the result is a brilliant notebook that falls apart the moment a real user touches it.

The problem isn’t the engineer. The problem is a category error.

This isn’t ML. This isn’t backend. It’s its own thing.

AI engineering sits in an awkward gap. On one side, you have model training – the research-heavy work of building and improving models. On the other, traditional software engineering – APIs, databases, deployment pipelines, the stuff we’ve been doing for decades.

AI engineering is neither. It’s the work of taking someone else’s model and making it do something useful, reliably, in production. That means prompt design, retrieval pipelines, evaluation harnesses, cost management, safety guardrails, and graceful failure handling. It means caring deeply about the 2% of cases where the model confidently produces garbage.

I spent years building backend systems across fintech and cloud infrastructure. The shift to AI engineering felt familiar in some ways – you still think about latency, error handling, observability. But the non-determinism changes everything. You can’t unit test your way to confidence when the same input produces different outputs on Tuesday.

The skill set looks different

When I talk to CTOs about what to look for in AI engineering hires, I push them away from the classic ML job description. The competencies that actually matter are:

• Prompt design and testing. Not prompt “engineering” as a parlor trick. Systematic testing across edge cases, with version control and regression detection.
• Retrieval and context assembly. Getting the right information to the model at the right time. This is where most applications succeed or fail.
• Integration discipline. Error handling, latency budgets, fallback paths. The boring stuff that separates demos from products.
• Evaluation loops. If you can’t measure whether your AI feature got better or worse after a change, you aren’t doing engineering. You’re doing improv.
• Safety and guardrails. Especially when the model can take actions or access private data.

None of this requires a PhD. It requires someone who has shipped software, understands production systems, and has the patience to wrangle probabilistic outputs into predictable behavior.

It’s a set of responsibilities, not a stack

People keep trying to draw AI engineering as a neat layer diagram. In practice, it’s a set of cross-cutting responsibilities. You’re choosing models, preparing data, shaping prompts, monitoring quality, controlling costs, and enforcing safety – all at once. The reason the role feels distinct is that it spans product thinking, system design, and ongoing operational care in a way that neither pure ML nor pure backend roles typically do.

At one large telecom, I watched teams try to split these responsibilities across existing roles. The ML team owned prompts. The backend team owned integration. The product team owned evaluation. Nobody owned the whole thing. The result was predictable: finger-pointing when quality dropped and no single person who could trace a bad output from user input to model response to product impact.

How to actually build these skills

Depth beats breadth. Don’t chase every new framework or technique. A solid path:

1. Build a feature that calls a model and returns something useful. Ship it.
2. Add retrieval so the model’s answers are grounded in real data instead of vibes.
3. Build an evaluation loop that catches regressions before your users do.
4. Add guardrails and define what happens when the model fails. Because it will.

The practice is learned by shipping and iterating. Blog posts help (including this one, I hope), but they aren’t a substitute for watching your carefully crafted prompt fall apart on production traffic.

Where this fits in your org

In smaller teams, AI engineering looks like a product-focused engineer who owns the AI feature end to end. At larger companies, it becomes a dedicated role that sits between product, platform, and security.

The interaction model is clean. Product defines intent and user experience. Platform provides infrastructure and monitoring. Security sets the safety bar. AI engineering turns those constraints into working features that don’t embarrass anyone.

The demand for this role is growing fast. Job descriptions are finally separating AI engineering from ML research, and the expectations center on integration, evaluation, and reliability rather than paper-publishing and model architecture. Good. That separation was overdue.

The discipline, not the hype

AI engineering isn’t a buzzword rotation. It’s the recognition that making models useful in production is real engineering work – with its own tools, its own failure modes, and its own career path. The teams that treat it as a distinct discipline are shipping better features. The teams that don’t are still arguing about whether their demo “works.”

Discipline over heroics. That’s the whole game.

What a year.

The Work

My main focus this year was a large consumer platform and a real-time messaging company, and the contrast was instructive.

At a large consumer platform, I worked on infrastructure that had to be reliable at scale – food delivery doesn’t tolerate downtime during lunch rush. The engineering culture was strong, the problems were interesting, and the systems were complex enough that good decisions compounded visibly. Working on their platform gave me a front-row seat to what happens when infrastructure is treated as a product rather than a cost center. It works. Teams ship faster, incidents are contained better, and new engineers become productive sooner.

At a real-time messaging company, the challenge was different – real-time messaging infrastructure at massive scale, where latency and reliability are the product. The work forced me to think carefully about state management, edge cases in distributed systems, and what “good enough” looks like when your customers are building their own products on top of your platform. It also reinforced something I keep learning: the boring engineering decisions – how you structure your Terraform, how you manage state, how you test infrastructure changes – matter more than the clever ones.

Both experiences reminded me why I like variety in my work. You see more patterns, more organizational shapes, more ways things can go right and wrong.

The Layoff Wave

I watched the layoffs arrive from a strange angle – close enough to feel the impact, removed enough to see the patterns across multiple organizations.

The speed of the pivot was jarring. Companies that were hiring aggressively in January were cutting in November. The same leadership that pushed “grow at all costs” pivoted to “efficiency is everything” without acknowledging the whiplash.

The organizations that handled it well were honest about the business reasons, treated departing people with dignity, and immediately rescoped their roadmaps to match the smaller team. The ones that handled it poorly did multiple waves, pretended the plan hadn’t changed, and burned out the remaining team trying to deliver the same roadmap with fewer people.

I’ve been on the founding side of this. When a travel startup’s runway got tight, I had to make similar calls. It’s never clean. But there’s a difference between hard and careless. Some of what I saw this year was careless.

ChatGPT Changes the Conversation

Then in late November, ChatGPT landed. I wrote about my first impressions already, but looking back at the full year, the trajectory is clear: AI went from a curiosity to a daily tool in about twelve months.

I started the year barely thinking about AI in my day-to-day work. Copilot was interesting but not essential. I ended the year using ChatGPT multiple times a day for drafting, debugging, and thinking through problems. The speed of that adoption – in my own workflow, not just the industry – caught me off guard.

The biggest shift isn’t productivity. It’s the realization that code generation is becoming commoditized. The cost of producing a first draft is dropping toward zero. What remains expensive – and will stay expensive – is knowing whether the draft is correct, appropriate, and maintainable. Judgment. Context. Taste.

For someone who has spent a career building expertise in systems design and infrastructure, this is actually reassuring. The skills that matter most are the ones that AI can’t fake yet: understanding tradeoffs, designing for failure modes, knowing when “good enough” is the right answer.

What Held Up

Looking back across the year, a few principles proved durable:

Discipline over heroics. I keep coming back to this. The teams that survived 2022 in good shape weren’t the most talented or the most well-funded. They were the most disciplined. Clear priorities, sustainable pace, honest communication.

Boring infrastructure wins. Every Terraform module I wrote this year was boring on purpose. No clever abstractions, no over-engineered wrappers. Simple modules with clear inputs, versioned state, automated tests. The boring stuff is what you can trust at 2am.

Relationships compound. The work I got this year came from people I had worked with before who trusted me to deliver. No amount of marketing replaces that.

Looking at 2023

I expect the layoff wave to continue into Q1 at least. The companies that cut early and honestly will recover first. The ones that are still pretending everything is fine will have a harder Q1.

AI will keep accelerating. By mid-2023, I expect code generation to be a standard part of most engineering workflows, not an experiment. The teams that will benefit most are the ones investing in verification – testing, code review, and quality infrastructure – not just generation speed.

For my own work, I plan to keep building, keep contributing to Go, and keep writing. This year reinforced something I believe strongly: the fundamentals don’t change. Languages change, tools change, economic cycles change. But clean architecture, honest communication, and sustainable engineering practices outlast all of it.

2022 was hard. It was also clarifying. Sometimes you need the music to stop to figure out who was actually dancing and who was just standing near the speakers.

This isn’t a framework post. It’s what I’ve seen and what I think matters.

The Shift Nobody Planned For

Eighteen months ago, every company I talked to was hiring aggressively. “We can’t find enough engineers” was the universal complaint. Now the complaint is “we hired too fast and the math doesn’t work.”

The market shifted from rewarding growth to rewarding efficiency. That’s a legitimate economic correction. But the speed of the pivot is brutal. Teams that were told to scale fast are now being told to do more with less, sometimes by the same leadership that set the original targets.

What I’ve Seen Go Wrong

The worst layoffs I’ve watched – and I’ve watched a few this year – share common traits.

Multiple waves. Nothing destroys trust faster than a “one-time reduction” followed by another one six weeks later. If leadership doesn’t know the full scope of cuts, they should say so honestly rather than promise stability they can’t guarantee.

Silence from above. At one organization I worked with, the engineering org learned about layoffs from Twitter before they heard from their own leadership. That isn’t a communication problem. That’s a respect problem.

Pretending the plan didn’t change. After cutting 20% of engineering, one organization kept the same roadmap and the same deadlines. The remaining team burned out within two months. Three more people left voluntarily. The original cost savings evaporated.

Knowledge walking out the door. I saw a team lose the only person who understood their payment processing pipeline. No documentation, no pairing history, no runbooks. Three months later they were still reverse-engineering their own system.

What I’ve Seen Go Right

The organizations that handled this well did a few things consistently.

They were honest about the business reason. Not corporate-speak, not “rightsizing for the future.” Honest: “Revenue is down, burn rate is too high, and we need to cut costs to survive.” People can handle hard truths. They can’t handle feeling manipulated.

They treated departing people with real dignity. Generous severance where possible. Genuine references. Time to say goodbye. The remaining team watches how you treat the people who leave. It tells them everything about what they can expect.

They immediately rescoped. Smaller team means smaller roadmap. Full stop. The best leader I watched through this process cancelled three initiatives within a week of the layoff, told the team “we’re doing these two things well, nothing else,” and stuck to it. That team stabilized faster than any other I saw.

For the People Who Remain

Survivor guilt is real and poorly understood. You kept your job, so you should be grateful, right? Except your friend got walked out, your workload doubled, and nobody has told you whether more cuts are coming. “Grateful” isn’t the word that comes to mind.

What actually helps:

Acknowledge the loss. Don’t skip past it. The people who left were colleagues, mentors, friends. Pretending everything is normal is insulting and counterproductive.

Reset expectations explicitly. What are we building? What are we not building? Who owns what now? If these questions aren’t answered within a week, anxiety fills the vacuum.

Protect sustainable pace. A smaller team carrying a larger roadmap is a team in the process of losing more people. Voluntary attrition after layoffs is the hidden second wave that leadership never budgets for.

Distribute Knowledge Before You Have To

The best insurance against knowledge loss isn’t documentation. It’s rotation. Pair on critical systems. Rotate on-call. Make sure at least two people can deploy, debug, and recover every service that matters.

I keep coming back to this: resilience isn’t about having a plan for when things go wrong. It’s about building systems – human systems – that can absorb shocks without collapsing. That means shared ownership, documented decisions, and deliberately avoiding single points of failure in your org chart.

For Leaders

You can’t control the macro environment. You can control how clearly you communicate, how honestly you scope, and how consistently you protect your team’s focus.

Watch for burnout signals: declining code quality, slower response times, people going quiet in meetings who used to speak up. These are leading indicators of the next round of attrition – the voluntary kind that hurts even more because it’s your best people who leave first.

Advocate upward for realistic expectations. If leadership expects the same output from a smaller team, push back with data. “We can deliver A and B by Q1, or A, B, and C by Q2. Pick one.” That isn’t defiance. That’s responsible leadership.

A Personal Note

Having gone through a deep-tech founder program and built startups, I’ve been on the other side of this equation too – making hard calls about team size when the money is running out. It’s never clean. But the difference between organizations that recover and organizations that spiral comes down to honesty and scope discipline.

Heroics don’t scale. Discipline does. The teams that will come out of this cycle stronger are the ones that cut scope honestly, protected their people’s energy, and resisted the temptation to pretend nothing changed.

At a mobility startup, we got this down to day two for most new hires. Not because we had some elaborate onboarding program. Because we had a checklist, a buddy system, and a backlog of small tasks tagged “good first issue.” The new engineer’s first PR was reviewed and merged before they finished reading the architecture docs. That’s the order it should happen in. Ship first, context second.

The real problem with onboarding

Most onboarding programs are designed around what the company wants to communicate, not around what the new hire needs to be productive. Day one becomes a parade of slides: company history, org chart, values, benefits, security training. The engineer sits through hours of content they won’t remember, and by the end of the day they still can’t push to the repo because their access request is pending.

Every hour spent in orientation that could have been spent writing code is a signal that the company values process over output. New hires pick up on that fast.

What actually matters in week one

Access on day one. Laptop, accounts, repo access, dev environment – all of it should be working before the engineer opens Slack for the first time. If access provisioning takes more than a day, your onboarding is already behind. Automate it. Test the automation quarterly by running it against a clean machine.

A real first task. Not a tutorial. Not “read the docs.” A real bug fix or small feature that touches the production codebase. It should be small enough to finish in a day, scoped enough to not need deep context, and assigned to a specific reviewer who will prioritize the review.

The first merge matters more than any presentation. It proves the workflow works, the environment is set up correctly, and the engineer can contribute. Everything after that’s momentum.

A buddy, not a babysitter. The buddy answers the dumb questions. “Where do I find the staging URL?” “Who reviews changes to this service?” “How do I get a test database?” The buddy isn’t responsible for the new hire’s career development or performance evaluation. That’s the manager’s job. Keep the roles separate.

Stop over-documenting, start pairing

I’ve seen teams spend months building elaborate onboarding wikis that nobody maintains. They go stale within a quarter. A 30-minute pairing session where the buddy walks through the deploy pipeline is worth more than a 20-page document about the deploy pipeline.

Keep documentation focused on what changes slowly: architecture overview, service map, on-call runbook. For everything else, pair. New hires should be encouraged to update docs when they find gaps – fresh eyes catch stale content better than any scheduled review.

The 30-day check

By the end of month one, a new engineer should be able to pick up a ticket, implement it, get it reviewed, and deploy it without asking how. If they can’t, something in the onboarding failed. Treat it as a systems problem, not a people problem. Did they get enough context on the codebase? Was the first month’s work well-scoped? Did the buddy actually check in?

Measure this with two signals: time to first solo PR (without buddy assistance on the workflow) and the new hire’s own confidence level. Ask them directly. “Do you feel productive? What’s still blocking you?” The answers will tell you more than any dashboard.

Onboarding isn’t a one-time project. It’s a system that compounds. Every new hire who has a good first week becomes someone who can onboard the next person. Every broken onboarding creates someone who spends their first month confused and frustrated, and that frustration echoes through their entire tenure.

That was week three of Decloud. We were hiring our first engineers and doing it fully remote from day one. Not because we were visionary. Because it was May 2020 and there was no other option.

Since then I’ve run maybe fifty virtual interviews across Decloud and the fintech startup. I’ve gotten some things very wrong and a few things right. Here’s what actually matters.

Whiteboard coding over Zoom is broken

I’ll die on this hill. Asking someone to solve an algorithm on a shared whiteboard tool while you watch through a webcam is a terrible experience for everyone involved. The candidate can’t think naturally. You can’t read their body language. The tool always has some lag or quirk. And what are you even measuring? Their ability to perform under artificial pressure on a laggy canvas?

I stopped doing it. Completely.

Instead I send a small take-home problem. Two to three hours of real work, a week to finish it. Then the live session is a code review of their submission. We walk through their decisions, I push on trade-offs, they refactor something live. This tells me ten times more than watching someone implement a linked list reversal on Miro.

The setup matters more than you think

The single biggest variable in virtual interview quality isn’t the questions. It’s whether the tech works. Sounds obvious. Almost nobody actually prepares for it.

My checklist before every interview block:

• Open the shared editor, paste something, delete it. Confirm it works on both sides.
• Test screen sharing. Every. Single. Time.
• Have a phone number or Telegram handle ready as backup. Zoom dies more often than people admit.
• Close Slack, email, everything. Notifications popping up during someone’s interview is disrespectful.

I also send candidates a prep email 48 hours out. Not a corporate template. A short note that says: here’s the Zoom link, here’s what we’ll cover, here’s the editor we’ll use, install nothing, and if anything breaks just message me on this number. People visibly relax when they know the logistics.

Keep it short

An hour-long virtual interview is thirty minutes of good signal and thirty minutes of diminishing returns. I cap everything at 45 minutes. The first five are small talk and tech check. The last five are their questions. That leaves 35 minutes of actual interview. Plenty.

If you need more depth for a senior role, split it into two sessions on different days. Two focused 45-minute conversations beat one draining 90-minute marathon.

What I look for changed too

On-site, you get all these ambient signals. How someone walks into the office. How they interact with the receptionist. Whether they ask good questions during the tour. That’s all gone now.

So I leaned harder into things I can actually observe on a call:

Communication under ambiguity. I intentionally leave parts of the problem vague and see how they handle it. Do they ask? Do they assume? Do they state their assumptions clearly?

Debugging live. During the code review session, I’ll point at something and say “this will break if X happens.” Watching someone debug in real time, talking through their reasoning, is the most reliable signal I’ve found for engineering skill.

Written communication. I added a short async component. After the take-home, before the live call, I ask candidates to write a paragraph or two about one decision they made and why. At a remote company, writing isn’t optional. If someone can’t explain a technical choice in a few sentences, that’s a problem.

The bias trap

One thing that caught me off guard: I started unconsciously judging people’s home setups. Nice bookshelf, good lighting, quality microphone — must be a serious person. Messy background, laptop mic, kids in the next room — less so.

This is garbage thinking and I had to actively catch myself. Someone’s apartment has zero correlation with their engineering ability. We made it a rule: cameras optional, background irrelevant, connection issues get a reschedule with no questions asked.

What I’d tell you to do

If you’re setting up virtual interviews for the first time, do three things:

1. Kill the live whiteboard coding. Replace it with take-home plus code review. Your signal will improve overnight.
2. Test your tools before every single session. Not once. Every time.
3. Make the process shorter than you think it needs to be. Respect people’s energy.

Virtual interviewing isn’t a downgrade. It’s a different format. Once I stopped trying to replicate the on-site experience over Zoom and started designing for the medium, the quality of our hires went up. Not down.

I became CTO of that company. The fintech startup. And the first thing I fixed was onboarding.

Not because it was the sexiest problem. Because it was the most expensive one nobody was measuring.

The Real Cost Nobody Tracks

When I was building Decloud during my founder-program cohort in 2019, every week a new engineer spent confused was a week we didn’t have. At a startup, a slow ramp-up isn’t an inconvenience. It’s an existential threat. But even at larger places, the math is brutal: a senior engineer who takes eight weeks to ship independently instead of three just cost you five weeks of salary for zero output. Multiply that by every hire per year.

The usual excuse is “our codebase is complex.” No. Your onboarding is lazy. Complexity is a reason to invest more in onboarding, not less.

What “Good” Actually Looks Like

I’ve onboarded engineers at the fintech startup, at a mobility startup, and at Decloud. Different products, different stacks, different countries. The pattern that works is boringly consistent.

Day one: the new engineer opens a PR. Not a meaningful one. Not a feature. A typo fix, a config tweak, a test improvement. The point is they’ve touched the full cycle – clone, build, branch, change, test, review, merge, deploy – before they go home. If your setup takes longer than a morning, it’s broken.

Week one: they own a real bug fix. Something with a clear repro, a limited blast radius, and enough context that they learn the codebase by reading the code that matters, not by reading a stale architecture doc.

Month one: they’re independently picking up work. They know who to ask, where the bodies are buried, and how deploys actually work (not how the wiki says they work).

That’s it. No elaborate 90-day plans. No onboarding “program” with a PowerPoint deck. Just a tight loop of ship, learn, ship.

make setup Or Go Home

At the mobility startup, we ran Go services talking to a handful of microservices. When I joined (before eventually leading the engineering), the local dev setup involved seventeen manual steps spread across a README that contradicted itself in three places. I rewrote it as a Makefile.

git clone git@github.com:company/app.git
make setup
make dev

Three commands. If it takes more than three commands to go from zero to a running local environment, you have a setup problem, not a complexity problem. Script it, containerize the dependencies, seed the database automatically. The new hire’s laptop is a test of your infrastructure’s maturity. If you can’t reproduce your dev environment reliably, what makes you think production is any better?

When I set up the dev environment at Decloud, I literally timed it. Fifteen minutes from git clone to running tests. If it crept past that, we treated it as a bug.

The Buddy System (Done Right)

Every new engineer gets a buddy. Not their manager. Not the tech lead. Someone close enough to the codebase to answer “where does this thing live?” questions but not so senior that the new hire feels stupid asking.

The buddy’s job is simple: be interruptible for the first two weeks. That’s the whole job description. They don’t need to teach. They need to unblock.

At the fintech startup, I paired each new hire with whoever had last touched the area of code they’d be working in. Not because that person was the best teacher, but because they had the freshest context. Onboarding is a transfer of context, not knowledge. The knowledge is in the code. The context – why this weird pattern exists, which service is actually deprecated but still running, where the real config lives – that’s in people’s heads.

Starter Tasks That Aren’t Insulting

The worst onboarding pattern is the “starter project” that’s actually a garbage task nobody else wanted to do. New engineers can smell it. It tells them their time isn’t valued.

Good starter work has three properties:

1. It touches production. The whole point is building confidence that they can ship safely.
2. It has a clear definition of done. Not “explore the payment service and propose improvements.” That’s a research project disguised as onboarding.
3. It teaches something specific about your system. A bug in the notification service teaches them about the event pipeline. An error message improvement teaches them about the API contract.

At Decloud, I kept a backlog of tagged issues specifically for this. Not fake work. Real bugs and improvements that were scoped to one or two days and came with enough context that someone new could pick them up without a forty-minute walkthrough.

Documentation: Less Is More

I’ve seen onboarding wikis with fifty pages of architecture history, org charts, and “philosophy” documents. Nobody reads them. The new hire skims the first two, gets overwhelmed, and asks their buddy anyway.

Here’s what new engineers actually need written down:

• How to set up their machine (the Makefile)
• How to deploy and how to roll back
• How to ask for help and who reviews what
• A one-page system overview with a data flow diagram

That’s four documents. Keep them short. Update them every time someone joins and finds something wrong. The onboarding docs should be the most maintained docs in your entire company, because they’re the only ones that get tested regularly by people who have no prior context.

The Feedback Loop Most Teams Skip

Here’s the thing that separates decent onboarding from great onboarding: you actually ask the new hire what was broken.

Every new engineer who joins should file at least one issue against the onboarding process itself. Not as a suggestion. As a requirement. “What was confusing? What was wrong? What did you have to ask someone that should have been written down?”

At the fintech startup, we turned this into a standing item in the 30-day check-in. Every single round of onboarding made the next one better. By the time I left, the setup was tight enough that contractors could be productive on day two.

Quick take

Stop treating onboarding as “show them the wiki and hope for the best.” Script the dev setup to three commands. Pair them with a buddy who has fresh context. Give them real work that touches production in week one. Then ask them what was broken and fix it. Repeat until your onboarding is your competitive advantage, not your embarrassment.

He’s one of our best hires.

That experience broke something in how I thought about interviewing. At the fintech startup we were growing the engineering team fast, and I kept seeing the same pattern: candidates who crushed whiteboard problems but couldn’t debug a real issue, and candidates who struggled with algorithmic puzzles but wrote clean, thoughtful code every day.

Something was deeply wrong with how our industry interviews people.

The stuff that doesn’t work

Whiteboard algorithms. I get why they’re popular. They feel rigorous. But think about what you’re actually testing. You’re testing whether someone recently crammed LeetCode. You’ve stripped away their IDE, their docs, their ability to Google something. You’ve removed every tool they’d use on the job and then judged them on the result. That’s not an interview. That’s hazing.

Brain teasers. “How many golf balls fit in a school bus?” If you’re still asking these in 2018, please stop. Google dropped them years ago after their own data showed zero correlation with job performance. Zero.

Trivia questions. “What’s the time complexity of HashMap.get() in Java?” Cool, they memorized it. Or they didn’t. Either way you’ve learned nothing about whether they can build software.

Massive take-home projects. I’ve seen companies send 8-hour assignments and call it “a small exercise.” You’re not testing skill. You’re filtering for people with no life outside work. Single parents, people with side commitments, anyone who values their free time – they just opt out. And you never even know what you missed.

What actually predicts performance

I’ve been iterating on our process at the fintech startup for a while now. Here’s what’s worked.

Give them a laptop and a real problem

This is the single biggest improvement we made. Instead of a whiteboard, we hand candidates a laptop with an IDE, internet access, and a small codebase. The task is something close to what they’d actually do on the job. Add a feature. Fix a bug. Review a pull request.

You learn so much more this way. How do they read unfamiliar code? Do they check edge cases? How do they use their tools? Do they ask good questions when stuck?

One of our best interview tasks is a broken API endpoint with a failing test. The candidate gets logs, the codebase, and 45 minutes. We’re not looking for a perfect fix. We’re watching how they think.

Pair with them

Pair programming sessions are gold. You pick a small problem, sit next to the candidate, and work on it together. Not as an examiner – as a collaborator.

This tells you things no other format can. How do they handle suggestions? Do they explain their thinking? Can they take feedback without getting defensive? These are the things that actually matter when you’re shipping code with a team.

Talk about what they’ve already built

For senior roles especially, I’ve started spending more time on deep dives into past work. Pick a system they built. Ask them to walk you through the architecture. Then start pulling threads. Why this database? What would you change? What broke in production?

Good engineers light up during these conversations. They remember the tradeoffs. They’ll tell you about the decision they regret. The ones who padded their resume get vague fast.

Use rubrics, not vibes

Early on at the fintech startup, our debriefs were a mess. “I liked her.” “He seemed smart.” “I don’t know, something felt off.” That’s not a hiring decision. That’s a gut check, and guts are biased.

Now every interviewer fills out a rubric before the debrief. Same questions, same scale. You write down specific evidence, not impressions. It’s not glamorous, but it’s the difference between a process and a coin flip.

Designing the loop

Keep it tight. Nobody needs a six-round interview for a backend role.

Here’s roughly what we do:

• Phone screen (30-45 min): Can this person communicate? Do they have the baseline?
• Work sample (60-90 min): Laptop, real problem, real tools.
• Deep dive (45 min): Walk me through something you built.
• Team fit (45 min): Values, collaboration style, how they handle disagreement.

For senior roles, swap the deep dive for a system design conversation. Let them drive. Ask about tradeoffs, not trivia.

Train your interviewers

This one’s overlooked constantly. Most engineers are terrible interviewers. Not because they’re bad people, but because nobody taught them. They default to whatever they experienced as a candidate, which was probably also bad.

At the fintech startup we started having new interviewers shadow experienced ones. We review rubrics together. We debrief on the debrief. It takes time, but the signal quality goes way up.

Candidate experience is your reputation

I can’t count how many times a candidate told me about a horrible interview experience at some other company. Ghosted after three rounds. Left waiting in a lobby for 40 minutes. Given a problem that had nothing to do with the role.

Every candidate who walks out of your office talks about it. To their friends, to their colleagues, sometimes on Glassdoor. At a startup where we’re competing with bigger names for talent, that reputation matters enormously.

Be clear about the process upfront. Respect their time. If you’re not making an offer, tell them why. It costs you nothing and it’s the right thing to do.

Watch out for these traps

Hiring for similarity. If your whole team went to the same three schools and thinks the same way, you don’t have a team. You have an echo chamber. Diverse panels, evidence-based decisions, focus on complementary strengths.

Credential worship. A degree from a top university tells you someone got into a top university. It doesn’t tell you they can debug a production outage at 2am or write code their teammates can actually read.

Letting one bad interview tank a candidate. Single data points are noisy. If four interviews went great and one was mediocre, look at the full picture. Maybe the interviewer had an off day. Maybe the question was bad. Aggregate the signal.

The actual point

Technical interviewing isn’t some unsolvable problem. It’s just that most companies copy what everyone else does without asking whether it works. Test real work. Use consistent evaluation. Treat candidates like humans. The bar isn’t that high, and yet most of our industry still can’t clear it.

Managers multiply through people. Tech leads multiply through systems. Pick based on what drains you least, not what sounds prestigious.

The fork nobody prepares you for

Every strong engineer eventually faces this question. Do you go into management, or do you stay technical and lead from there?

I’ve been on both sides of this at the fintech startup. When we were small, I did both. Ran architecture decisions, hired engineers, handled 1:1s, reviewed code. It was unsustainable. Once we grew past a handful of engineers, I had to pick. And more importantly, I had to figure out what each role actually demanded so we could hire and promote into them properly.

Here’s what I learned.

Side-by-side breakdown

That table is the short version. Let me expand on the parts that aren’t obvious.

What an engineering manager actually does

Most of the job is invisible. You’re clearing the path so your team can build. Hiring the right people, onboarding them fast, giving honest feedback, shielding the team from organizational noise. None of that shows up in a commit log.

At the fintech startup, I made a rule for myself: if I was writing production code as a manager, something was wrong. Either I hadn’t hired well enough, or I was clinging to the IC identity. Both are problems.

The trap is thinking management is a promotion from engineering. It’s not. It’s a career change. You stop building things and start building an environment. Completely different skill set. If you hate ambiguity, dislike repetitive conversations, or need the dopamine of shipping code daily — you will be miserable. I’ve seen good engineers become terrible managers because nobody told them this upfront.

What makes a great EM: you actually care about people’s careers. Not performatively. You enjoy the puzzle of team dynamics. You can sit in a room full of competing priorities and walk out with a plan everyone tolerates.

What a tech lead actually does

The tech lead owns the “how.” You decide the architecture, set coding standards, break ties on technical debates, and make sure the system doesn’t rot while the team ships features.

You still write code. That’s non-negotiable. A tech lead who stops coding loses credibility fast. But you also spend a surprising amount of time communicating. Explaining tradeoffs to product managers. Writing design documents. Mentoring junior engineers through code review. The ratio shifts — maybe 50% coding, 50% everything else — but the code stays.

The frustrating part? You’re accountable for the system but you don’t control the people building it. You can’t assign tasks or run performance reviews. You lead by influence, by being right often enough that people trust your judgment. If your ideas are bad, or if you can’t communicate why they’re good, you have nothing.

At the fintech startup, our tech leads owned specific domains. One person owned the data pipeline architecture. Another owned the API layer. Clear ownership, clear accountability. No committees.

How to choose

Forget the title. Look at how you spend your energy.

After a day of back-to-back 1:1s, are you energized or drained? After eight hours deep in a codebase, do you feel alive or lonely? The honest answer points you in the right direction.

Better yet — test it. Before you commit to either track, volunteer for the work. Mentor a junior engineer for a quarter. Run a sprint planning cycle. On the tech side, drive an RFC through to implementation. Own a migration. Lead a postmortem.

The title matters less than the work. If you’re doing the work and it fits, the title will follow.

The hybrid trap

We tried the “tech lead manager” thing at the fintech startup when the team was four people. I was doing both. It sort of worked until it didn’t. You end up being mediocre at two jobs instead of good at one. Skipping 1:1s because you’re deep in a debugging session. Skimping on code review because you have a hiring pipeline to manage.

If your company is small enough that one person must do both — fine, just know it’s temporary. Plan the split before you need it.

One more thing

Management isn’t a promotion. Tech lead isn’t a consolation prize. I’ve met directors who would’ve been happier as principal engineers and staff engineers who secretly wanted to run a team. The industry does a bad job of framing these as equal. They are.

You can switch tracks. People do it all the time. But switching costs something — you lose momentum, you rebuild credibility, and skills you don’t use will fade. So pick deliberately, try the work before you commit, and don’t let someone else’s career ladder define yours.

So I shut up, asked a few questions, and later that afternoon wrote a one-page doc outlining the bottleneck I saw. I included numbers from our existing traffic patterns. I proposed an alternative that reused most of their work. Two days later the team pivoted — not because I pulled rank, but because the problem was clear once I put it on paper.

That was the moment I understood what technical leadership without authority actually looks like. And honestly, it’s the only kind of leadership that sticks.

Credibility is earned in the boring moments

You don’t become the person people listen to by giving brilliant speeches. You become that person by being right about the small stuff consistently. Fixing the flaky test nobody wants to touch. Jumping on an incident at 2am and writing up the postmortem the next morning. Reviewing PRs with actual thought instead of rubber-stamping them.

At the fintech startup, I had to build credibility from zero. The team was sharp. They didn’t care about titles. What they cared about was whether you could help them solve hard problems without wasting their time. Fair enough.

I focused on a few areas where I knew my experience was strong — system design, infrastructure, and debugging production issues under pressure. I didn’t pretend to know the financial domain better than people who had been in fintech for years. When I was wrong, I said so. When I was unsure, I said that too. Turns out, admitting uncertainty is one of the fastest ways to build trust. People can smell posturing.

The real work is communication

Here is what nobody tells you about influence without authority: it’s 80% communication and 20% technical skill. You can be the best engineer in the room and still get nothing done if you can’t frame a problem in a way that makes people care.

I learned to always lead with the problem. Not my solution. The problem. If I walked into a discussion and said “we should switch to Kafka,” people pushed back instinctively. But if I said “we’re dropping 12% of events during peak load because our queue can’t keep up — here are the numbers from last Tuesday,” suddenly everyone wanted to talk about solutions. Same destination, completely different path.

Writing things down changed everything for me. At the fintech startup we were moving fast, and decisions got lost in Slack threads and hallway conversations. I started writing short proposals — a page, maybe two. Problem, context, recommendation, alternatives, tradeoffs. Nothing fancy. But it forced me to think clearly, and it gave people something to react to on their own time instead of in a high-pressure meeting. Half the arguments I avoided were arguments that never needed to happen in the first place.

Make other people better

The biggest unlock was realizing that my job wasn’t to be the smartest person on the team. My job was to make the team smarter. Pair with someone on a tricky migration. Share the context behind a design decision so the next person doesn’t have to reverse-engineer it. Fix the CI pipeline that wastes 20 minutes of everyone’s day.

These things aren’t glamorous. Nobody gives you a promotion for speeding up the build. But they compound. Every small improvement makes the team a little faster, a little less frustrated. And the people you helped? They remember. When you propose something ambitious later, they are the ones who back you up.

Start small, find allies

When I wanted to push a bigger initiative — say, rearchitecting a service that had become a bottleneck — I never started with a grand plan. I started with a focused prototype. Something I could build in a week that demonstrated the idea was viable. Early wins create momentum. A working demo is worth ten slide decks.

Then I found allies. One person pushing for change is easy to dismiss. Three people aligned on the same problem? That’s a movement. I would share early results with engineers I trusted, get their input, fold in their ideas. By the time the proposal reached a wider audience, it wasn’t just my thing. It was our thing.

The traps that get smart engineers

Being right and being effective are two different skills. I’ve watched brilliant engineers lose every argument because they treated disagreements as contests to win instead of problems to solve together. If you burn a relationship to win a technical debate, congratulations — you won the battle and lost the war. That person won’t support your next idea. Or the one after that.

Pick your battles. Not everything is worth fighting over. Some decisions are reversible and low-stakes, and spending political capital on them is a waste. Save your energy for the things that genuinely matter.

This is the job

I used to think leadership without authority was a stepping stone — something you did while waiting for the “real” leadership role. I was wrong. This is the real thing. The credibility you build, the communication habits you develop, the trust you earn — these are the foundations. If a title shows up later, great. You will be ready. If it doesn’t, you’re still the person who makes things happen. And every team needs that person more than they need another manager.

I’ve been building the engineering team at a mobility startup for the past several months. Shared mobility is still early. We’re pre-Lime, pre-Bird, pre-everything. The concept is unproven, the funding is modest, and the salary bands reflect that reality.

Every good candidate I talk to has at least one offer from a company that can pay 30-50% more than I can. Some of them have offers with stock grants that look like a second salary. I can’t match that. I learned early to stop pretending I could.

But we’ve still managed to hire well. Here is what actually worked.

Be honest about money on the first call

Nothing kills trust faster than dancing around compensation. I bring it up in the first conversation. “Here is what we can pay. Here is the equity. Here is what the equity is worth today, which isn’t much, and here is what it could be worth if we execute.” No hand-waving. No “competitive salary” language that means nothing.

Most engineers respect directness. The ones who are only optimizing for cash will self-select out, and that’s fine. The ones who stay in the conversation are evaluating the whole picture, and I want to talk to those people.

Show the work, not a pitch deck

At the mobility startup I started doing something that felt risky at first: I gave candidates access to our actual codebase during the interview process. Not all of it, but enough to see how we build. Our code reviews. Our deployment pipeline. Our monitoring setup. The real thing, not a sanitized version.

This did two things. First, it filtered for engineers who cared about craft. If someone looked at our setup and got excited about the problems, that told me more than any whiteboard exercise. Second, it made the job tangible. They weren’t imagining what the work might be. They could see it.

One engineer told me he accepted our offer over a much higher one because, and I’m quoting here, “your codebase looked like people gave a damn.” That stuck with me.

Sell speed, not “startup culture”

I never use the phrase startup culture in interviews. It means nothing. What I do talk about is speed. At the mobility startup, an engineer can go from idea to production in a day. Not because we skip process, but because our process is light and the team is small enough that decisions happen fast.

I tell candidates about specific examples. Last month one of our engineers noticed a pattern in user drop-offs, proposed a fix, built it, shipped it, and we saw the numbers move within 48 hours. At a big company that same change goes through three teams, two planning cycles, and a prioritization meeting. Maybe it ships in a quarter.

Speed isn’t about working more hours. It’s about fewer layers between you and the outcome. That’s genuinely compelling to a certain kind of engineer, and those are exactly the engineers I want.

Autonomy has to be real

Every startup claims to offer autonomy. Most of them mean “we don’t have enough managers yet.” That isn’t autonomy. That’s chaos.

Real autonomy means an engineer picks the approach, owns the tradeoffs, and lives with the consequences. At the mobility startup, our engineers choose their tools. They design their own systems. They are on call for what they build, which means they build things that don’t break at 3 AM.

When I interview, I’m specific about this. I describe a recent technical decision and who made it. Not me. The engineer closest to the problem. If a candidate has been stuck in an environment where every architecture choice needs three sign-offs, that story lands hard.

Hire for the team, not the role

I can’t afford specialists. What I can afford is sharp generalists who get better at everything by doing everything. At our size, an engineer might write a service, set up the monitoring, debug a production issue, and review someone else’s database migration in the same week.

Some people hate that. Others thrive on it. I screen for the second group by asking about the last time they worked outside their comfort zone and what they learned. The answers tell me whether someone wants range or just wants to go deeper on one thing. Neither is wrong, but only one fits where we’re right now.

The peer interview matters most

The single best recruiting tool I have is my existing team. When a candidate meets the people they would work with every day and those people are sharp, thoughtful, and honest about the hard parts of the job, that’s more persuasive than anything I can say.

I make sure candidates spend real time with the team. Not a panel interview. A working session or a design conversation. Something that feels like the actual job. If they click with the team, the salary gap shrinks in their mental math. If they don’t click, no amount of money would have made it work anyway.

What I got wrong early on

I wasted time in the beginning trying to compete on perks. Free lunches, flexible hours, the usual startup bingo card. None of it moved the needle. Engineers saw through it immediately.

What moved the needle was being specific and being honest. Specific about the problems we’re solving, the systems we’re building, and where we’re going. Honest about what is hard, what is broken, and what we haven’t figured out yet.

The best hires we’ve made came from conversations where I said something like, “Our deployment process isn’t great yet and you would own fixing it.” That kind of honesty attracts builders. Glossy pitches attract people who want to be at a company that sounds good, not people who want to do the work.

The uncomfortable truth

You will lose candidates to higher offers. It will happen regularly. Some of those candidates would have been great, and it will sting.

But the engineers who join you despite the lower salary are making a deliberate choice. They are choosing the work, the team, and the trajectory over the paycheck. From what I’ve seen, those people build better things and stay longer. Not always. But often enough that I’ve stopped trying to win the compensation game and started focusing on winning the “is this work worth doing” game instead.

That’s a game a startup can actually win.