The best interview-question list begins with the actual role. A long generic list can feel productive while leaving the employer's central requirements untouched. Use the job description as a map: identify what the person will do, what evidence you can offer, and what you still need to learn. Then choose a small set of questions that tests those points.

This is an editorial preparation method, not a prediction of what a particular employer will ask. Reported company questions on wasAsked offer context, but teams, interview rounds and hiring needs can change.

Step 1: separate responsibilities from tool names

Copy the posting into a private working note. Mark the tasks you would own, such as designing APIs, resolving production incidents or working with customers. Mark the required tools separately. “SQL” might mean writing queries, interpreting plans, managing transactions or explaining data models. A question about a tool is useful only when it tests the work behind the word.

For each responsibility, write one likely interview question. “Improve API performance” could become “How would you identify whether a slow endpoint is blocked by the database, downstream service or application code?” That question asks for a decision process, not a memorized definition.

Step 2: build a three-column skill map

  1. Requirement: quote the relevant responsibility in your own short words.
  2. Question: write one conceptual and one scenario question.
  3. Your evidence: note a real project, exercise or learning example that lets you answer honestly.

For a junior role, evidence can be a tested course project. For an experienced role, the interviewer may expect trade-offs, constraints, mistakes and verification. Keep those standards separate; do not pretend a classroom exercise is a production incident.

Step 3: rank questions by relevance and uncertainty

Start with requirements that appear repeatedly or are described as essential. Next, give attention to a requirement where your explanation is weak. Leave low-relevance trivia for later. A useful first shortlist is about ten questions: several core responsibilities, a few behavioral examples and a few questions you will ask the employer. The number is a planning aid, not a market statistic.

For a .NET role, you might choose API design, asynchronous I/O, data access, testing and deployment. For a customer-facing role, you might choose problem diagnosis, communication under pressure, collaboration and a measurable improvement you actually made. The shortlist changes with the job.

Step 4: rehearse aloud before reading an answer

Give a direct answer, explain your reasoning, name an assumption, describe an example and say how you would check the result. Record where you pause because you lack knowledge. Those gaps become a targeted study list. The Interview Challenge can structure repeated practice with published questions; its self-ratings are reflection tools, not automatic grades.

A small worked example

Suppose a posting says “build reliable APIs that integrate with external services.” A weak practice question is “What is an API?” A stronger one is “How do you handle a downstream timeout without hiding failure or retrying forever?” Your answer can discuss timeout budgets, cancellation, idempotency, observability and a user-facing failure path. If you have not implemented that in production, explain the design you would test rather than inventing experience.

Keep the shortlist current

After each mock interview, remove questions you can explain comfortably and replace them with the next gap. Keep company reports distinct from universal advice. Browse interview questions by technology, then use the role's actual wording to choose what deserves your time.

Source and further reading: Harvard FAS interviewing guidance discusses matching experience to job requirements and researching the employer. The ranking method here is an original preparation worksheet for wasAsked readers.