An interview question list becomes more useful when it tells you what to do next. Reading a familiar question can feel like preparation even when you cannot explain an answer without looking it up.
Try this workflow with a small set of questions for the role and technology you are targeting.
1. Capture what is actually known
For each question, record the company, technology, reported year and interview context when supplied. Leave missing information unknown. A question reported from one team does not describe every interview at that company, and a publication date is not necessarily an interview date.
Keep the original question separate from your interpretation. For example, “How would you improve this query?” needs more context before there can be one useful recommendation. The database engine, schema, query, data distribution and performance goal all matter.
2. Explain before opening an answer
Pick one question and explain your approach aloud or in a short note. A useful structure is:
- What do I need to clarify?
- What assumptions am I making?
- What approach would I try first, and why?
- What tradeoff or failure case should I mention?
- How would I check whether the approach works?
You do not need a polished speech. You need enough detail to reveal where your understanding stops.
3. Check evidence rather than familiarity
Compare the explanation with primary documentation, a small reproducible example, or a reviewed source. A popular answer can still omit assumptions. A plausible explanation can still apply to the wrong framework version.
For a technical question, write down what evidence would change your answer. If performance is involved, describe what you would measure before claiming an improvement. If behavior depends on a version or configuration, name it instead of treating it as universal.
4. Record one actionable gap
Avoid a vague note such as “learn SQL.” Prefer “I could explain the symptom, but could not describe how I would inspect the execution plan.” Your next session now has a concrete starting point.
Use a simple self-assessment:
- To practise: I have not attempted an explanation.
- Revisit: I found a specific gap or relied on prompts.
- Confident for now: I can explain my assumptions and reasoning, and have checked the important details.
This is your assessment, not a certification of correctness.
Copyable worksheet
| Field | Your notes |
|---|---|
| Question and source URL | |
| Company/role/year, only if known | |
| Clarifying questions | |
| Assumptions | |
| Proposed approach and reason | |
| Tradeoffs or failure cases | |
| Example, test or primary reference | |
| One gap to revisit | |
| Next action |
Start with three questions rather than a large checklist. The purpose is to produce three honest explanations and a few useful next actions—not to claim that you completed an entire technology.
A tool for keeping the shortlist
Disclosure: I am Raviindra Wadile, the creator of wasAsked. I built it to organize reported interview questions by company and technology and provide a browser-local saved/practice flow. You can browse without signing in. Community answers are available where contributors have supplied them; coverage is still developing.
The same workflow works in a notebook. The useful part is attempting an explanation, checking its assumptions and keeping a clear record of what to revisit.
Top comments (0)