HireScope

Why I built it

When I prepared for interviews, the feedback I got on my resume was always about fonts, length and keywords. None of it matched what actually happened in the room. A good interviewer does not care that you wrote "scalable". They pick the one line that sounds impressive and ask: what exactly did you decide, and what broke?

So I wanted a tool that reads a resume the same way. It should tell apart "I built" from "I helped with", point at the claims that sound big but have no detail, and then let you practise answering those exact questions out loud before a real interviewer asks them.

Who it is for

• Candidates who want an honest read of their resume, a fit check against a real job post, and practice on their weak spots.
• Hiring teams who post a job, share a link, and see applicants ranked by the evidence in their resume instead of by keywords.

How it works

1. Reading the resume

The browser uploads the file directly to S3 using a link that works for 5 minutes, so the file never passes through my server. Files over 10 MB are refused. The server then pulls the text out of the PDF or DOCX and sends it to the model with a long, strict brief.

That brief is really the product. A few of its rules:

• Every point must come from something actually written in the resume. No invented numbers or companies.
• "I designed" counts for more than "I worked on".
• A score of 90 or more needs direct, senior-level evidence. A score under 40 means the resume does not say much, not that the person is bad.
• Every risky claim comes with the exact follow-up question a sharp interviewer would ask.
• No filler words like "robust" or "seamless", and no generic praise.

The report shows a short summary, skill depth, the strongest evidence with a quote from the resume, the risky claims, and what to prepare.

2. Checking fit for a job

Paste any job description and the resume is scored against it, one requirement at a time. If a company posted the job with its own list of must-haves, the model has to return exactly those requirements, in the same order. If you paste a random job post, the model pulls out 4 to 7 key requirements itself.

The verdict is one of three: Strong Fit, Possible Fit or Not a Fit. A weak must-have pulls the score down hard. A weak nice-to-have does not. The resume read and the fit check run at the same time, and if only the fit check fails, you still get the resume report.

3. The spoken mock interview

You press record, answer out loud, and press stop. The audio goes to Deepgram for the text, the model writes the interviewer's next line, and Deepgram reads it back to you. If the microphone is blocked, you can type your answers instead.

There are three interviewers to pick from: a founder checking ownership and comfort with chaos, a senior engineer pushing on design and failure cases, and a hiring manager asking about past decisions. Or the interview can focus on one gap found in your resume. The interviewer asks one short question at a time, pushes back when an answer is vague, and wraps up after about six to eight exchanges.

At the end, the full transcript is scored. The debrief has to quote what you really said, and it judges substance over talking a lot. If you barely answered, it says so instead of making up depth.

4. The hiring side

A company posts a job with must-have and nice-to-have requirements and gets a share link. When someone applies through that link, their fit report is added to the job automatically. Applicants move through four stages: New, Reviewing, Shortlisted and Archived. I kept it to four on purpose. A v1 does not need an eight-column hiring board.

Key decisions

What can go wrong

Status