Most recruiting processes start the same way: the client sends a job description, the recruiter starts sourcing, and the first candidates show up in two weeks.
The problem with this sequence is that it skips the most important step. And skipping it is why so many searches take longer than they should, produce candidates that don't fit, and end with someone hired who doesn't work out in the first year.
Before we source a single person, we run a diagnostic. It takes time we don't bill for. It slows the start of sourcing by a week or two. And it's the thing most responsible for the searches that close well.
What the diagnostic actually is
It's not complicated. It's a structured conversation — usually 60 to 90 minutes — with the people who will actually evaluate candidates and make the hire. Not just the recruiter who opened the req. The engineering lead, the hiring manager, and whenever possible, someone from the team the person will join.
The goal is to answer a specific set of questions that most job descriptions leave undefined:
What does "good" look like at 90 days? Not the laundry list of requirements. What specific things should this person have done, built, or changed in their first three months for the hire to be considered successful? If the people in the room give different answers to this question, you have a problem that sourcing won't solve.
What does the work actually look like day to day? What will the person do on a Tuesday at 3pm? Who do they talk to? What systems do they touch?
What's the team context? Seniority on paper is meaningless without knowing what seniority means in this specific team. A senior engineer joining a team of staff+ engineers is in a different role than a senior engineer who will be the most experienced person in the room.
What are the real constraints? Timeline, budget, must-haves versus nice-to-haves, deal-breakers. I've had clients spend 45 minutes describing the technical requirements in detail and then mention at the end that the role is office-based in Buenos Aires three days a week. That's not a footnote. That eliminates 80% of the people we were going to source.
Where did previous searches for this role fail? This one is underused. If the company has tried to hire for this role before, the patterns in those failures tell you more than any requirements list.
What comes out of it
At the end of the diagnostic, we produce a written brief. Not the job description — the brief is an internal document, two to three pages, that captures what we learned and how it translates into the search.
It defines: the specific seniority level with concrete examples, the technical bar with must-haves separated from wants, the working style requirements, the compensation range calibrated to current market rates, the interview process and who owns each stage, and the red flags that would disqualify an otherwise strong candidate.
We share this brief with the client. If they read it and say "that's not quite right," we talk about why. That conversation, before sourcing starts, is worth more than any amount of sourcing done against a vague brief.
Why this step gets skipped
The honest answer is that it costs time and it doesn't feel like output. Clients who are hiring urgently want to see candidates fast. A firm that starts sending profiles in week one feels like it's moving. A firm that asks for a 90-minute call before it starts anything feels like it's creating friction.
The firms that skip the diagnostic can send profiles faster. They just send more wrong ones. The client spends three weeks interviewing candidates who aren't quite right, adjusts the brief informally based on the rejections, and eventually the right person appears. By the time they're hired, the process has taken longer than a well-briefed search would have.
The organizational psychology angle
My background is in organizational psychology, which shapes how I think about this. A job description is a behavioral expectation document. When it's written well, it describes what a person needs to do, how they need to interact, and what outcomes they're responsible for. Most of them aren't written well.
The diagnostic is a structured process to extract the behavioral expectations that the job description didn't capture. Not the technical requirements — those are usually fine. The working style, the cultural fit, the team dynamics, the decision-making model.
In 17 years of technical recruiting, most early exits — the hires that are gone by month six — were not failures of technical assessment. The person could code. They couldn't communicate the way the team needed them to communicate. Or they needed more structure than the role provided. Or the role scope changed two months in and they weren't built for ambiguity. These mismatches are predictable before the hire is made if you ask the right questions.
What clients can do before calling us
If you're considering a technical search in Argentina and want to start the diagnostic work before engaging a firm, these are the questions worth answering internally:
- What does success look like at 90 days? Write it down in three specific sentences.
- What is the actual technical environment — scale, stack, team size, development process?
- What budget have we set, and is it current with 2025 market rates?
- Have we tried to hire for this role before? What happened?
- Who in our organization will interview, and what is each person's role in the decision?
If those answers are clear before the first conversation with a recruiter, the search will be faster. If they're not clear, that's what the diagnostic is there to figure out.
Sources: Bondy Group internal methodology and placement data (2008–present). SHRM cost-of-failed-hire estimates (1.5–2x annual salary). Organizational psychology literature on behavioral expectation frameworks (foundational to Bondy's diagnostic approach, drawing on Mara Schmitman's background at UdeSA).