How to build an interview scorecard app

What matters here

• A scorecard app is four parts: competencies per role, per-interviewer scorecards, independent submission, and a comparable decision view.
• Hide other scores until a submission is in. Visible scores produce convergence, and convergence looks like signal.
• Assign competencies to interviewers in advance. Four people all assessing culture fit and nobody assessing the actual skill is the default failure.
• Require evidence with every score. A rating with no example is an impression, and impressions are where bias lives.
• Define the scale in words, not numbers. Everyone means something different by a 3 unless you write down what a 3 is.
• The app holds candidate data, which is personal data with legal obligations, so access control and retention are part of the build.

Who this is for

You run recruiting or hire regularly. You already know which roles you struggle to assess consistently. What you want is feedback that arrives, is comparable across interviewers, and gives you something to say when a decision is questioned.

How it works in practice

What happens before, during and after a panel, and the one rule that protects the signal.

1. 1

   Competencies are agreed before anyone interviews

   With the scale written out in words, so a 3 means the same thing to two different interviewers.

2. 2

   Each interviewer is assigned specific competencies

   And the app warns you if one is covered by nobody, or by four people at once.

3. 3

   Interviewers get their questions on the feedback page

   Assigned competencies, behavioural anchors, and suggested questions, all in one place.

4. 4

   Nobody sees anyone else's score until theirs is in

   This is the whole design. Interviewers who read an earlier score move towards it, and the panel then mistakes agreement for evidence.

5. 5

   Every rating needs an example

   A score with no evidence is an impression, and the app should not accept one.

6. 6

   The debrief compares on the same axes

   Disagreement highlighted rather than averaged, with the evidence expandable inline.

1. 1

   Decide what good looks like, in words

   Before anyone is in a room, and this is where most scorecards fail.

   Copy

   In this Helix project, build me an interview scorecard app.
   
   Start with competencies, and do not ship a numeric scale without written
   anchors. For each competency, write out what a 1, a 3 and a 5 actually
   look like behaviourally. A scale of one to five with no words attached
   produces ratings that are not comparable between two interviewers, which
   makes the whole exercise decorative.
   
   Then roles: title, level, family, hiring manager. Attach a set of
   competencies to each role with a weight, and let me clone a role's set as
   the starting point for another role in the same family.
   
   And a question bank: per competency, questions worth asking and what a
   good answer contains.
   
   I sign in through Helix, so do not build a login page. Read the signed-in
   user from the runtime. And do not put any key or connection string in the
   code: if this needs to reach another system, tell me and I will create the
   connection in my workspace.

   Worth knowing. The behavioural anchors are the whole exercise. Everything else here is plumbing around them.

2. 2

   Assign coverage deliberately

   So somebody is assessing the thing that actually matters.

   Copy

   Add candidates, panels and assignment.
   
   For each interview, assign that interviewer specific competencies rather
   than letting everyone assess everything. Then check the panel: warn me if
   any competency for this role is assigned to nobody, and warn me if one is
   assigned to more than two people.
   
   Four people assessing the same broad trait while nobody assesses the
   specific skill is the standard way a panel fails, and it is invisible
   unless something checks for it.
   
   On the page where each interviewer writes their feedback, give them their
   assigned competencies, the behavioural anchors, and suggested questions
   from the bank. Nobody should have to go and find those.

3. 3

   Independent scoring

   The rule that protects the signal, and it is not optional.

   Copy

   Now scoring, and this is the most important rule in the app.
   
   Hide every other interviewer's score and comments until the signed-in
   interviewer has submitted their own. Interviewers who can see an earlier
   strong yes produce more strong yeses, and the panel then reads its own
   convergence as evidence, which is exactly backwards.
   
   Require written evidence on every rating. A score with no example is an
   impression, and impressions are where bias lives. Do not accept a rating
   without one.
   
   Give each interviewer an overall recommendation from a fixed list: strong
   no, no, yes, strong yes. No neutral option. A panel of maybes decides
   nothing.
   
   Lock a submission once made. An edit creates a visible revision with a
   reason, rather than quietly replacing the original. And chase unsubmitted
   feedback automatically, with the debrief as the deadline.

