There's a pattern we see consistently in how engineering hiring processes go wrong. It's not in the interview rubric. It's not in the sourcing channel. It starts the moment a hiring manager opens a stack of resumes before they've clearly defined what they're actually evaluating for.
I spent five years in recruiting operations at technical companies before Fonzi. In that time I watched hundreds of screening sessions. The ones that produced good hires, consistently, started with clarity about the role before the first resume was touched. The ones that produced churn, mismatches, and rehires almost always involved a hiring manager who had an intuitive idea of what they wanted but hadn't made it explicit.
Clarity at the start isn't about writing a better job description. It's about answering five specific questions for yourself before you evaluate anyone against anything.
Question One: What Does This Role Actually Need to Do in the First 90 Days?
Not "what do we want this person to do long-term." Not the list of responsibilities from the JD. The specific, concrete work output you need in the first three months.
If you can't name three to five deliverables for the first quarter, you don't have a clear enough role definition to evaluate candidates accurately. You'll evaluate against a vague set of impressions, and you'll weight credentials and interview confidence more than actual output fit.
A useful answer to this question sounds like: "Debug and stabilize our payment processing service before Black Friday, document what we find, and have a proposal for the architectural changes we'll need next year." An unusable answer sounds like: "Own the backend infrastructure and be a strong technical contributor."
The 90-day frame forces specificity. It also tells you what technical skills are actually required now versus what are nice-to-haves you'd want in year two.
Question Two: What Does the Team's Working Environment Actually Look Like?
Not the version you'd put in a job posting. The real version.
How synchronous is the day-to-day? How fast does Slack move? How are technical decisions made and documented? What's the ratio of planned work to interrupt-driven work? Is the codebase in reasonable shape or are there substantial technical debt pockets the new person will hit early?
This matters because working environment is one of the strongest predictors of early performance and retention. An engineer who does their best work in a structured sprint environment with solid documentation will struggle in a fast-moving, under-documented startup context, regardless of their technical level. The reverse is also true. Neither person is a bad engineer. They're badly matched to the environment.
If you don't have an honest picture of your own working environment before you screen, you'll hire based on credentials and interview performance and wonder why the person underperformed in practice.
Question Three: What Technical Depth Is Non-Negotiable Versus Learnable in This Role?
Most hiring managers conflate these two categories. They list every technical requirement as if it's equally critical, which makes sourcing imprecise and screening inconsistent.
The question to answer is: which skills does this person need on day one to be useful, and which could a strong candidate learn within a reasonable onboarding window? If you're hiring a backend engineer to work on a Go codebase, is Go fluency required or can you onboard someone who knows Rust well and will pick it up quickly? If you're hiring a data engineer who'll work with your specific dbt and BigQuery setup, do they need to know both on arrival or just know the concepts?
The reason this matters for screening is that it changes what you're looking for in a resume and what you ask about in a screen call. It also changes the size of your qualified candidate pool meaningfully. Hiring managers who treat everything as a hard requirement often screen out strong candidates who could ramp into the role in four weeks while admitting weaker candidates who happen to have the right keywords.
Question Four: What Broke with the Last Person in This Role (or the Last Comparable Hire)?
This is the question most hiring managers skip, especially if the departure was uncomfortable. It's the most valuable one.
Every broken hire has a failure mode. Sometimes it's technical skill mismatch. More often it's working style or communication cadence or expectations about scope. If you can name the failure mode clearly, you can design your evaluation to detect it. If you can't name it, you may hire the same pattern again.
A useful answer sounds like: "The previous backend engineer we hired was technically strong but struggled with ambiguity. We give a lot of latitude in how problems get solved and they needed more direction than we were able to provide. We want someone who defaults to figuring it out before escalating." That's a specific signal to look for in the screen. It changes how you interpret answers to behavioral questions.
We're not saying every departure reflects a bad hire. People leave for good reasons. But if the departure involved performance or fit issues, the hiring manager who can name the pattern specifically is going to make a better next hire than one who says "it just didn't work out."
Question Five: Who on the Team Will This Person Work With Most Closely, and What Is That Person Like?
Team fit isn't an abstract thing. It's usually mediated by one or two close working relationships. The engineer who will sit next to this person in standups and do code reviews with them and ask for help when things break defines the actual working context more than the team culture statement does.
If you can name the person and describe their working style honestly, you can evaluate whether a candidate's communication patterns are likely to mesh well. If you have a senior engineer who moves fast, writes terse tickets, and expects people to ask questions, you probably don't want to hire someone who needs detailed written specifications and gets anxious when requirements are underwritten.
This doesn't mean the team's lead engineer should be the default filter. It means their working style is part of the environment you're hiring into, and pretending it isn't leads to mismatches that wouldn't have happened if you'd been honest with yourself earlier.
What Happens When You Skip These Questions
The failure mode isn't that you make a bad hire. It's that you make a mismatched hire that looks fine through most of the interview process. The technical level checks out. The candidate says the right things in the culture interview. The team likes them. Three months in, something is off. The person is slower to ramp than expected, or creates friction in how they communicate, or is strong in areas that aren't the priority and weak in areas that are.
None of that was visible at screen because the evaluator didn't know precisely what they were evaluating for.
What we've built in Fonzi's role setup flow is a structured way to surface these questions before matching begins. The matching is only as useful as the role profile underneath it. We've found that hiring managers who complete a detailed role profile screen fewer candidates and advance stronger ones, not because the matching is magic, but because they go into screening with clarity rather than impressions. That clarity is worth more than any algorithmic shortlist.
