Partway through diligence the reviewer says they would like to talk to your lead engineer directly, without you on the call. Founders hear that and tense up, because the one part of diligence you cannot personally control is what your team says when you are not there. It is not a trap. Reviewers do this because talking to the people who actually build the system is the fastest way to learn whether the story the founder told holds up. An unprepared team will not lie; they will just answer badly, and that can cost you as much as a real problem would.
I have been the reviewer on those calls and I have prepped teams for them. The failures are almost never dishonesty. They are engineers who were never told the call was coming and did not know what mattered.
Why reviewers talk to the team directly
A founder describing their architecture is one data point. The engineer who built it is a better one, and the gap between the two is exactly what the reviewer is looking for.
They are checking the founder's story against the source
Investors treat the engineer interview as verification. If you told the committee the system scales cleanly and your engineer, unprompted, describes the part that falls over at load, the reviewer now has a discrepancy to chase. This is the same failure mode as an engineer contradicting the founder in a diligence call, except now it happens in a room you are not in. The point is not that your team should hide problems. It is that the founder and the team need to be telling the same honest story, which only happens if you have actually talked about it beforehand.
They are assessing whether the team can extend the code
Reviewers check whether a team other than the original authors could understand and extend the system. Talking to your engineers tells them how well the team understands its own product, how decisions get made, and whether knowledge is shared or trapped in one person. An engineer who can explain why the architecture is the way it is, including the tradeoffs, signals a healthy team. One who says "I just work on my part, ask the founder" signals the key-person risk the reviewer was already worried about.
How to prepare the team without scripting them
The wrong preparation is worse than none. Coach engineers to recite talking points and a reviewer will smell it in a minute, and a team that sounds rehearsed reads as a team with something to hide.
Tell them it is coming and why
The single most valuable thing you can do is not surprise them. Tell your engineers a diligence interview is likely, that it is normal, and that its purpose is to verify the technical story, not to catch anyone out. An engineer who knows the context relaxes and answers well. One ambushed by a stranger asking pointed questions about the codebase gets defensive and vague, and vague reads as evasive even when it is not.
Align on the known weaknesses
Sit down with the team before the calls and agree on the honest version of your weak spots and the plan for each. Not a script, a shared understanding. If everyone already knows that the search service is the scaling risk and there is a plan for it, then whoever the reviewer asks gives the same grounded answer instead of one person minimizing it and another blurting it out as a crisis. This is the same work as surfacing your own issues in the tech memo the committee reads; the team interview is where that memo gets stress-tested by someone other than you.
Let them be honest, and tell them so explicitly
Give your engineers permission to say "I do not know, but I can find out" and to describe real tradeoffs plainly. Reviewers respect that far more than confident hand-waving. The damage in these calls comes from an engineer who guesses to sound competent and gets it wrong, or who tries to spin a known problem and gets caught. Honesty from a team that clearly understands its system is the outcome you want, and it is also just the truth being allowed to speak.
The engineer interview is not the part of diligence to fear. It is the part you cannot fake, which means the only real preparation is having built a team that understands its own product and tells a consistent, honest story about it. If you want a dry run before a fund's reviewer talks to your team, walking the technical story through with an outside reviewer first is exactly what a teardown or a call before the round is for.
FAQ
Can I be on the engineer interview?
Sometimes, but if the reviewer asks to speak with the team alone, insisting on being there looks like you do not trust them to answer. A better move is to prepare them well beforehand and let them speak. Your absence is only a risk if the team is unprepared.
What if my engineer surfaces a problem I did not mention?
That is why you align on the weaknesses beforehand. If it happens anyway, the fix is not to contradict your engineer later, it is to have already told the committee your honest weak spots so there is no gap for the reviewer to exploit. A consistent story across founder and team is the whole game.
Should I coach my engineers on what to say?
Coach them on context, not content. Tell them the call is coming, why it happens, and what your shared honest weaknesses are. Do not hand them lines. A rehearsed engineer is easy to spot and reads worse than an honest one who occasionally says they will get back to you.