Question count looks objective. That makes it tempting to treat it as a measure of interviewer quality. An interviewer who asks fewer questions might appear focused. One who asks more might appear thorough. The interview record does not support either conclusion.

In a sample of 1,142 captured interviews where questions could be detected from the transcript, the median was 19. The middle half ran from 12 to 27. That is a wide spread, but it does not tell us which interviews were better. The count cannot tell whether a question was job-related, whether a follow-up uncovered useful evidence, or whether the interviewer applied the rating scale consistently.

Interview records can still help a team review its process. They show what was asked, how the conversation unfolded, and what was documented afterwards. Used carefully, those records can point to interviews worth opening and coaching opportunities worth discussing. They cannot, on their own, rank interviewers by the quality of the people they hire. Metaview’s corpus holds no post-hire performance, retention, or tenure data.

What best would have to mean here

There are several reasonable ways to judge an interviewer. A team can review whether they covered the competencies assigned to their stage, asked job-related questions, gave the candidate enough room to answer, followed up on unclear evidence, and recorded the basis for their rating.

Those are process measures. They can identify specific behavior to reinforce or coach. They are not the same as proving that one interviewer consistently selects people who later perform well.

Metaview’s aggregate interview data cannot make that second judgment because it contains no post-hire performance reviews, retention, tenure, or quality-of-hire outcomes. Candidate advancement is not a substitute. It records what the hiring team decided. It does not record whether the decision later proved correct.

The other common measures are narrow too:

• A completed scorecard shows that a form was submitted. It does not prove the rating was accurate or well supported.
• Talk share shows how speaking time was divided. It does not explain why the interview took that shape.
• Question count shows how many questions were detected. It does not distinguish a strong core question from a weak one, or a useful probe from an unnecessary detour.

These measures become useful when a team treats them as prompts for review. They become misleading when they are combined into a single interviewer score and presented as a verdict.

What question counts actually show

The measured variation is real within the sample. Across 1,142 interviews, the median number of detected interviewer questions was 19. The twenty-fifth percentile was 12 and the seventy-fifth percentile was 27.

Talk time varied too, in separate qualifying samples. Across 2,688 interviews with speaker-attributed timing, the median interviewer share was 46.8%. The tenth percentile was 27.9% and the ninetieth percentile was 65.1%. In another sample of 2,542 interviews, the interviewer spoke for more than 70% of the conversation in 5.63% of cases.

Those sample sizes bind everything in this section

These are small, filtered samples from a much larger corpus. The question figure is based on transcript detection, which means it measures what the method identified as a question. It does not tell us what type of question was asked or how useful it was. The talk-time figures only cover interviews with the required speaker-attributed audio.

The figures describe the shape of those samples. They are not targets for an individual interviewer, a role, or a company. A team should not try to reach 19 questions or a 46.8% talk share simply because those are the medians.

The ranking idea falls over on its own

Nothing in these distributions tells us that the lower or higher end is better. Twelve questions might represent a focused interview with strong follow-ups. It might also represent an interview that missed half the rubric. Twenty-seven questions might reflect careful probing, or it might reflect a rushed list with no depth.

The number tells you that two conversations took different shapes. To understand whether the difference matters, you have to read or listen to the interviews and compare them with the plan for that role and stage.

Variation inside one role is the part worth acting on

Question counts become more useful when the comparison is narrow. Put interviews for the same role and stage next to each other. Large differences can point to inconsistent coverage, but the difference itself is not the finding.

Two candidates may receive different follow-up questions because they gave different answers. That is normal. The problem is when they are not given comparable opportunities to demonstrate the competencies assigned to the stage, or when interviewers apply different standards to the answers they hear.

That is one company’s account. It is not a prevalence estimate. It shows the practical use of the comparison: the team could see an extreme difference, open the interviews, and decide whether its process needed more structure.

Official structured-interview guidance makes the standard clearer. Candidates should be assessed against job-related competencies using predetermined core questions and the same rating scale. The more consistent the core assessment is, the easier it is to compare the evidence. Follow-ups can still clarify an answer, but they should serve the same competency rather than create a different interview for each candidate.

Decide what a strong answer looks like first

A shared question list helps, but it is not enough. Interviewers also need a common understanding of what they are assessing and how the evidence maps to the rating scale.

Before the loop starts, agree on four things:

• the job-related competencies the role requires;
• the stage responsible for assessing each competency;
• the core questions and approved probes for that stage;
• the evidence expected at each rating level.

“Strong communicator” is too broad to score consistently. A more useful definition describes an observable job requirement, such as:

Explains a technical trade-off clearly enough for a nontechnical stakeholder to make a decision.

That definition gives the interviewer something concrete to test. The core question can ask for a real example. Follow-ups can then clarify the audience, the options, the candidate’s role, and the decision. The rating should refer back to the agreed evidence, not to whether the interviewer personally liked the answer.

Ask one question, then follow the answer

A structured interview does not have to sound like a script being read at someone. Start with the agreed core question, listen to the answer, and use focused probes to fill the important gaps.

For example:

Tell me about a project where you had to make an important decision without all the information you wanted.

The first answer may not contain enough detail to rate. Follow up on three areas.

What they personally did

• What was your responsibility?
• Which decision was yours?
• What did you do first?
• Who else was involved?

Why they chose that approach

• What other options did you consider?
• Why did you choose that one?
• What risk were you accepting?
• What information was missing?

What happened next

• What happened after the decision?
• How did you know whether it worked?
• What went wrong or changed?
• What would you do differently now?

