Job description to interview questions

Paste a job description and get 10–15 likely interview questions, grouped by the requirement they test, with a one-line approach and a short prep checklist. Free, no account.

What this page does

Paste a job posting. You get ten to fifteen interview questions that posting is likely to lead to, grouped by the skill or requirement they test. Each matched requirement is highlighted in the posting, and each question has a one-line approach: how to start the answer, not a script to memorize. Under that is a short checklist of what to prepare before you practice out loud.

The match runs in your browser. It looks for skills and requirement language, then maps those hits to a curated question list and to Luna’s public interview-question hub. You can copy the list or share the page. Role pages further down are the same tool with a sample posting already filled in, so you can see the shape of a frontend loop, a data science loop, or a manager loop before you paste your own.

How to read a job description

A posting is a compressed interview plan. The first paragraph is usually the product and the user. The bullets are the rounds. Read them as claims the company expects you to defend, not as a wish list of technologies to nod at.

Separate three kinds of lines. Must-have work is a verb plus an object: design the API, own the pipeline, coach direct reports, run the experiment. Tool lines are the names of languages, vendors, and frameworks. Culture lines are collaboration, ownership, ambiguity, and pace. Must-have work predicts the prompt. Tools predict the dialect of the answer. Culture lines predict the behavioral round, including when a recruiter calls them requirements.

Nice-to-have bullets are still fair game, but they are usually follow-ups. If a posting says Python is required and Spark is a plus, expect a Python question and treat Spark as a story you tell only if you have it. Do not invent a Spark migration to cover a plus line.

Watch for repeated ideas. If reliability shows up in three bullets, the loop will not be satisfied with one sentence about monitoring. If the word “own” shows up after launch, they will ask what you did when the launch was over. If every bullet is a tool and none is a user, ask the recruiter what the interview actually is before you spend a week on the wrong half.

Map a requirement to a story

Take one highlighted line and write the story in four beats. Situation in a sentence. Your actions, longer than the situation. The result, with a number or a clear tradeoff. The limit: what that result does not prove. The approach line under each question on this page is a hint about which beat interviewers listen for.

Here is a worked example. The posting says: “Design REST APIs that clients can retry safely, and model the data in Postgres.” That is two requirements, not one. The API line wants a request, an error, and what a second try should do. The Postgres line wants the grain of a table and a migration that does not freeze readers. A single story about “building the backend” will blur both. Split them.

For the API, a usable story is a client that timed out and retried, created a duplicate, and forced you to add an idempotency key. The result is the duplicate rate after the change. For the table, a usable story is a migration in two phases and the query you refused to let get slow. If you only have one of those stories, say so. Interviewers can hear a borrowed incident.

Do the same for a behavioral line. “Partner with stakeholders” is not a prompt to list meetings. It is a disagreement. Name the objection, what you changed, and what you refused to take over. The highlight in the posting is there so you can point at the line while you practice and notice when your story has drifted into a different job.

What to prepare, and what to skip

The checklist under the questions is intentionally short. It asks you to mark the requirements you cannot yet support, to rehearse the specific artifact that role needs (a query, a screen, a pipeline, a coaching conversation), and to say each answer out loud once in under two minutes. Out loud is the part people skip. A story that looks fine in a doc often runs long or goes vague the moment you hear yourself.

Skip collecting a second list of fifty generic questions. Skip rewriting your resume into the posting’s adjectives. Skip practicing a company values poster unless the posting or the company page actually ties a value to a decision. If you want more prompts after this list, follow the link on each group into the interview-question hub — Google coding, Amazon system design, Airbnb role questions, and the rest — and practice the theme, not a rumor about a date.

A small example

Imagine a short frontend bullet: “Ship React and TypeScript UI, including loading and error states, and treat keyboard access as part of the feature.” Three questions fall out. Where does state live, and what is not state? What does the screen show when the request fails? What should a screen reader announce on the primary action? The approaches are short on purpose. State the user action before the hook. Name the error the UI can show. Tab the flow and describe the focus move. You can practice those three in an evening. You cannot honestly practice every component pattern in the same evening.

A manager bullet works the same way. “Coach direct reports who ship but are not growing” is not a question about your management philosophy. It is one person, one piece of feedback, and a change in the work. If the posting also says you will stay close to system design, add one technical question so you are not surprised when the loop checks that you can still talk about the system.

Limits, honestly

The browser match is a strong baseline, not a mind reader. It highlights phrases it knows — React, an SLO, a PRD, a warehouse pipeline — and falls back to broader “how you work” questions when a posting is vague or uses language outside the map. Unusual roles still get a useful list, then you should edit it. If a line matters and it is not highlighted, that line is your extra story.

Optional sharpening sends the posting to Luna’s model and rewrites questions for the requirements already found. The highlights stay put, because those come from the text. If the model is unavailable, the on-page list is the product. No account is required either way.

Use the questions as practice. In a real interview, follow the rules of that interview. A prepared story is yours to tell. A script you do not believe is how people get stuck.

Popular roles

Each page is the same tool with a sample posting filled in, the likely questions already rendered, and links into the company question hub.

FAQ

Will these be the exact questions in my interview?

No. The list is a practice set inferred from the requirements in the posting. It is not a leaked question bank and not a claim that an interviewer will use this wording. Use it to see which lines in the job description are likely to become a coding prompt, a design prompt, or a story.

How do I read a job description for interview signal?

Read the product first, then the verbs in the bullets. Languages and data structures point at a coding screen. Services, latency, and scale point at design. Ownership, stakeholders, and conflict point at behavioral rounds even when they are listed as requirements. Tool logos are weaker signal than the work you are expected to do after launch.

How do I turn a requirement into a story?

Copy the line. Pick one project that matches its verb, not your whole career. Spend one sentence on the situation and most of the answer on what you did. End with a result the user in that line would care about. If you cannot match the line, say so and name an adjacent skill you have actually used.

How many questions should I prepare?

Ten to fifteen is enough for one posting. Fewer and you will skip a requirement that is sitting in the bullets. More and you will memorize openings you cannot defend. This tool stops in that range and groups them so you can see which requirement still has no story.

Do I need an account?

No. The first list is built in your browser from the posting you paste. Nothing is required to copy it or to open a role page. Sharpening the wording with Luna’s model is optional, rate limited, and not required to use the page.

How is this different from a company question list?

Company pages such as the Google or Amazon interview questions collect prompts people associate with that employer. This tool starts from a specific posting, highlights the lines that triggered each group, and links across to the company or category page when you want a wider set. Use both: the posting for what this loop is likely to emphasize, the company page for the shape of that company’s rounds.

Can I practice the questions with Luna?

Yes. Luna is a side panel for interview practice: you hear a question and work from notes you can defend. The checklist on this page is the short version of what to have ready. When you want to say the answers out loud, open Luna and run the questions one at a time. The tool stays free either way.