Are Glassdoor interview questions accurate?
By Aaron Cao · Updated
Partly. They are self-reported by candidates and not verified, so individual questions go stale and vary by team, level, and interviewer. As a signal of format, difficulty, and tone they are useful. As a script to memorise, they are unreliable.
Where the data comes from
Glassdoor's interview section is built from candidate submissions. Someone finishes an interview, goes to the site, and writes down what they remember being asked, along with a difficulty rating and whether they got an offer. That is the entire pipeline.
Nothing in that chain verifies the question was actually asked, or asked in that wording. Glassdoor moderates for its community guidelines, and companies can respond to reviews, but there is no fact-check comparing a submission against an interview that only two people attended. The data is honest crowdsourcing, not a record.
The four things that make individual questions unreliable
You are trying to work out how much weight to put on a list of questions someone posted. This section names the specific distortions, so you can discount the right things instead of dismissing the whole source. There are four, and they compound.
- Recall. People write these up after the fact, from memory, often days later. Wording drifts even when the substance is right.
- Age. An entry has a date, and a question from several years ago may describe a process the company has since replaced entirely.
- Variance. A large company interviews differently by team, by level, by office, and by individual interviewer. Two accurate reports from the same employer can look nothing alike.
- Selection. Candidates with a strong reaction, good or bad, are likelier to post than the ones who had an ordinary hour and moved on.
Companies also rotate question banks, and some ask candidates directly not to share specifics. A widely circulated question is exactly the one most likely to have been retired.
What the data is genuinely good for
Read the entries in aggregate rather than line by line and they become useful. Across twenty reports for one company you can reliably see how many rounds there are, whether a take-home exists, whether the technical round is a live coding exercise or a discussion, roughly how hard people found it, and what the tone was.
Consider a concrete case. A candidate preparing for a product manager interview reads through a company's Glassdoor entries and finds that the exact questions differ every time, while nearly every report mentions a case exercise about prioritising a roadmap. The specific questions were noise. The presence of a prioritisation case was the signal, and it is what they prepared for.
That is the right way to read it: extract the shape of the process, then prepare for the shape.
Turning a question list into practice
The failure mode is memorising answers to listed questions. It produces a candidate who is fluent on four questions and blank on the fifth, and interviewers notice the difference in texture immediately.
A better use is as a topic list. Pull the recurring themes out of the entries, then practise answering around those themes in your own words, out loud, with follow-up questions coming at you. Running those topics through a session on the mock interview page rehearses the recovery when the question arrives in a form nobody posted.
Aaron Cao, founder of SubcueAI, built the mock interview flow around follow-up questions for this reason: a prepared answer that survives one question and collapses on the second is worse than no preparation, because it sets an expectation the rest of the interview then fails.
More on what practice actually transfers to a real conversation is on the mock interviews topic hub.