Part of the guide: Nearshore Software Development: A Field Guide
Most teams interview a senior software developer the way they'd interview anyone: a stack of algorithm puzzles, a system design prompt, a round of "tell me about a time when." It takes four or five hours of their engineers' time, and at the end they often know less than they think.
If the developer came through a partner that has already screened them technically, most of that is duplicate work. The question you're left with is narrower and more important: will this person work well on your team, on your problems? That fits in one hour, if you spend the hour on purpose. Here's how I'd do it for a senior contractor joining a remote or nearshore team.
What a senior developer interview is not for
It is not for re-running the technical screen. Our own 4-gate vetting funnel ends with a two-hour live pairing session in a real codebase, after three earlier gates. A 45-minute whiteboard exercise won't tell you more than that did, and it signals to a senior person that nobody read their file.
It is also not a sales pitch in either direction. Senior developers can tell when they're being charmed, and so can you.
How to structure a one-hour interview
Five minutes: set the table. Say what the team does, what the product is, and what the first month will probably look like. Be concrete. "You'd pick up the billing service, which has more edge cases than tests" is more useful than a mission statement.
Twenty minutes: work through a real problem. Pick something your team solved recently, or is in the middle of. Describe it plainly, including the constraints that made it awkward, and ask how they'd approach it. You're not grading the answer. You're watching how they get to one.
Fifteen minutes: dig into their past work. Ask them to pick something they built that they'd defend, and something they'd do differently now. The second half matters more.
Fifteen minutes: their questions. Leave real time for this, and notice what they ask.
Five minutes: next steps. Say what happens next and when. Senior people have options, and a clear, prompt answer is part of how you win the ones you want.
Interview questions for a senior software developer
These do more work than puzzles, because there's no memorized answer to reach for.
- "Before you'd start on this, what would you want to know?" Asked about the real problem in the second block. A senior developer's first move on an unfamiliar problem is almost always a question.
- "What would make you choose the other approach?" Tests whether they see trade-offs or just preferences.
- "Here's a constraint we forgot to mention. What changes?" Add it halfway through. Watch whether they adjust or defend.
- "What's something you built that you'd still defend today, and why?"
- "What's something you'd build differently now?" Look for a specific, unembarrassed account of what went wrong and what they learned.
- "Tell me about a code review where you disagreed with someone. How did it end?" Remote teams run on review; this is how disagreements get settled.
- "When a task turns out bigger than you estimated, when do you say so, and to whom?" On a distributed team, the answer should be "early, and in writing."
- "What do you need from a team to do your best work?" Senior people know, and the answer tells you whether you can provide it.
What good answers sound like
- "It depends," followed by what it depends on. The second half is the whole point.
- The people around the code. Who reviews it, who gets paged, who has to read it next year.
- Comfort with "I don't know." Especially about your domain. Pretending is a bigger risk than not knowing.
- Clear writing afterward. If you exchange a message or two after the call, read it the way you'd read their pull request descriptions. Remote work runs on writing.
And a few that should give you pause: jumping to a solution before asking anything, defending the first idea after the constraint changes, or a "what I'd do differently" answer that blames everyone else.
Who should be in the room
One person from the team they'd join, ideally the engineer they'd work with most. Two at most. A panel of five turns a conversation into a performance, and you lose the thing you came to see.
If the developer is in another time zone, schedule the call inside the window you'd actually share. It's an honest preview of the working relationship for both of you, and our guide to Latin America time zones shows how large that window is for each country.
Decide the same week
The fastest way to lose a strong senior developer is to go quiet for two weeks while you schedule three more rounds. If the hour went well and the screening before it was real, you have what you need. Say yes, set a start date, and put the effort you saved into their first two weeks.
The interview isn't where you find out whether someone can code. It's where you find out whether you'd want them in the room when something breaks. One good hour is enough for that. If you'd like senior developers who arrive already vetted, how it works explains what happens before they reach your calendar.