The first piece in this series, Hiring for Culture First, argued that behavioral archetype, how someone handles conflict, ambiguity, and pressure, matters more in hiring than skill, because skill is teachable and type mostly isn’t. That argument holds, but it was making a narrower claim than “culture” usually means, and it’s worth being explicit about what it left out.

Archetype is compositional. Every one of the ten patterns in that piece has a real strength and a real cost, and the job of a leader is to balance them, not eliminate the ones with edges. There’s a defensible case for keeping an Operator on the team even though Operators accumulate debt. There’s no defensible case for hiring someone who can’t admit they were wrong.

That second category isn’t an archetype. It’s a threshold, the same handful of things you screen for in every candidate, regardless of which of the ten patterns they lean into. Clear the threshold and archetype tells you where they fit. Miss it, and no composition of archetypes saves you. A team of perfectly balanced types who can’t update their own thinking just gets the wrong answer more efficiently.

Patrick Lencioni covered a version of this ground in The Ideal Team Player: humble, hungry, smart. That’s a good general framework and worth reading. What follows here is narrower and more specific to engineering, four traits that show up constantly in code review, incident response, and design discussion, and that predict more about long-term value than almost anything on a resume.

Curiosity

In engineering specifically, curiosity is the instinct to keep asking why past the point where the immediate problem is solved. It’s what turns a patched symptom into a found root cause, and it’s the difference between someone who uses a tool and someone who understands what the tool is actually doing underneath.

It’s also become the precondition for something new: verifying AI output instead of rubber-stamping it. An engineer reviewing a pull request an AI generated has no built-in signal that says “wait, why did it choose this approach, what happens at the edge case it didn’t show me” unless curiosity is already their default mode. Accountability for what ships is supposed to sit with the engineer, not the model, but that only means something if the engineer is curious enough to actually interrogate the output instead of accepting whatever looks plausible.

Without it, technical experience has a shelf life. Five years of repeating the first year’s habits looks like five years of experience on a resume and isn’t. The tools and the paradigms move constantly in this field in a way they don’t in most professions, and an incurious engineer’s skill quietly decays even while they stay in the same job. Curiosity also isn’t independent of archetype. A curious Operator still ships fast, but keeps asking why afterward, closing the gap the Operator archetype is prone to leaving open. An incurious Operator just moves to the next fire. Same archetype, very different value, and archetype alone won’t catch the difference.

How to test for it: Ask about a complex project they built, and press on why they chose a specific technology, especially one where you know something newer or arguably better exists. Don’t accept the first answer, pressure test whether they actually went and investigated the alternatives given their constraints, or just defaulted to what they already knew. A curious engineer can walk you through what they considered and why the tradeoffs under their specific limitations ruled the alternative out. An incurious one either hasn’t heard of the alternative or has a thin, generic answer for skipping it.

Growth mindset, or coachability

The willingness to actually update behavior after feedback, not just nod at it. Coachable engineers get measurably better across a career. Uncoachable ones plateau at whatever level they were at when they stopped being able to hear a correction as information instead of an attack.

Without it, code review becomes a negotiation instead of a signal. Every note gets relitigated, every correction gets a justification instead of an adjustment, and the people reviewing their work eventually stop bothering, which is a worse outcome than the original mistake ever was.

It also shows up in how someone treats a blocker that isn’t their fault. A database migration is taking longer than expected. UI assets aren’t ready. The work in front of them stalls on something outside their control. Without growth mindset, the response is to sit there blocked, or quietly switch to something else and wait it out. With it, the blocker becomes a problem worth solving in its own right, not just something to wait past. They look for a way around it now, and just as often, a way to make sure the same class of stall doesn’t happen to the next person.

How to test for it: Ask for a strength and a weakness. It’s a cliché question, and that’s fine, the value isn’t in the question, it’s in what you’re listening for. What you want is for them to recognize, on their own or with a nudge, that their greatest strength and their greatest weakness are usually the same trait. Someone with a bias for action gets things done fast, doesn’t need to be told twice, operates with real urgency. That same trait leaves people behind, because they’re several steps ahead of everyone else, and their communication gets thinner, since less time went into making it clear. If they can’t get there on their own, prompt them: what does that strength cost the people around you when it’s running unchecked. Then ask about a time they were blocked by something outside their control, a dependency, another team, a slow process, and what they actually did about it. A weak answer describes the wait, or a quiet pivot to other work with no mention of the blocker again. A strong answer includes what they did to get unblocked in the moment, and separately, what they changed afterward so the same class of blocker was less likely to hit the next person. This is the same duality part one built the whole archetype framework on, a strength and its cost are one trait seen from two angles, not two separate things. Growth mindset is whether someone can see both angles about themselves, not just the flattering one, and whether they have anything resembling a way to catch it before it costs someone else.

Empathy

