SR&ED technical interview: what questions to ask developers

The classic trap of the SR&ED interview: asking "What research and development did you do?" Almost always, the answer is "Nothing special, we just built the product." Developers downplay the problems they eventually solved. Your job is to get around that modesty by asking concrete questions that bring out the uncertainties and the attempts.

Before the interview: set the right frame

You're not assessing the quality of the software or the team's competence. You're looking for the moments when nobody knew in advance how to do it, and what was tried to get there. Say it plainly: "I want to understand where things got stuck technically, not judge your work." Teams open up far more when the frame is set this way.

Open with the concrete, not with "R&D"

• Which part of the project gave you the most trouble?
• Was there a problem you were stuck on longer than expected?
• What forced you to experiment before finding an approach that held up?
• Was there a feature you weren't sure you could deliver?

The word "stuck" is valuable: it leads straight to the uncertainties without ever uttering the word "SR&ED."

Dig into the technological uncertainty

Once a problem is identified, you need to establish that it was a genuine uncertainty, not just work to be done:

• Did you know at the outset how you'd solve it, or did you have to figure it out?
• Did an existing solution, library or documentation meet the need? Why not?
• Would another experienced developer have known right away how to proceed?
• What made the outcome uncertain: performance, accuracy, scaling, an integration, hardware?

Bring out the experimentation

This is where the strongest material for the report lives. The attempts, especially the failed ones, demonstrate the systematic process:

• What approaches did you try before the one that worked?
• Why did you abandon the first ones?
• Did you have to redo or rewrite part of it? What wasn't working?
• How did you know one approach was better than another: measurements, tests, comparisons?

The single most valuable question of the whole interview: "Tell me about something you tried that didn't work." Failures are direct evidence of experimentation, and they're exactly what people forget to record.

Lock down the evidence and the time

Before wrapping up, secure what will make the file verifiable:

• Where can the trace of this work be found: code repositories, tickets, pull requests?
• Over what period were these problems addressed?
• Who worked on it, and roughly what share of their time?

A few pitfalls to avoid

• Closed questions. "Did you do R&D?" invites a yes/no that's of little use. Prefer "Tell me about…".
• Settling for the first answer. The real technical problem often shows up on the second or third follow-up.
• Accepting jargon without translating it. Keep asking until you understand where the difficulty really was.
• Forgetting the dead ends. A story where everything went fine is an incomplete story.

When the interview goes beyond the firm's reach

On advanced projects (AI, distributed systems, performance, hardware), it becomes hard to follow up well without understanding the technology. That's exactly when to hand the interview to me: I speak to developers in their language, identify the eligible uncertainties, and hand you material that's ready to write up. You keep steering the file and the client relationship; I bring the technical depth.