Most interview tracking spreadsheets fail in the same quiet way. The sheet is built carefully, the columns are sensible, and for ten days everybody uses it. Then one interviewer confirms a time by email without touching the sheet, a second reschedules from their calendar, and by the end of the fortnight the grid and the calendars disagree. Nobody announces this. People simply stop trusting the sheet and go back to asking in chat.
The difference between a tracker that survives and one that does not has almost nothing to do with layout. It comes down to whether updating the sheet is the same act as doing the work, or a second act that somebody has to remember afterwards. Everything below is aimed at that one problem.
One row per interview, not one row per candidate
This is the decision that determines whether the rest of the sheet works, and it is the one most templates get wrong.
A candidate row looks efficient until somebody goes through three rounds. Then the row needs first interview date, first interviewer, first outcome, second interview date, second interviewer, second outcome, and the sheet grows sideways until it needs horizontal scrolling on every screen in the building. Worse, the moment a candidate has a fourth conversation that nobody planned for, there is nowhere to put it, so it goes in a notes cell and disappears.
One row per interview fixes this. Each row is a single scheduled conversation, carrying the candidate, the round, the date and time, the interviewer, the format, the location or link, the confirmation state, and the outcome. A candidate with three rounds has three rows. Counting how many interviews happened last week becomes a filter rather than an arithmetic exercise, and nothing needs to be redesigned when somebody adds an unexpected round.
Keep the candidate details in a second tab, one row per person, and reference them rather than retyping them. The interview tab holds the schedule, the candidate tab holds the person and the documents. Two narrow tables are easier to maintain and far easier to read than one wide one, and they make it possible to hand someone a filtered view of the schedule without handing them salary expectations and outcomes for everyone else.
The columns that decide whether the sheet stays accurate
| Column | Why it exists |
|---|---|
| Candidate | Links the row back to the person tab |
| Round | First, second, panel, final |
| Date and time | Stored as a real date value, not typed text |
| Time zone | The field that prevents the most damaging single error |
| Interviewer | One name, the person who has to show up |
| Format and location | In person, video link, phone |
| Invitation sent | Date, not a checkbox |
| Candidate confirmed | Date, not a checkbox |
| Outcome | Advance, reject, no show, rescheduled |
| Feedback submitted | Date the interviewer actually wrote it up |
Two of those deserve an argument. Invitation sent and candidate confirmed have to be separate fields, and both have to be dates rather than ticks. A single scheduled column cannot distinguish a time that was proposed from a time somebody agreed to, and that distinction is the difference between an interview and an empty meeting room. Storing dates rather than ticks also makes the useful question answerable: which invitations went out more than two days ago with no reply.
Time zone is the other. Where anyone involved is remote, a column holding the candidate's time zone, filled in at the point the application arrives, removes the most common category of no show. A grid that shows only local time reads as correct to the person who typed it and wrong to everybody else.
Enter dates as dates. A cell holding 3/4 is ambiguous across countries and unsortable in every country. Set the sheet's locale once, use the date picker, and use a separate column for the start time. Sorting by a text column that looks like a date is a bug that hides for weeks, because it usually produces an order that is nearly right.
Make the sheet the thing people already touch
A tracker that requires a second action after the real work will drift. There are three practical ways to close that gap, and they differ in effort.
The cheapest is to stop typing rows in by hand. If applications and availability arrive through a form, the rows should be created by the form, so that the schedule tab starts populated with candidate, role, time zone and preferences that nobody had to copy. Copying by hand is not only slow, it is the step where names get misspelled and email addresses lose a character, which then quietly breaks every later message.
The second is to make the calendar and the sheet agree by construction. Send the invitation from the calendar, paste the event link into the row, and treat the calendar as authoritative for the time while the sheet stays authoritative for the state. Trying to keep two records of the same time in sync by discipline alone does not work over more than a few weeks.
The third is protection. Google Sheets allows a sheet or a range to be protected so only named editors can change it, and Excel allows specific cells to be locked on a protected worksheet. Locking the columns that everyone reads, such as candidate and round, while leaving the working columns open, prevents the accidental overwrite that makes people lose faith in a shared grid. Both features restrict editing rather than viewing, which is worth remembering before treating a protected range as a confidentiality measure.
One habit is worth more than any of the three. Give the sheet a single owner who reviews it at a fixed time each day, and say out loud that the sheet is the record. A tracker with no named custodian becomes a second opinion, and a second opinion is worth nothing during a scheduling conflict.
Where a shared grid stops holding
Both Google Sheets and Excel support several people editing at once. Excel calls it co-authoring and requires the workbook to be stored on OneDrive or SharePoint. It works well, and it does not solve the problems that actually break interview tracking.
A cell cannot be assigned. An interviewer's name typed into a column is a label. Nothing notifies them, nothing changes when the name is replaced, and nothing stops a second person editing the same row in the same minute. Both edits save, the later one wins, and the earlier one survives only in version history, where finding it means stepping through file revisions rather than looking at a single row.
Correspondence lives elsewhere. The row says the invitation went out on Tuesday. What it said, what the candidate asked in reply, and what was promised about the format all sit in one person's mailbox. When that person is away and the candidate replies with a question, nobody else can answer it, and the sheet gives no hint that a question is outstanding.
Access is all or nothing. A hiring manager who needs to see their own three interviews receives a link to a file containing every candidate for every role. Filtered views help the reader and protect nobody.
None of this makes a spreadsheet the wrong choice. For one recruiter running one role, it remains the fastest tool available. The point is that these three limits are structural, so they cannot be closed by adding columns or by trying harder.
Choosing the shape that matches the team
| Situation | What works | What gives way first |
|---|---|---|
| One recruiter, one role | A single sheet, interviews on one tab | Nothing, until a second person joins |
| One recruiter, several roles | Two tabs and a role filter | Reporting, once outcome values drift |
| Several interviewers updating the same schedule | A sheet with one strict owner per row | Double booking, and replies nobody else can see |
| Hiring managers restricted to their own role | Not a shared file | Confidentiality, on day one |
| Availability and applications arriving by form daily | A tool where each submission carries its own owner and state | Manual copying, and the typos it introduces |
The bottom two rows are where teams usually overcorrect, because the perceived alternative is a full recruiting platform with an implementation project attached. That is not the only option. What those rows actually require is that a submission arrives already carrying a state and a named owner, and that the reply stays attached to it, which is how a form tool with response management is built. Comparing what such a tool does after the form is submitted against the columns in the grid is a faster test than any feature checklist, and a short look at how the pieces fit together in practice settles it quickly.
Three questions decide it, and two yeses are enough. Does every scheduled interview need exactly one named owner at all times. Does correspondence need to be readable by somebody other than the sender. Does anyone need to see part of the schedule without seeing all of it.
Feedback is part of the schedule
The column teams add last is the one that changes decisions most: the date the interviewer submitted their written feedback.
Interview notes written four days later are shorter, more favourable to whoever was memorable, and influenced by what other people said in the meantime. Tracking the submission date makes the delay visible, and visibility is usually enough to shorten it. Pair it with a short structured form, the same questions for every candidate in the same role, rather than a free text cell. A notes column produces fragments that cannot be compared, which defeats the purpose of running the same interview twice.
Record no shows honestly and separately from rejections. A no show that is filed as a rejection hides a scheduling or communication failure that will repeat. Where a pattern appears in one round or with one interviewer, the tracker is the only place it will ever be visible.
Reschedules deserve the same treatment. The instinct is to edit the date in place, which is fast and destroys the only evidence that anything moved. Mark the original row as rescheduled and add a new row for the new time. The cost is one extra line. The return is that a candidate who has been moved three times is visible as three rows rather than hidden behind a single date that happens to be current, and that the person who has to apologise can see what happened without reading anybody's mailbox.
What to change first
Split the sheet into one row per interview and one row per candidate, then add separate dated columns for invitation sent and candidate confirmed. Those two changes catch nearly every no show and double booking that a grid can catch. When correspondence and ownership start to matter more than the flexibility of the grid, move the schedule somewhere every submission keeps its own owner and state, whether that is Halict or any tool built the same way.
Q1. Should an interview tracking spreadsheet have one row per candidate or one per interview?
One row per interview, with candidate details on a second tab. A candidate row has to grow sideways for every extra round, and it has nowhere to put an unplanned conversation. One row per interview makes counting last week's interviews a filter rather than a calculation, and nothing has to be redesigned when a fourth round appears.
Q2. What columns belong in an interview tracker?
Candidate, round, date and time, time zone, interviewer, format and location, invitation sent, candidate confirmed, outcome, and the date feedback was submitted. Invitation sent and candidate confirmed must be separate dated columns, because a proposed time and an agreed time are different things.
Q3. How do you stop a shared interview tracker going out of date?
Reduce the number of places the same fact is stored. Let the form create the rows instead of typing them, keep the calendar authoritative for times and the sheet authoritative for state, and give the sheet one named custodian who reviews it at a fixed time each day. A tracker with no custodian turns into a second opinion.
Q4. Can several people edit an interview tracker at once?
Yes. Google Sheets supports simultaneous editing, and Excel supports co-authoring when the workbook is stored on OneDrive or SharePoint. Neither assigns a row to a person or prevents two people editing the same row in the same minute, so the later edit silently replaces the earlier one.
Q5. How can a hiring manager see only their own interviews?
Not through a shared file. Google Sheets can protect a range and Excel can lock cells on a protected worksheet, but both restrict editing rather than viewing, so anyone with the link can read every row. Restricting what a person can see means keeping the schedule somewhere that controls access per record.
Q6. Why track the date interview feedback was submitted?
Because notes written days later are shorter and more influenced by what colleagues said in the meantime. A dated column makes the delay visible, which is usually enough to shorten it, and it pairs with a structured feedback form that asks every candidate for a role the same questions.