When I was building candidate-matching pipelines at developer platforms, the most persistent gap in every system I worked on was the same one: we could match on skills reasonably well, but we had almost no good signal on whether a candidate would work well with a specific team. Not values, not culture fit in the abstract sense. Specifically: how they worked day-to-day, and whether that matched how the people they'd be working with operated.
Culture-fit interviews try to fill this gap by asking about values. How do you handle conflict? What does ownership mean to you? Describe your ideal working environment. These questions aren't useless. They reveal something. But I've watched enough hiring data to be pretty confident that values-interview signal is a weaker predictor of retention and team performance than working-style signal. Here's what I've seen and why I think it matters for how teams hire.
What Values Interviews Actually Measure
A well-designed culture or values interview measures how someone thinks and talks about work, and whether that maps to the values the company publicly holds. These are not nothing. An engineer who thinks carefully about their own patterns and can articulate them is probably more self-aware than one who can't. Values alignment with the company's stated principles is correlated with other good things.
But values interviews are declarative assessments. The candidate tells you what they believe, in a setting where they know they're being evaluated. What they tell you is a mix of genuine belief and presentation-optimized self-description. The stronger a candidate is at the interview layer, the harder it is to separate these two things.
More importantly, what someone believes about ownership or collaboration or quality standards doesn't tell you how they actually behave when they're blocked at 4pm with a deploy broken in production and three people waiting on them. Behavior under pressure is a working-style question, not a values question. And it's the behavior that teammates experience day-to-day.
What Working Style Is and Why It Shows Up Fast
Working style is the set of habitual behaviors that characterize how someone does their work: how they communicate when they're blocked, how they handle ambiguous requirements, how frequently they check in versus go heads-down, how they manage their own time relative to team commitments, and how they behave when priorities conflict.
These patterns are largely stable across contexts. An engineer who defaults to asking questions before starting work will do that regardless of the team's stated documentation culture. An engineer who processes problems by talking them through will create pressure toward synchronous communication even on an async-first team. These aren't character flaws. They're stable behavioral tendencies that either match or don't match the specific team environment they're walking into.
The reason working style predicts retention better than values is that mismatches surface quickly. A values misalignment might take six months to become visible. A working-style mismatch is often apparent to the immediate team within the first sprint. Someone who needs tight specification before writing code creates friction in a team that runs on loosely-scoped tickets and expects engineers to drive clarity themselves. That friction is daily and concrete, not periodic and abstract.
Three Working-Style Dimensions That Matter Most for Engineering Teams
Based on what I've observed in building Fonzi's matching layer, three dimensions explain most of the working-style compatibility signal.
The first is communication frequency and modality preference. This ranges roughly from engineers who prefer single focused blocks of async communication (morning Slack, long resolved threads) to engineers who prefer real-time synchronous exchange (short check-ins, quick calls, high-cadence DMs). Neither end of this spectrum is better. A mismatch in preference is genuinely disruptive.
The second is ambiguity tolerance in requirements. Some engineers need clear specification before they write code and will produce better output with it. Others move comfortably on partial information, make reasonable assumptions, and validate asynchronously. Early-stage and fast-moving teams often need the second type. Teams with established processes and detailed ticket hygiene can accommodate the first. Putting the wrong type into the wrong context creates frustration on both sides.
The third is escalation threshold. When an engineer is stuck, how long do they try to solve it independently before asking? How do they decide when to escalate and who they escalate to? On a small team, an engineer with a very low escalation threshold can create significant coordination overhead. An engineer with a very high escalation threshold can disappear into a problem for two days when a 15-minute conversation would have resolved it. The right threshold varies by team structure and the availability of senior engineers to absorb escalations.
How to Actually Surface Working-Style Signal in an Interview
The working-style questions that produce useful signal are behavioral and specific. They ask about past behavior in concrete situations, not hypothetical preferences.
For communication patterns: "Tell me about a project where you were collaborating with engineers in different time zones. How did you stay coordinated day-to-day? What worked and what didn't?" The answer should reveal actual practices, not stated preferences. Look for specificity about tools, cadence, and what actually happened when coordination broke down.
For ambiguity tolerance: "Walk me through the last time you started on a feature where the requirements were genuinely unclear. What did you do first?" An engineer with high ambiguity tolerance will describe making reasonable assumptions, moving forward, and validating. An engineer with lower tolerance will describe asking multiple clarifying questions, possibly waiting, and then proceeding once they had clarity. Both patterns are valid. You want to know which one you're getting.
For escalation behavior: "Describe a time when you were blocked on something technical for more than two days. What did you try and when did you escalate?" The range of answers here is wide and revealing. Some candidates escalated immediately and collaboratively resolved it. Some spent a week in isolation before asking. Some never escalated and worked around the problem in a way that created downstream issues. The pattern tells you something that no values question will surface.
The Matching Problem
What makes working-style matching genuinely hard is that you need signal on both sides. You need to know the candidate's working patterns and you need to know the team's working environment. Most hiring processes get some signal on the candidate and almost none on the team context. The job description describes desired attributes, not actual working patterns. The hiring manager often has an implicit model of what the team is like that they haven't made explicit.
At Fonzi, we've structured the role intake process specifically to surface the team's working-style profile before matching begins. What are the team's actual communication patterns? How is work scoped and handed off? What's the escalation culture? This isn't about writing a better JD. It's about having a real model of the environment so that working-style signals from the candidate can be compared against something concrete.
Values-based culture fit screening isn't going away, and it shouldn't. But if you're a small team making a hire that will affect everyone's day-to-day for the next two years, working style should carry at least as much weight in your evaluation as values alignment. It predicts the experience that actually happens, not the culture the company aspires to have.
