Send a Hiring Manager the Scorecard Without a Login

A placement cell coordinator we spoke with in August described her actual workflow for getting a hiring manager’s sign-off: she would screen-record her own laptop scrolling through a candidate’s HireQwik evaluation, narrate over it in a two-minute video, and send that video over WhatsApp, because the hiring manager sat at a client company two states away and had never logged into HireQwik in his life, and never would for one candidate.

That is not a workflow anyone designed. It is what happens when the only way to show someone an interview record is “log in and look,” and the person who needs to look is not, and will never be, a HireQwik user. Sharing an AI interview scorecard with a hiring manager should not require provisioning them an account for a five-minute read. On August 26 we shipped a feature built specifically to remove that step: Share scorecard.

What Share scorecard actually mints

From Interview Details, a “Share scorecard” action creates a link at /scorecard/<token>. That link opens directly, no email verification step, no password, no account creation screen. Whoever has the URL can view the record it points to.

This is a genuinely different mechanism from most “share with a colleague” features, which usually mean “invite this person as a user with limited permissions.” HireQwik’s version skips the account entirely, because the actual ask, in the workflow above, was never “give this hiring manager a HireQwik seat.” It was “let him see this one candidate’s evaluation for five minutes and make a call.”

What is actually on the page

The shared page carries the verdict, the scored dimensions with the reasoning behind each one, any notes or flags a recruiter attached, the speech-quality read, a short-lived link to the video, and the full transcript. It is the same evidence a recruiter would see inside the product, not a summarized or watered-down version built for outside eyes.

That completeness is deliberate. A hiring manager deciding whether to override a Go or push back on a No Go needs the actual basis for the score, not a headline number. Workable’s own guidance on documenting interview feedback makes the same point from the opposite direction: a vague “not a fit” note from one interviewer is what breaks recruiter-hiring-manager alignment, and a scored, evidence-backed record is what fixes it. If the shared page only showed a verdict tier with no reasoning attached, it would recreate the exact problem our own scorecard-reading guidance warns about: a score is an opinion with a number attached to it unless the evidence behind it is visible too.

It is a capability link, not a login, and that distinction matters

Here is the part we want to be plain about rather than let a reader assume: this is not per-viewer access control. It is what the W3C’s technical architecture group calls a capability URL: the link itself is the credential, and possessing it is what grants access, the same pattern behind a password-reset email or an “anyone with the link” cloud-document share. Anyone who has the URL can open the scorecard until it is regenerated. We are not implying, anywhere in the product, that only the intended hiring manager can open it, because that is not how it works.

Practically, this means the link should be handled the way you would handle the underlying evaluation itself: sent over a channel you trust, to the person you intend to see it, and not pasted into a public Slack channel or a group chat with people outside the hiring loop. The product’s job is to make the link easy to generate and easy to kill. Whose hands it ends up in after that is still a judgment call, the same judgment call that already applies to a screen-recorded WhatsApp video, just with a cleaner mechanism behind it.

Why not just export a PDF

The obvious alternative is a PDF export: generate a document, attach it to an email, done. We considered it and decided against it as the primary path, for reasons that only show up once you think about how a scorecard actually gets used after it’s sent.

A PDF is a snapshot. If a recruiter adds a note to the interview after sending it, or a flag changes, the PDF a hiring manager is looking at is already stale, and there is no way to tell from the document itself that it’s stale. A PDF also has no natural revoke: once it’s emailed, it exists as a file on someone’s laptop indefinitely, forwarded, saved, printed, outside any control the product has. And a video short link inside a shared PDF, if the export even includes one, tends to expire on its own schedule, disconnected from whether the underlying interview record has changed.

A live link avoids all three problems by construction. It always shows the current state of the record, because it isn’t a copy, it’s a view. It can be killed in one action. And because it is generated per candidate rather than exported and forgotten, there’s a natural moment, right when a recruiter is done needing to share it, to regenerate and cut it off.

A second use case: reviewing across teams without cross-team accounts

The hiring-manager case is the obvious one, but the same mechanism handles a second scenario we didn’t originally design for: a client’s own HR team wanting to spot-check a vendor’s screening quality without HireQwik provisioning them a login into someone else’s account. A share link answers “show me the evidence behind this specific call” without answering the much bigger, much riskier question of “give this outside team standing access to our screening data.” Those are different requests, and conflating them by defaulting to an account invite for every ad hoc review is exactly the kind of access-control sprawl that makes an IT team’s audit of who-can-see-what harder every quarter, not easier.

Why this has to work on a phone, not just a laptop

