PM Vibe Coding Interview: Build a Small Prototype and Defend Your Product Decisions

A PM vibe coding interview is best prepared for as a build-test-explain exercise: choose one user problem, make a small prototype demonstrate the intended promise, test a broken state, and defend the product decisions. A polished screen is not enough if you cannot explain what happens when the happy path fails.

The label is not a universal employer specification. Confirm whether your invitation actually includes a prototype exercise, which AI tools are permitted, and what must be delivered. This article presents an original local rehearsal, not a verified Meta round, proprietary prompt, or authorization to use AI during an assessment.

What “vibe coding” means in this preparation exercise

Vibe coding here means using an allowed AI assistant to help produce a runnable prototype from natural-language instructions, then inspecting and revising the result. The PM still owns the user problem, product scope, acceptance criteria, and explanation of limitations. Generated code is proposed implementation, not independent proof of correctness.

Third-party context: IGotAnOffer's preparation article discusses AI-assisted PM prototyping. A December 2025 Maven session discusses “Product Sense with AI.” These sources establish preparation commentary, not an employer-wide guarantee about tools, timing, availability of a coding round, or scoring.

We did not verify a public official policy and two comparable current candidate reports that establish one universal prototype format. The scope is therefore practical rehearsal. Do not treat a traditional product-sense interview, an AI brainstorming discussion, and a live runnable-prototype exercise as interchangeable.

If the invitation says no AI, prepare and perform within that boundary. If it permits a supplied tool, use that tool rather than assuming permission for another assistant, browser extension, account, or external service.

Clarify permissions and deliverables before the first prompt

Resolve what the interviewer expects to see: a working user flow, a clickable mock, code, a screen recording, or a verbal defense. Ask whether the prototype may use local fixtures, whether network access is available, and whether persistence is required. These answers materially change the smallest coherent build.

Keep data boundaries explicit. Use invented users, reservations, and content. Do not upload customer records, private employer code, API secrets, or a real account's exported data to a tool merely because the exercise involves AI. A convincing prototype does not require a real payment or production deployment.

Also identify the fallback if the assistant or preview environment fails. You can still explain the state model, show the completed portion, and identify the remaining test. A backup should preserve honest evidence, not hide a nonworking result behind a static screenshot.

For the rehearsal below, the environment is a local HTML and JavaScript page with no backend, login, external API, or durable storage. Its behavior is intentionally narrower than a production booking service. Reloading resets it, which must be visible rather than discovered after the demonstration.

Original product brief: reschedule a community workshop

Use this fictional practice case: a user already has a reservation for a community workshop at Tuesday 14:00. They want to move it to Tuesday 15:00. Tuesday 16:00 is full. The user must not lose the existing reservation merely by exploring another time.

The first user promise is: “I can choose a new time, inspect it, and either confirm an available change or leave my existing reservation intact.” That promise is narrow enough to build and important enough to test. It does not require recommendations, social sharing, payment, multiple calendars, or an invented AI chatbot.

Compare a rescheduling flow with a separate cancellation-and-rebooking flow. The second is easier to sketch but can expose the user to losing the original reservation before obtaining another. For this exercise, choose a guarded replacement because preserving the current reservation is central to the stated need.

Define the non-goals openly. We are not proving identity, real-time inventory, concurrent booking safety, timezone handling, or server persistence. Those are genuine production requirements, not problems solved by a convincing front end. Explain which would become essential before a real launch.

The prototype needs a current-reservation display, a labeled time selector, a preview, confirmation, cancellation, and understandable failure feedback. Add failure controls only for rehearsal so the interviewer can see an unavailable slot or connection. Label those controls as local simulations rather than product features.

Build a state contract before generating the screen

Separate the current reservation from the selected candidate. Selection changes the candidate only. Confirmation replaces the current reservation only after the applicable checks pass. Cancellation clears the candidate and keeps the current reservation.

A minimal local state includes reservation, selected, status, error, and a committed-change counter used for testing. A real service would need a stronger authoritative state contract, but the separation already prevents a common prototype defect: treating a dropdown change as a completed booking.

The allowed local transitions are straightforward. With no selection, confirmation produces a useful error and no committed change. With an unavailable selection, failure leaves the current time unchanged. With an available different time, confirmation commits one replacement and clears the candidate. Selecting the current time does not count as a new change.

Use semantic controls and explicit labels. Keep the status message readable and exposed through a status region so success is not communicated only by color. Keyboard access matters because a mouse-only prototype hides an avoidable usability limitation, even in a small exercise.

MDN's form-validation guidance distinguishes useful client-side feedback from server-side validation. The local controls improve the demonstration; they do not authorize or secure a production reservation.

Prompt revisions should correspond to a product decision

Start with a bounded instruction such as: “Build a local rescheduling mock for one existing workshop reservation. Keep the current reservation separate from the candidate time. Include confirm, cancel, full-slot feedback, and no external calls. Use fictional fixtures and label the mock's limitations.”

Inspect the generated output before asking for aesthetic refinements. Does choosing a time silently replace the reservation? Does Cancel actually preserve the previous value? Can the user understand which state is authoritative? A prompt that asks only for a “beautiful booking dashboard” leaves the central product behavior unspecified.

Here is an illustrative revision log, not a claim about a live hiring session:

