Lessons from Google. From JD to Offer: Building a Direct Sourcing Engine for Japan's Engineering Market

Around 2014, Google Maps Japan needed to build out an iOS engineering team. I was the recruiter. My manager said, "Jordan, go hire us the iOS team." And I said sure. Yeah, let's do this.

I had not looked at the market. I had not asked what the actual talent pool looked like for iOS engineers in Japan at that point in time. Objective-C was still relatively niche. The engineers who had those skills were mostly self-taught frontend builders, people who learned by building apps, not by going through computer science programs. And then I went and submitted them into Google's standard engineering interview process, which had been designed for search infrastructure engineers. C++. Systems design. Algorithms. A hiring committee made up entirely of machine learning and backend engineers who had no context for what a good mobile engineer looked like.

Everyone got rejected. Not because they were bad. Because the process was built for someone else.

By the time I figured out what was happening, I had burned through most of the available candidate pool in Japan. The people who could have been great hires had already been through Google's process, gotten a rejection, and were now off the table. I was looking at this situation thinking, I was gonna fail from the beginning and I didn't even know it.

That experience, and a lot of others like it over a bit more than seven years at Google, is where most of what I know about engineering hiring in Japan actually came from. Not from theory. From destroying my own pipeline and having to figure out what went wrong.

Map the market before you open your mouth

The most dangerous thing a recruiter can do in Japan is say yes before they know what they're saying yes to.

Japan is not a big-pool market. For a niche engineering role, especially anything requiring bilingual ability on top of a specific technical skill, you might be looking at a total addressable pool of fewer than 100 people in the entire country. Sometimes fewer than 20. I've been in situations where I realized, in hindsight, there were maybe 10 or 20 people who could have filled a role I'd committed to filling.

When you're operating in a pool that small, there is no margin for false starts. Every candidate you send through a broken process, and reject, is a permanent reduction of your viable pipeline. You can't go back to them a month later. You can't pretend it didn't happen. You burned it.

So before you agree to headcount, before you promise a hiring manager that yes, you can find them this person, map the market. How many people actually exist who could fill this role? What's your realistic response rate going to be? What's your realistic pass-through rate at each interview stage? What's your offer acceptance rate? If there are a thousand people in the market, and your email response rate is ten percent, you now have a hundred candidates who will actually engage with you. Apply your conversion rates from there, and you can show a hiring manager, in numbers, before any sourcing begins, exactly how constrained the situation is and what needs to be true for the hire to happen.

That conversation changes everything. Because instead of coming back three weeks later with twenty candidates and having the hiring manager say "none of these are right," you're sitting down before any of that and saying: here's the reality. Here's what the market can actually give us. How do you want to approach it?

The same thing happened with Google Cloud Japan in the early cloud days. We needed solution architects who spoke English. The only people in the market with cloud architecture experience were at Microsoft and Amazon. And nobody spoke fluent English. Google's requirement was fluency in English. Nobody had the conversation upfront to say those two things cannot coexist in this market. We missed the numbers. We didn't fix it until we changed the requirement. We could have had that conversation in week one.

Right talent vs. strongest talent, they're not the same thing

Hiring managers almost always describe what they need in terms of the strongest possible engineer. That makes sense from their perspective. But "strongest" is relative to something, and if that something is not the actual job, you'll spend months rejecting the right people.

Google's bar for a strong engineer, master's degree, C++, algorithms, systems design, was genuinely appropriate for search infrastructure. It was completely wrong for an iOS engineer building a consumer maps application. The interviewers evaluating my candidates were sometimes search and machine learning engineers. They didn't know how to evaluate a good iOS engineer. So they often rejected them. Because they couldn't solve a systems design problem that had nothing to do with the scale they wanted iOS devs.

The way to get ahead of this is simple, but you have to do it before sourcing starts. Ask the hiring manager: what does success look like in six months for this person? What are they actually going to be working on? What are their OKRs? What does a sprint look like for them? Once you have specific answers to those questions, you have something concrete to come back to when the process is producing false negatives. You can say: you told me this person needs to build X. This candidate can build X. Why are we rejecting them? You can also correct the broken process by saying, how do we evaluate them.

It's uncomfortable. But it's the only way to stop building processes that systematically reject the people you actually need.

False negatives will kill you in a small market

A false negative is when your process rejects someone who would have been a great hire. In a big market like Silicon Valley for example, you can absorb that. In Japan, you can't.

There are a few common causes. Wrong evaluation framework for the role, that's the iOS story. But there's another one that doesn't get talked about enough: candidates who don't know what they're walking into.

When I was at Google preparing for the Stadia launch, this was Google's take on gaming, we were trying to hire engineers from big players in the gaming industry, and major game studios. The question a candidate from one of those companies is asking is: why would I leave a real game company to go to Google to build games? It's actually a weird pitch. Google is not a game company. So I spent weeks building a candidate preparation guide. What's the mission? Why does this matter? Who's on the team? What does the interview process look like? What are we actually building?

Some hiring managers may push back on this. "Aren't we giving them too much? Isn't that like cheating?" And my answer was always: if your interview questions are good, it doesn't matter. What preparation does is reduce the number of qualified candidates who underperform because they were anxious, confused, or didn't know what was being assessed. You're reducing false negatives. That is the point.

Build the EVP for the role, not just the company

Every candidate you're doing outbound to is silently asking one question: what's in it for me? Not the company pitch. Not why Google is great or why McKinsey is a prestigious firm. Why should this specific engineer want this specific job?

