Module 4: Technical interviews

After this module you will be able to conduct an interview with a client's technical lead that produces, in the lead's own words, the uncertainty, the work done to resolve it and the point at which it was resolved; to listen for the elements of the definition without putting words in anyone's mouth; and to record the interview so that it is evidence in its own right and the source document for the narrative.

What this module covers

Preparation: what to read first, who to interview and what not to send in advance.
A staged question bank, with the follow-up to use when an answer is thin.
Listening for the definition without leading.
Recording the interview as evidence and having the lead confirm it.

Preparing for the interview

Read the records before you meet the people: the project register, the earliest design notes, the ticket or experiment history and the release records show where the unknowns are likely to sit and give you document names to ask about. Interview the person who led the technical work, not the person who sponsored or sold it, and interview separate leads separately, because they will describe different uncertainties. Do not send the statutory definition in advance: it causes people to self-censor or to shape their answers to the words of the test. Send a one line brief instead: we are looking for work where you did not know whether something could be done, or how, and had to find out. Agree at the start that routine work, however hard, is out of scope, and that saying so makes the claim stronger.

The question bank

The questions move in a fixed order, because each stage sets up the next. Use the follow-up when an answer describes the product rather than the problem.

Stage	Question	What it elicits	Follow-up if the answer is thin
Context	What were you trying to achieve, and what would success have looked like?	The technical objective and a measurable target	What number, tolerance or behaviour did it have to meet?
Baseline	What did you and the field already know when you started? What did you look up or ask about?	The state of knowledge and the search made	Had anyone done this before, and how do you know?
Uncertainty	What did you not know how to do at the start?	The unknown, in the lead's words	Could an experienced engineer elsewhere have worked it out from what was published or available?
Alternatives	What approaches did you consider, and why did you pick the first one you tried?	The hypotheses and the reasoning	What did you rule out before trying anything?
The work	What did you try, in what order, and what happened?	Experiments, results, failures, changes of direction	What failed? What did you learn? What changed as a result?
Outcome	When did you know it would work, or that it would not? What told you?	The end point and the record of it	Which test, result or release marked that moment?
Boundary	Which parts of the wider project were straightforward once that was settled?	The routine workstreams to exclude	If you did it again, which parts would need no experiments?
People and time	Who worked on the uncertain part, and roughly when?	Names, roles and periods for the cost analysis	Does the ticket or commit history show those names?
Evidence	Which documents, logs or results would show someone what you have just told me?	The record list for the file	Where are they, and are they dated and attributed?

Listening for the definition

The practitioner's job in the room is to hear the elements of the definition in ordinary language and to probe where they are missing, not to supply them. Uncertainty sounds like "we did not know whether", "nobody could tell us", "the supplier said it could not be done", "three approaches failed". Routine work sounds like "we followed the documentation", "we configured", "it was a lot of work but we knew how". A systematic approach sounds like a sequence: we thought it might be X, we built a test, it showed Y, so we changed to Z.

Three failure modes recur. The lead who says nothing was uncertain, they just worked through it: ask what they tried first and whether it worked, and what they would do differently now; if there were no failures and no changes of direction, accept that the project is out. The lead who describes the whole programme as research: ask the boundary questions until the routine workstreams are named. The lead who answers with features and customer benefits: return to the context stage and ask for the technical target. Ask open questions, let silences run, and never offer the words of the definition as a prompt; a lead who agrees there was "scientific or technological uncertainty" because you suggested it has given you nothing a reviewer will accept.

Recording the interview as evidence

The interview note is a dated record made at the time, and it should look like one: the date, the people present and their roles, the questions asked, the answers in the lead's words with direct quotations for the uncertainty and the outcome, the documents the lead referred to by name, the actions agreed, and a line for the lead's written confirmation that the note is accurate. Send it to the lead within days, ask for corrections, and keep the confirmed version with the earlier draft.

The note then does three jobs. It is the source document for the narrative, which the lead drafts or dictates and the practitioner edits, as Module 5 sets out. It is the evidence list for the file, because every document the lead named is retrieved and dated. And it is the record that the technical account was obtained from the person who did the work, before the claim was written, which is what every reviewer is trying to establish.

Illustrative example

Illustrative example. Harbour Robotics Ltd, a hypothetical company, has a project with costs of 100,000 and a lead engineer who opens the interview by describing the gripper's features. The context question produces a target: hold soft objects of unknown shape with less than a stated damage rate. The baseline question produces a search of published grasp planning methods and a supplier's statement that its force sensors could not resolve the contact fast enough. The uncertainty, in the engineer's words, is "we did not know whether any closed loop approach could react in time with those sensors, or whether we needed different hardware". The work stage produces four approaches, two abandoned after test runs, and the outcome stage a dated test report in month seven showing the target met. The boundary stage identifies the remaining five months as integration with the customer's line, which the engineer agrees needed no experiments. The note records that 70,000 of the 100,000 relates to the seven months inside the boundary and names eleven documents. The narrative is drafted from the note, and the benefit is calculated on the 70,000 at that country's rate.

Across the seven countries

Country	How the technical account is tested
United States	IRS examiners are directed to test contemporaneous documentation, the basis of wage allocations and the consistency between technical narratives and financial records.
United Kingdom	Claims should be able to show which competent professionals judged the uncertainty and what relevant expertise they had.
Ireland	Revenue may consult an expert in the relevant field of science or technology, having first notified the company, and the expert may be given access to the company's records and personnel.
Canada	The technical review procedure includes gathering information through the site visit and interviews, determining eligibility against the guidelines, and communicating preliminary findings before the review report is issued.
Australia	The department sets a period for the company to respond and may follow up with a site visit or meeting with the company's technical staff.
New Zealand	Inland Revenue may engage external technical experts to assist in assessing whether activities meet the definition of core and supporting R&D activities.
Singapore	The Comptroller may by notice require any person to provide information and documents and to attend for interview, and IRAS may seek the views of technical experts in assessing whether a project involves novelty or technical risk.