• Initial scope: one existing reservation and one replacement flow; decline payments and calendar synchronization.
• State repair: keep candidate selection separate from committed reservation; Cancel must not erase the existing booking.
• Failure repair: check availability at confirmation, not only when rendering options; show why the change failed.
• Verification repair: clear the candidate after a successful commit so repeated confirmation cannot create a second local change.

Explain why each revision exists. “I changed the prompt until it looked good” is less informative than “the first state design could overwrite a reservation before confirmation, so I required a separate candidate and a guard.” Keep a short record of the decision and test result, not an unfiltered transcript of every prompt.

Broken-state demonstration: the slot becomes unavailable

Consider a deliberately incorrect implementation sketch:

reservation = selected;
if (!available(selected)) showError();

The assignment happens before validation. Even if the screen later displays an error, the existing reservation has already been overwritten. Showing an error is not the same as preserving the user's state.

The local repair checks the candidate before replacing the reservation. If the slot is missing, full, or the simulated connection is unavailable, the function returns an error state while retaining the existing time. A successful replacement clears selection and increments the local committed-change count once.

Now select Tuesday 15:00, then use the rehearsal control to make that slot unavailable before confirming. The expected outcome is an understandable error and Tuesday 14:00 still shown as the current reservation. This is stronger evidence than simply selecting Tuesday 16:00, whose full status was already known when the page rendered.

The local check does not solve a server race. In production, availability can change after a browser check, and the server must enforce the relevant reservation and replacement rules. OWASP's input-validation guidance likewise treats client validation as insufficient for security. Say what the prototype demonstrates and which authoritative checks remain unbuilt.

Acceptance tests: what actually ran locally

For this article, we executed 12 checks against the original local state module. They cover initial-state preservation, selecting without committing, cancelling, confirming without selection, a full slot, an unknown slot, simulated connection failure, availability changing before confirmation, one successful commit, repeated confirmation, selecting the current slot, and cancelling after failure.

These tests passed for the fixture. They establish local transition behavior only. They do not prove network correctness, authentication, multi-user concurrency, durable storage, a production accessibility audit, or integration with any employer's assessment tool.

The important acceptance conditions can be stated without code:

Action or failure	Required visible outcome
Select a candidate time	Preview changes; current reservation remains intact.
Cancel before confirmation	Candidate clears; current reservation remains intact.
Confirm a full or newly unavailable slot	Explain failure; do not replace the existing reservation.
Confirm while the mock connection is unavailable	Explain the failed change and preserve the existing reservation.
Confirm an available different time	Replace once, clear the candidate, and show confirmation.

During a demonstration, show one ordinary path and one consequential failure. Then reset and let the reviewer choose a condition. Do not silently change fixtures to avoid a case you cannot handle. If a test fails, explain the violated promise before discussing implementation details.

A sixty-minute rehearsal budget, not an employer timer

Use a self-imposed practice budget of five minutes for permissions and setup, ten for the user promise and acceptance criteria, twenty for the first working flow, fifteen for failure tests and repair, and ten for demonstration and defense. These intervals total 60 minutes; they are not a reported company limit.

If the first build overruns, reduce optional surface area before sacrificing verification. A smaller coherent flow with an exposed failure can demonstrate more judgment than three incomplete screens. Do not remove cancellation, failure feedback, or state preservation while continuing to claim the original promise.

Keep a visible list of what was deferred and what is essential before production. That list should distinguish optional product expansion from missing safety foundations. Real server authorization cannot be treated as cosmetic polish simply because the rehearsal uses local fixtures.

Practice without a perfect tool response. Ask for one implementation, inspect it, and make a targeted correction yourself or through the permitted assistant. The useful skill is maintaining product ownership through imperfect generation, not finding a magic prompt that never needs review.

Defend the product decisions after the demo

Begin the defense with the user promise and the trade-off: “I optimized for a safe, understandable change to an existing reservation. I deferred integrations so I could test selection, cancellation, and unavailable-state behavior.” Then show the evidence instead of repeating feature names.

Explain the limit of your metrics. For a real product, you might measure acknowledged successful replacements among independently defined eligible attempts, alongside unwanted cancellations and failed attempts. The local counter proves only that the fixture committed once; it does not establish adoption, satisfaction, or business value.

Expect a changed requirement. If the interviewer asks for timezone support, identify the representation and display contract before adding a dropdown. If they ask about two users taking the last slot, explain why authoritative concurrency belongs to the backend. If they ask for reload persistence, state that the current mock resets and propose the smallest appropriate next layer.

The strongest closing answer names what you learned from a failed state and what you would test with actual users. Do users understand that their old reservation remains safe? Is the error actionable? Would another workflow solve the need better? A working prototype is evidence for a product discussion, not a substitute for discovery.

Sources and Further Reading

• IGotAnOffer PM vibe coding preparation: third-party commentary, not a universal employer process.
• Maven Product Sense with AI session: dated December 2025 discussion; does not grant assessment permissions.
• MDN client-side form validation: client feedback and server-validation boundary.
• OWASP input-validation guidance: authoritative validation expectations, not proof that this mock is production secure.

Checked October 6, 2026. All users, times, reservations, and prompt revisions are fictional. Only the local fixture was tested; no real booking, employer assessment, or backend integration was executed.