That answer has to be ready before you send a single message. And it has to be specific. An engineer is not motivated by the same things as a salesperson. A researcher is not thinking about the same things as a Technical Program Manager (TPM). If your outreach reads like a company announcement, most people will ignore it. If the first line doesn't give them a reason to care, you've already lost them.

The other thing: everyone involved in the hiring process has to be saying the same thing. If a recruiter pitches one story about the role and the hiring manager tells a different one, candidates notice. It makes the whole company feel disorganized. And in Japan, where candidates are already cautious about leaving a stable employer, especially for a startup or an international company without strong local brand recognition, any sign of misalignment is enough to make them slow down or pull out.

Get the EVP defined for the specific role. Make sure the hiring manager and every interviewer can articulate it. That is the foundation of a credible candidate experience.

Breaking agency dependency: name collecting

Japan has one of the lowest referral rates in the world for engineering talent. Referring someone means putting your own reputation behind them. If that person doesn't work out, there's a sense of personal failure attached to it. That weight suppresses referrals in ways that are very hard to overcome with incentive programs.

So agencies fill the gap. And they're expensive. And the structural problem is that the agency owns the relationship with the candidate, not you.

Google had a work around to this which we called door-to-doors. Instead of asking engineers directly for referrals, which triggered the cultural resistance, we would sit down with each engineer one-on-one and bring a list of names we had already compiled. People they might know from a previous employer, from the same type of team at another company, from the same programming language or product area. I would ask if they recognized anyone, and whether those people were good. It shifted the dynamic. They weren't putting themselves forward as a sponsor. They were just reacting to a name. And once they said "yeah, she's pretty good," that's enough. That's a warm signal. You reach out with something to reference.

The other thing most people don't consider: salespeople. If you're looking for engineers at a mid-sized company, the salesperson knows the entire technical team. And they're far more likely to want to chat and share than the engineer is. So go to the sales team. Ask them. They're extroverted, they're connected, and they have no reason not to help you.

Remove the black box

In Japan, candidates move slowly. They think carefully. They consult their families. They have conversations with their current manager before they make a move. For a startup or an unknown brand, the default posture is caution, because they don't know what they're walking into.

The more you can remove that uncertainty up front, the faster everything moves. It doesn't require a lot. A note from the engineering manager. A description of what a typical sprint looks like. A short video of the office. Anything that makes the unknown feel a little less unknown. If a candidate can get a sense of the culture, the team, the day-to-day, the management style, before they've even had their first interview, they go into the process already more invested.

This is also why an outbound scouting email that just says "hey, are you open to opportunities?" goes nowhere. You're asking someone to commit their time to an unknown. Give them something first.

Mine the database you already have

At Google, a large percent of hires were people who had previously applied or been interviewed. That number often surprises people. Most candidates don't get hired on their first pass. They learn. They acquire experience. They become a better fit for the role the second time around, or they're in a different headspace, or this time they feel prepared and reduce the opportunity for a false negative..

When I worked with a major auto-manufacturer company, one of the first things I saw was a database that the recruiting team was essentially ignoring. Every new role triggered a new pipeline request. The assumption was that a rejected candidate was permanently off the table. The hiring managers would literally say: we already rejected them. And that was it.

That's a huge missed opportunity. Especially in Japan. A candidate who already interviewed with you, already went through your process, already showed interest at some point, they have more brand affinity than any cold candidate you'll find. They know who you are. That matters for offer acceptance.

Tag your candidates. Note what role they interviewed for and why they didn't advance. Set a reminder to check back in after a year. Past interns become mid-career hires. Silver medalists (i.e. past interview finalists who didn't get an offer) from one role are sometimes the right fit for a different one that opens later. This is not admin work. It's a sourcing strategy.

The hiring manager conversation: bring data

When a hiring manager hands you a requirements list, the instinct is to say yes and start sourcing. I've done it. Everyone's done it. You want to be helpful, you want to move fast, you don't want to push back in the first meeting.

The problem is that if you come back with twenty candidates and they're not what the hiring manager expected, you've burned through a chunk of your available pool and also damaged your own credibility. It's much worse than the conversation you were trying to avoid.

Do the analysis first. Take three days. Map the market. Figure out how many people actually exist who match the requirements. Apply realistic conversion rates, response rate, screening pass rate, interview pass rate, offer acceptance. Show the hiring manager the math. If there's a pool of a thousand people but only ten percent respond to outreach and only a fraction pass each stage, what does that actually mean for the headcount target?

Engineering managers respond to this. They're analytical. If you show up with data and say: here's our actual pool, here's where the constraints are, here are the places where we might want to recalibrate, they'll engage with that. They'll consider adjusting the requirements, rethinking the evaluation criteria, and expanding the definition of the role. Things they would never consider if you just walked in and started sourcing.

The worst thing you can do is say yes, go search, come back with nothing, and then try to have that conversation from a position of failure. Have it before anything starts. That's what slow is fast actually means in practice, it's not a mindset, it's a decision to invest thirty minutes in analysis before you spend three weeks on sourcing that was never going to work.

====

Jordan Jarjoura is Head of Product at ZooKeep and formerly led engineering hiring at Google Japan and Korea for nearly eight years, leading engineering recruitment for Google Maps, Search, Google Cloud, and AI Research, among others. Prior to Google, he was at Square Enix in HR and Recruiting, and played a critical role in transforming recruitment practices, process, and use of technology for a major auto-manufacturer before joining ZooKeep.