This isn’t about being nice, even though it tends to look like it from the outside. It’s the capacity to actually understand a position from someone else’s point of view, accurately enough to explain it back, not just agree they’re allowed to have it. In a room, it shows up as someone who can walk in with a strong, well-researched opinion of their own and still sit quietly enough to really listen, taking in what’s said and pressure-testing it against their own view in real time, instead of spending the listening time rehearsing the rebuttal.

Without it, a room doesn’t get an honest exchange, it gets two prepared positions delivered past each other. Someone who can’t do this either steamrolls, their view wins by persistence rather than by surviving contact with a real counterargument, or looks like they’re listening while visibly just waiting for their turn, and the tell is that their response restates the same point instead of engaging with what was actually said. This is also what separates a calibrated Challenger from an uncalibrated one in part one. The calibrated version has usually done this work before they open their mouth.

How to test for it: Give them a real, defensible position of your own, one that’s different from the approach they’d probably choose, in a live discussion. Before they respond, ask them to restate your position back to you, in your terms. Someone actually listening can do this accurately and briefly. Someone who’s been waiting for their turn produces a thinner, distorted version, or quietly restates their own point with your position’s name attached to it. Then watch what their real response does with it, whether it engages the specific reasoning you gave, or reverts to the argument they walked in with, unchanged by anything you said.

Integrity under pressure

Whether someone tells you the true thing when it costs them something, not whether they’re pleasant to be in a room with. Niceness and integrity aren’t the same trait, and hiring for the first while thinking you’re hiring for the second is how teams end up with agreeable people who quietly let bad decisions ride.

Without it, small omissions compound. The bug that’s inconvenient to report gets fixed quietly instead of flagged. Credit that belongs to someone else gets kept because nobody’s counting. None of these show up as a single bad decision. They show up as a slow erosion of whether anyone can actually trust what a person tells them, which is expensive to rebuild and almost impossible to test for after the fact.

It also shows up in whether you can depend on them once the terms change. Scope shifts, a constraint they didn’t know about shows up, the approach they agreed to stops making sense halfway through. Someone with integrity comes back and checks in, here’s what changed, here’s what I think we should do about it, before they act on their own read of the situation. Someone without it just does whatever they’ve decided is right and tells you after, if at all. This is the same failure mode as the Cowboy in part one, just showing up at the threshold level instead of the archetype level. An agreement isn’t a suggestion, and quietly renegotiating it by yourself, without looping in the person who’s counting on you, is its own kind of dishonesty even when the outcome turns out fine.

How to test for it: Ask about a time they found a real problem that was inconvenient to report, close to a deadline, embarrassing, easy to quietly fix and never mention. What they actually did, not what they’d do hypothetically, is the signal. Then ask about a time the terms of a project changed on them mid-stream, a scope cut, a new constraint, a deadline moved, and what they did next. The weak answer is that they adjusted on their own and moved forward without looping anyone in, especially if the outcome was fine, that often gets described as a strength instead of the risk it actually is. The strong answer includes going back to whoever was depending on the original agreement and re-confirming before acting on the new read. The specificity is the tell, same as everywhere else in this series. A real instance has a name, a date, a consequence. A philosophy about honesty doesn’t.

Both questions, in order

These four traits and the ten archetypes from part one aren’t answering the same question, and hiring processes that collapse them into one interview loop tend to get both wrong. The threshold traits are a gate: does this person tell the truth, take feedback, stay curious enough to keep learning, actually hear someone else’s point of view. Archetype is a composition question: given that they clear the gate, which of the ten patterns are they, and does the team already have too much of it.

Ask them in the wrong order and you’ll talk yourself into hiring a well-calibrated Architect who can’t take feedback, because the technical interview went well and the culture conversation was an afterthought bolted onto the end of the day, exactly the failure mode part one opened with. Ask them in the right order, threshold first, archetype second, and you get a team that’s honest with itself and balanced in how it operates. Either piece alone gets you half a team.

The interview runs both ways

There’s a second thing happening in every interview described across these two pieces, and it’s worth naming directly instead of leaving it implied. A hiring process doesn’t just extract information from a candidate. It hands them information back. The questions you ask, and the ones you don’t bother asking, tell a candidate what you actually value before they’ve signed anything.

A loop that only tests whether someone can produce is telling them, honestly, that production is what they’ll be valued for once they’re inside. A loop that also tests how someone handles disagreement, whether they can be trusted when the terms change, whether they’ll get taught instead of just corrected, is telling them something different: that they’ll be treated as a person doing the work, not just a source of the work itself. Candidates read this. The good ones read it especially closely, because they’ve usually already worked somewhere that only asked the first question.

None of this is an argument for being soft in an interview. Everything in this series is built around asking harder, more specific questions than most loops bother with. It’s an argument for being honest about what the difficulty is actually measuring. Pressure-testing someone’s judgment, their honesty, their capacity to hear a hard truth and stay in the room, is not the same thing as grinding them down to see what breaks. The first is what a company does when it plans to treat you like a person worth understanding. The second is what a company does when it’s already decided you’re a resource to be used up. The process is the first real data a candidate gets about which one they’re walking into.