The result matters, but it should not be graded in isolation. A reasonable decision can end badly, and a poor decision can benefit from luck. The interviewer should rate the evidence against the competency and the agreed anchors.

Stop probing when you have enough evidence to apply the rubric. If the answer remains too thin, record that the evidence was insufficient. Do not turn uncertainty into a confident rating simply because the interview time has run out.

What the interview leaves behind

The written record is another part of the process a team can inspect. It should be kept separate from question count and talk share because it answers a different question: was a structured evaluation created, submitted, and completed?

In a capped sample of 120,000 created scorecards, 50.3% of scorecards where Metaview generated the first draft were submitted, compared with 28.6% of manually started scorecards. The groups contained 93,502 and 26,498 scorecards respectively. This is an observational comparison between self-selected groups. It does not show that the draft caused the higher submission rate, or that the submitted scorecards contained better judgments.

A broader corpus measure uses a different denominator. Of 5,207,185 candidate interviews, 31.2% had at least one scorecard attached. That figure does not tell us whether every interview was expected to have a scorecard or whether the attached scorecard was complete.

Completeness is a third measure. In a separate sample of 13,373 created scorecards, 32.1% had every field filled and 25.6% were empty. Again, a full form is not proof of a good interview or a sound rating.

Keep the measures separate:

• scorecard attachment shows whether a scorecard record was linked to the interview;
• submission shows whether a created scorecard was finalized;
• field completion shows how much of the form was filled;
• evidence quality requires reading whether the rating is supported by something the candidate actually said.

A team can improve the first three without improving the fourth. The content still needs human review against the role’s criteria.

Where Metaview fits

Metaview’s Notetaker is visible to participants on video calls. Teams decide which conversations it joins. It records and transcribes the conversation, then organizes factual details into notes based on the team’s template.

Metaview can also help fill factual scorecard fields when the ATS workflow supports it. Subjective fields, ratings, and hiring recommendations remain with the interviewer. The interviewer reviews the draft, corrects it, adds the evaluation, and submits it.

The exact workflow varies by ATS. Ashby and Lever support reviewing and submitting matched feedback forms from Metaview. Greenhouse supports scorecard autofill through Metaview’s browser extension, with the interviewer reviewing and submitting the scorecard in Greenhouse. Current integration documentation should be checked before making a system-specific claim.

Reports lets teams filter captured conversations by properties such as role, stage, interviewer, date, ATS status, and conversation content. It can also extract consistent fields into columns and export the results. That makes it easier to find a narrow comparison set. It does not turn a question count or talk-time split into an automatic judgment of interview quality.

A high interviewer talk share may reveal an interviewer who is crowding out the candidate. It may also reflect a stage that includes a long role briefing. The metric tells you which conversation to open. The recording and rubric provide the context needed to decide what happened.

Running the review without writing a script

Start with one role and one stage. A narrow comparison makes it easier to distinguish a repeatable process problem from ordinary differences between roles.

Read a small sample side by side

Choose a sample small enough to review in full. For each interview, note:

• which core questions were asked;
• which follow-ups were used and what they clarified;
• whether the assigned competencies were covered;
• whether the candidate had a comparable opportunity to provide evidence;
• whether the scorecard rating points to specific parts of the answer.

Check the questions against the rubric

A weak answer can come from the candidate, but it can also come from a vague, overloaded, or irrelevant question. Check whether the question gave the candidate a fair opportunity to demonstrate the competency before treating the answer as evidence against them.

Calibrate on one recorded answer

Have several interviewers rate the same answer independently. Then compare the evidence each person used and the rating anchor they applied. A disagreement is useful because it shows where the competency definition or scoring guidance is still unclear. Resolve the difference before the next interview rather than allowing each interviewer to keep a private standard.

Change one thing, then look again

Do not rebuild the entire interview loop from a handful of conversations. Choose the repeated issue that matters most, such as missed competencies, stacked questions, weak follow-ups, interviewer-heavy calls, or ratings with no cited evidence. Change the guide or coaching, then review another comparable sample.

At the end of the review, you should know whether candidates were assessed against the same job-related criteria and whether the ratings are traceable to what they said. You still will not know, from Metaview’s interview corpus alone, which interviewer consistently produces the best post-hire outcomes. That is a different analysis with different data.

Use question counts and talk share to decide where to look. Use the interview, rubric, and scorecard to decide what needs to change.

Source notes

1. Metaview aggregate study of captured conversations. Questions per interview: TALKTIME-7, n=1,142, median 19, p25 12, p75 27. This is a transcript-detection proxy. Interviewer talk-share distribution: TALKTIME-4, n=2,688, p10 27.9%, median 46.8%, p90 65.1%. Interviewer share above 70%: TALKTIME-5, 5.63% of n=2,542.

2. Metaview aggregate scorecard analyses. CORPUS-13: 5,207,185 candidate interviews, 1,624,988 with at least one scorecard attached, 31.2%. SCORECARDS-12: capped sample of 120,000 created scorecards, manual n=26,498 at 28.6% submitted and Metaview-drafted n=93,502 at 50.3%. SCORECARDS-6: n=13,373 created scorecards, 32.1% all fields filled and 25.6% empty.

3. James Lesner quote from Metaview’s Catawiki case study. LC Dyas quote from Metaview’s EvenUp case study. Each describes one company’s experience and is not a corpus-wide prevalence estimate.

4. Structured-interview guidance: U.S. Office of Personnel Management, Structured Interviews. Current Metaview product behavior: Reports Overview, Best practices for Notes, and the current Ashby, Lever, and Greenhouse integration documentation.