4. 4

   The debrief, and what it tells you about your interviewers

   Comparing candidates properly, then looking at yourselves.

   Copy

   Build the candidate summary: every competency, each interviewer's rating and
   evidence side by side, and the weighted total. Show the spread as well as
   the average, and highlight any competency where interviewers disagreed by
   more than a threshold. Disagreement is information and averaging destroys
   it.
   
   Add a comparison view for several candidates on the same role, on the same
   competencies, with evidence expandable inline. Then a decision record:
   outcome, who decided, when, why, and which competencies drove it.
   
   Finally, three reports. Score distribution per interviewer, so I can see
   who rates everyone highly and who has never given a strong no.
   Competencies that never discriminate between candidates, which are
   measuring nothing and should be dropped. And time from interview to
   feedback submitted.
   
   Add a retention rule too: flag candidate data older than a period I set
   for deletion, and show me what is due.

   Worth knowing. The interviewer distribution report is uncomfortable and useful. Someone who has never used the ends of the scale is not calibrated.

5. 5

   Connect it to real systems

   The step that turns a working prototype into something with your data in it.

   Copy

   Now connect it to the systems we actually run, so it works on real data
   rather than the rows you seeded.
   
   Anything in angle brackets is a placeholder. Swap it for whatever we use
   instead, and have the app name the connection it wants rather than assume
   a vendor, so changing my mind later is a config change and not a rewrite.
   
   <Greenhouse>. Read candidates, roles and scheduled interviews, and write
   the decision back once the debrief closes.
   
   <Okta>. Resolve interviewers to real accounts, so the app can match a
   person to the panels they are actually on.
   
   <Google Calendar>. Read who is on which interview, so assignment does not
   need re-entering.
   
   <Gmail>. Send the scorecard link and the reminder by email, for the panel
   members who do not live in chat.
   
   <Zoom>. Read which interviews actually happened, so chasing feedback is
   not based on the calendar invite.
   
   <Slack>. Chase unsubmitted feedback before the debrief, which is most of
   what this saves.
   
   <Snowflake>. Push scores into the warehouse for the calibration reporting,
   without holding candidate data twice.
   
   Only write where I have said to write. Everything else is read only.
   
   Do not write a key, a token or a connection string anywhere in the code,
   and do not ask me to paste one. Tell me which connections you need and I
   will create each as an authentication in my Helix workspace. Reference
   them by alias.

   Worth knowing. Every name in angle brackets is a placeholder for whatever you run. Helix holds the credential as a workspace authentication, so the app references an alias and never the secret itself.

6. 6

   Ship it

   The last step of every build: a URL, and the right people on it.

   Copy

   Deploy my app.

   Worth knowing. Your assistant runs helix deploy underneath and the app comes back as a URL. Candidate data is personal data with legal obligations attached, so set Access Control before sharing and scope it to the panels people are actually on.

What it connects to

Candidate data is personal data, so this reads carefully and writes back only the decision.

• Greenhouse

  Read candidates, roles and scheduled interviews, and write the decision back once the debrief closes.

• Okta

  Resolve interviewers to real accounts, so the app can match a person to the panels they are actually on.

• Google Calendar

  Read who is on which interview, so assignment does not need re-entering.

• Gmail

  Send the scorecard link and the reminder by email, for the panel members who do not live in chat.

• Zoom

  Read which interviews actually happened, so chasing feedback is not based on the calendar invite.

• Slack

  Chase unsubmitted feedback before the debrief, which is most of what this saves.

• Snowflake

  Push scores into the warehouse for the calibration reporting, without holding candidate data twice.

Each line says whether the app reads, writes or both. Anything not described as writing should be read only.

Named systems are the ones most teams actually run, not a list of the only ones that work. Swap in whatever you use.

Each connection is an authentication in your Helix workspace, referenced by alias. The app names the connection it wants and never holds the credential, so nothing here ends up in your code and any of it can be rotated or revoked without a redeploy.

Related guides