Simple questions with hard answers: When code generation becomes cheap, what becomes expensive/rare to produce high quality software?
Lately the industry has been in a kind of low-grade panic: not the kind where anyone’s screaming/shouting, but the kind where everyone’s quietly aware that the ground has shifted. The old blueprints are gone. There is no shared playbook anymore for how groups of people are supposed to build software together. You know it is happening when ThoughtWorks is racing to name new methodologies. And I do believe it eventually will find its center of gravity (right or wrong), it will be sold by large/small consultants, and everyone will go back to either agreeing or disagreeing, modifying or embracing it wholly… But until then, I think we are kind of in a gray zone, fog.
In a Sisyphean attempt to build the best team to build Integral through this fog, I have conducted 100+ engineering interviews over the past year. I asked nearly everyone the same core questions, that I have carefully collected, and curated over the past years.
Out of these, three questions consistently separated good candidates from exceptional ones for me. Not because of correct/wrong answers, but what the following conversations revealed how they think, grow, and operate as engineers.
As models makes technical skills more accessible, I argue that these behavioral signals matter more. You can teach someone how to create plans, implement and test them. You cannot easily teach someone to be coachable, self-aware, and accountable.
1. “What’s the best feedback you’ve ever received?”
What I’m actually asking
Can you distinguish between praise and developmental feedback? Have you been properly coached/managed in the past? Are you self-aware enough to recognize and articulate your edges?
The pattern I see
Most candidates immediately recall praise: “My manager said I was the best developer on the team” or “I got recognition for shipping the project ahead of schedule.”
That’s not feedback. That’s a compliment.
The answers that catch my attention sound more like this:
- “My tech lead told me I was solving the right problems but making them harder for others to maintain. That changed how I think about code ownership.”
- “A peer pointed out that I dominate design discussions. I didn’t realize I was shutting people down. I’ve been working on that for two years.”
- “Someone told me I optimize for being right instead of being effective. Still thinking about that one.”
These answers reveal something crucial: the candidate has worked with people who cared enough to coach them, and they were capable of receiving it.
Both matter. Some candidates actively seek feedback. Others receive it when offered. Both are green flags. What matters is whether they can articulate what they learned and how they changed.
This question also opens doors. Based on their answer, I can ask deeper questions about how much they’ve thought about their own patterns and growth edges.
2. “Who are the best engineers you’ve worked with, and why?”
What I’m actually asking
What do you actually value in engineering excellence? Can you articulate what makes someone great beyond technical chops?
The pattern I see
Mediocre answers cluster around surface-level traits:
- “They’re a 10x developer”
- “Super fast coder”
- “Really detail-oriented”
- “Knows every algorithm”
These aren’t bad qualities, but they’re incomplete. They focus on individual output rather than team impact.
The answers that stop me sound different:
- “She had this way of making the whole team better, which took me 2 years to understand. When she reviewed code, you actually learned something.”
- “He was the person everyone went to when stuck—not because he gave you the answer, but because he asked questions that helped you find it.”
- “She could hold really strong technical opinions while staying genuinely open to being wrong. Made every design discussion better.”
- “He was calm, which makes everything slow down in a good way. I just realized what he was doing when he was no longer there.”
Why it matters
When candidates describe what makes someone else great, they’re often describing what they value or aspire to be. Sometimes what they already are but don’t recognize in themselves.
Engineers who notice individual heroics tend to optimize for individual heroics. Engineers who notice multipliers tend to become multipliers.
Here’s something I keep thinking about: if you don’t know what good looks like, you work with approximations. And approximations are never good.
Working alongside excellent engineers gives you a calibrated sense of excellence that reading or watching videos cannot provide. Proximity to quality is irreplaceable. This slightly advantages engineers who have worked with genuinely good people.
I don’t see this as unfair. It’s just observable. If a candidate has had that exposure, it’s a strong signal. If they haven’t, it doesn’t disqualify them. But the way they talk about excellence still reveals what they value.
3. “What’s the biggest crisis you’ve managed?”
What I’m actually asking
How do you behave when things go sideways? What level of responsibility do you hold in tough times? What do you even consider a crisis?
The pattern I see
Everyone has success stories. Everyone can talk about the system they scaled, the feature they shipped, the architecture they improved.
Few people shine when describing their worst day.
Weak answers deflect or minimize:
- “I haven’t really had any major crises”
- “There was this outage, but it wasn’t really my fault”
- “We had this bug, but the PM should have caught it in review”
Strong answers lean into it:
- “I pushed a trivial but necessary change that took down checkout for 45 minutes during Black Friday. Here’s what I learned about deployment and incident communication…”
- “I made an architectural decision that locked us into a vendor we couldn’t escape. Goog on paper, nasty on the long term. Here’s how I navigated the team through the migration…”
- “I underestimated a project by 3 months, missed a critical deadline, and had to rebuild trust with the business. Here’s what changed in how I plan…”
Why it matters
Everyone fails. Not everyone takes ownership, and ride the failure. Most sink with the failure, find some well reasoned excuses.
Crisis reveals character. The engineers who can clearly articulate their worst moments, without blame-shifting or minimizing, are the ones who learn from failure. They get better.
These are the people you want when your production system catches fire at 2am.
Why These Questions Matter
Eventually the fog will clear and the panic will die. One or two ways of working (frameworks, orchestration, AGI.,..) will win out, get branded, get sold (and they will be overadopted with great enthusiasm by the Nokias of this era—companies that applied the playbook to the letter and still got left behind). Until then, the teams that move are the ones that don’t wait for a playbook, mass adoptation or need any virtue signaling. They build their own frameworks as much as they need, their own tools, and they ship.
These three questions help me find the people who can do that: the ones who move in the fog, enjoy it, and still deliver. They invent, give/hear the feedback, get into crisis and make it to the other side. If you’re building a team in the same fog, these three might be worth stealing.