The placement cell coordinator’s WhatsApp workaround was, underneath the awkwardness, solving a real constraint: the hiring manager she needed a decision from was reachable on a phone between meetings, not sitting at a laptop with time to log into anything. A share link that only rendered well on desktop would have fixed the account problem and left the actual access problem untouched.

The shared page is built to be read on a phone screen with one thumb, because that is realistically how most of these get opened, a link dropped into WhatsApp or email, tapped between a client call and a status meeting, not a browser tab kept open on a desk. The transcript and the scored dimensions are the parts most worth reading in that five-minute window, so those render first and don’t require scrolling past a video player that hasn’t finished buffering on a patchy connection. This sounds like a small implementation detail. It is the difference between a feature that gets used the way it was designed for and one that quietly reverts everyone back to the screen-recording workaround because the “proper” version is annoying to use standing in a hallway.

Why this shipped narrow instead of broad

A more elaborate version of this feature could plausibly do more: track when a link was opened, show a countdown to expiry, let a recruiter set a custom validity window per share. We would rather ship a narrow feature that does one thing honestly, hand a recruiter a link, let them kill it, than a broad one with privacy and access-control edges we haven’t fully thought through yet. Tracking exactly when a specific external person opens a link, for instance, is a materially different posture than simply making evidence available to whoever holds the URL, and it deserves its own deliberate design pass rather than getting bundled in as a side effect of shipping something else. Regenerate-to-revoke is the one control we were confident enough in to ship now; anything further is a decision for a later version, made on its own merits, not assumed here.

Revoking access: one action, every old link dies

If a link needs to stop working, regenerating it invalidates every previously issued share for that candidate at once. There is no per-recipient revoke list to manage, no tracking which of three hiring managers still has which copy of a link. Generate a new one, and the old ones stop resolving, full stop.

This is the same shape of control that makes the WhatsApp opt-out mechanism trustworthy: a single, unambiguous switch rather than a set of exceptions someone has to remember to maintain. A feature that is easy to share is only genuinely useful if it is at least as easy to un-share.

The allowlist boundary and the 404 that never confirms anything

Two smaller details are worth knowing if you are the kind of TA lead who checks how a feature actually behaves rather than taking a description on faith. First, the public page is built from an allowlist of named fields, not a raw dump of the candidate’s record, and that boundary is pinned by a test on our side, so a field nobody intended to expose cannot leak through by accident. Second, every failure mode, an invalid token, an expired one, or one that was already revoked, returns the same generic response. You cannot use the URL pattern to probe whether a given scorecard exists at all; a dead link tells you nothing.

We will not publish the token format or how long a link stays valid by default, on purpose. The mechanism is transparent; the specific numbers that make it harder to guess or brute-force are not the part we think is useful to share publicly.

Where this fits into an actual decision

The scorecard link is not a standalone feature so much as the last step of a chain that starts earlier in the funnel. A candidate lands in the On Hold band because the verdict sat in the middle, not confidently Go or No Go. A recruiter needs a second opinion before the decision deadline passes. Instead of describing the interview over a call, or exporting a PDF nobody will open, the recruiter shares the link, the hiring manager opens it on their phone between meetings, and the decision gets made with the actual evidence in front of them, not a summary of it.

It is also the natural next step out of the Screener vs reality outcome data: when a hired_no_go pattern shows up on a JD, the fastest way to understand what the screen actually saw, and show a hiring manager the same thing, is this link, not a meeting. That is a genuinely different use from a never-screened hire, where there is no HireQwik interview to share in the first place, and from the separate question of whether a hired_no_go pattern should ever be allowed to move a threshold on its own, which this feature deliberately has nothing to do with, it only ever shows evidence, never changes a score.

What this doesn’t replace

Worth being clear about the edges of this, too. A share link is built for one specific job: getting a specific person, for a specific candidate, the evidence they need to weigh in. It is not a substitute for giving a genuine collaborator, someone who reviews scorecards across many candidates every week, an actual HireQwik seat with proper permissions. If a hiring manager is opening five or six share links a week for the same role, that’s a signal the right fix is an account with scoped access to that JD, not five or six more capability links to track. The feature is deliberately narrow, and narrow tools solve the case they’re built for well and other cases badly; reaching for the account-based path when the actual need is recurring, not one-off, is still the right call.

The take

The alternative to a proper share link is not “nobody sees the evaluation.” It is a screen recording over WhatsApp, a forwarded PDF export, or a hiring manager who just takes the recruiter’s word for the verdict because getting an actual account felt like too much friction for one candidate. None of those are more secure than a revocable link with an allowlisted payload; they are just less visible about being informal. Talk to us if you want to see how a shared scorecard looks on your own candidates.