A reference check after the final interview usually means you’re close to an offer. It doesn’t mean the decision is made. References come late in the process. Their main job is to catch anything the loop missed. So the call can still change the outcome. Your references won’t just be asked whether you’re good. They’ll be asked how you compared with your teammates. They’ll be asked what you were the go-to person for and how you work best. A vague answer like “great to work with” carries little weight. A specific, comparative one carries a lot. For an Android engineer, pick people who watched your Android work up close. That matters more than a senior title. Then brief each one before the call. Tell them the role, the one project to describe and the strength the loop seemed unsure about. Also expect a back-channel call to someone you didn’t list.
We’ll follow one candidate through this post. They finished a senior Android loop at a mid-size product company. The recruiter now wants three references by Friday. Their strongest project was an offline sync rewrite for a field-sales app. Their system design round went well. Their behavioral round raised one question about how they handle cross-team disagreement.
A reference check after the final interview looks for what the loop missed
Companies that check references usually do it near the end. GitLab’s public handbook describes a Reference Check stage that runs before an offer. Recruiters must request references there before giving one. The Holloway Guide to Technical Recruiting and Hiring gives the reason. Its section was last updated in August 2022. It advises asking only when a candidate is fairly far along, because references cost the candidate social capital.
The same Holloway section lists what the calls are for. The first purpose is finding red flags the interviews missed. It also names choosing between equally strong candidates and planning how to help the new hire succeed. The US Office of Personnel Management says something similar in its guidance on reference checking. The page is undated. It describes references as a way to verify claims and to predict performance from past work. It recommends them for the final stage, with a few top finalists.
So treat the reference request as one more round. It’s a short one that you don’t attend. For our candidate, the loop already believes the design skills. The open question is the cross-team disagreement. A reference who saw that side of them is worth more. Repeating what the design round showed adds little.
Your references get asked how you compared with the rest of the team
A reference call does check dates and titles. That part is quick. Holloway’s chapter on designing reference questions describes the rest. Hiring teams start with context. That covers the reference’s role, how long they worked together and how the candidate’s job changed. Then they ask comparative questions instead of ratings. The guide’s own example asks how a candidate’s Python skill compared with others on the team.
The guide also suggests questions about what the candidate was the go-to person for. Others cover how they communicate and whether they suit a lead track or an individual track. One asks what kind of team would help them succeed. These questions reward a reference who knows your work in detail. Someone who only saw your output in a status meeting has little to say.
Holloway’s section on interpreting reference feedback explains how answers get read. References lean positive, so the guide gives generic praise less weight. The guide quotes one suggestion to discount positive comments by 30% and amplify negative ones by 30%. Specific, comparative praise from someone who saw many engineers counts for more. Vague or evasive answers get a closer look.
For an Android role, a comparative question might cover app architecture. How did you handle it next to other mobile engineers? Or it might ask whether you were the person others asked about Compose, Gradle builds or crashes. Your reference needs a concrete answer ready. A crash you tracked down or a module you owned works well.
Pick the reference who watched your Android work, not the biggest title
Holloway’s guidance favors former colleagues as well as managers. Peers can speak to collaboration and communication in ways a manager may not. It also advises hiring teams not to call a candidate’s current employer. Most candidates don’t want their current company to know they’re looking. If you’re still employed, you can say that up front.
Our candidate has four possible references. Their first engineering manager is now a director. That manager left before the sync rewrite. Their current manager can’t be asked. A backend engineer built the sync API with them. A tech lead on the web team argued with them over the API contract. The two of them settled it.
The director has the biggest title and the weakest answers. They can’t describe the project the loop cared about. The backend engineer can compare our candidate with other mobile engineers they’ve worked with. The web tech lead is the most useful of all. That person saw the exact cross-team disagreement the behavioral round questioned. If the recruiter wants a former manager, our candidate can add the director as a third name. They should know that this call will carry the least detail.
Choose people who can answer comparative questions about the work this role needs. Then check that at least one of them covers the area the loop was unsure about.
Brief each reference before the recruiter calls
A good reference can still give a weak answer if the call catches them cold. They may describe an older project or praise the wrong strength. Asking permission and briefing them takes five minutes. Here’s the message our candidate sends to the web tech lead.
Hi Priya, I'm in the final stage for a senior Android role at a product company. Would you be OK being a reference? Their recruiter would call in the next week or so. The role leads mobile work on a team that ships with backend and web every sprint. So they care a lot about cross-team work. If it helps, the project I'd love you to speak to is the sync API contract last spring. You pushed for cursor-based paging. I wanted timestamps. We ran both against the offline cases and went with yours. I wrote up the decision for both teams. They may ask how I compared with other mobile engineers you've worked with. Please answer honestly, including anything I could do better. Thanks either way. I'll let you know how it goes.
The message asks first and gives an easy way to say no. A reluctant reference is a risk, so you want to know early. It names the role’s real priority in one line. Then the reference can pick examples that fit it.
It points to one project with a few concrete details. Those details remind the reference what happened. They aren’t lines to recite. The project also matches the behavioral round’s open question. Our candidate didn’t win that argument. Losing it well, then documenting the decision, is the evidence the loop wanted.
It warns that a comparative question may come up. It also asks for honesty. Holloway’s guidance says hiring teams read hesitation and vague praise closely. A reference who sounds coached may stand out for the same reason. In our view, a candid reference who mentions a real weakness sounds more credible.
Don’t write a script for them. Don’t ask them to overstate your role. The details should be true and easy to check.
Expect a back-channel reference you didn’t choose
Your list isn’t the only source. Holloway’s section on back-channel references describes calls to people you worked with but didn’t list. Hiring teams often find them through LinkedIn or shared contacts. The guide says they’re more common for senior roles and in dense networks like Silicon Valley. It also recommends asking candidates first whether anyone should not be contacted. Not every team does.
Android teams tend to be small. Mobile engineers also move between a limited set of companies. So a back-channel call is a real possibility for a senior Android role. You can’t brief someone you don’t know about. But you can do two things.
First, if the recruiter asks whether anyone shouldn’t be contacted, answer plainly. Name your current employer and anyone with a real conflict. Give a one-sentence reason. Don’t list half your old team, because that reads as hiding something.
Second, make your own list cover your recent work. Our candidate’s two references both saw the sync rewrite. A back-channel call to a former mobile teammate will likely describe the same work. Suppose your listed references only cover a job from four years ago. Then the back channel becomes the most current picture of you.
Our candidate sends the brief to Priya and the backend engineer that evening. They tell the recruiter the current manager is off-limits. They give the reason in one sentence. Then they send the names before Friday. If the offer stalls after this, ask the recruiter directly whether references are still outstanding. Sometimes one reference just hasn’t called back. A stall can also happen at the committee stage. That’s covered in our post on why you can ace every round and still get rejected.