Vibe coder or product engineer domain knowledge interview questions

As asked

Explain what a context window is in an LLM, how it affects what you can build, and what product engineering decisions you make differently depending on whether you have 8k versus 128k versus 1M token contexts.

Sample answer outline

The context window is the maximum amount of text the model can attend to in a single call, including both the input and the output. With 8k tokens you need careful chunking and retrieval to handle long documents. With 128k tokens you can fit most single documents but still cannot load an entire codebase. With 1M tokens you can fit large repositories but the cost per call scales with input tokens, so you still want smart retrieval for cost reasons. Product decisions affected: chat history truncation strategy, document chunking and retrieval for RAG, whether to use an embedding search step at all, and latency since time-to-first-token grows with context length. A strong answer also notes the lost-in-the-middle problem: models attend less reliably to content in the middle of a very long context.

Expect these follow-ups

• How do you handle a chat product where conversation history grows beyond the context window over time?

As asked

Walk me through the minimum accessibility bar you would hold a product to before shipping. What tools do you use to check it, and what are the two or three issues that cause the most user harm that teams routinely miss?

Sample answer outline

The minimum bar is WCAG 2.1 AA: sufficient colour contrast (4.5:1 for normal text), all interactive elements reachable by keyboard with visible focus indicators, images with meaningful alt text, form inputs with associated labels, and no content that flashes more than 3 times per second. Axe DevTools or Lighthouse catches the mechanical checks. The two issues teams miss most: focus management after modal open or close, where focus should move into and out of the modal, and error messages that announce via aria-live so screen reader users hear them. Interactive components built from divs and spans rather than native HTML elements is the root cause of most keyboard and screen reader failures.

Expect these follow-ups

• How do you test screen reader behaviour without owning a physical assistive device?

As asked

You are building a product that makes LLM API calls on every user interaction. Walk me through how you estimate the monthly cost before launch and what levers you have to control cost as usage grows.

Sample answer outline

Estimate: count average input tokens per call (system prompt plus context plus user message), average output tokens, multiply by the model's per-token price, and multiply by expected monthly call volume. For a feature with a 2000-token system prompt, 500-token user input, and 800-token output at $3 per million input tokens and $15 per million output tokens, each call costs about $0.02 (input: 2500 tokens at $3/1M = $0.0075, output: 800 tokens at $15/1M = $0.012, total roughly $0.02). At 100k calls per month that is around $2000. Cost levers: use a smaller model for simple tasks and a larger one for complex tasks, cache system prompts with prompt caching if the provider supports it, reduce system prompt size, truncate context history aggressively, and add output token limits. A strong answer also mentions logging token counts per call from the API response to detect outlier calls.

Expect these follow-ups

• How would you build a cost attribution dashboard so you know which features are the most expensive per user?

As asked

Walk me through the technical SEO concerns that a product engineer needs to handle, not an SEO specialist. What breaks SEO in a Next.js app that an engineer ships without thinking about it?

Sample answer outline

The most common mistakes: duplicate content without canonical tags when the same page is reachable from multiple URLs, missing or incorrect metadata from neglecting the Next.js Metadata API, client-side rendering of content that Googlebot does not execute in time to index (though Googlebot does run JavaScript now, delay matters), broken internal links from unchecked route changes, and missing structured data for content types like articles or products that unlock rich snippets. Other fundamentals: a sitemap.xml that includes all indexable pages, robots.txt that does not block crawlers unintentionally, and page speed since Core Web Vitals are a ranking factor. A strong answer also mentions that noindex should be set deliberately on thin or duplicate pages to prevent them from diluting crawl budget.

Expect these follow-ups

• How do you audit a Next.js app's SEO health without access to Google Search Console data?

As asked

Walk me through the GDPR requirements that actually affect what you build as a product engineer, not what a lawyer handles. What data handling decisions do you need to make when building a user profile feature?

Sample answer outline

Data minimisation: only collect what you need for a specific purpose. The user profile should not store fields you do not use. Right to erasure: you need a delete account flow that actually deletes or anonymises PII from the database, not just soft-deletes the account. Right to portability: users can request a data export in a machine-readable format like JSON or CSV. Lawful basis: for most product features this is legitimate interest or contract; for marketing emails it is explicit consent. Practical implications: pseudonymise analytics events with a hashed user ID rather than a raw email, be careful about logging PII in application logs which may be retained indefinitely, and for EU users ensure data is stored in EU-region servers if that is what your DPA says.

Expect these follow-ups

• How do you build a data deletion flow that propagates through third-party services like Stripe and email providers?

As asked

Your team is splitting a monolith into a web app and a mobile app sharing a type library. Should you use a monorepo or separate repos? Walk me through the concrete engineering tradeoffs.

Sample answer outline

A monorepo lets you make an atomic change across the web app, mobile app, and shared library in a single commit, guaranteeing they stay in sync and eliminating the versioning ceremony of publishing an npm package. The cost is tooling complexity: you need Turborepo or Nx for efficient builds, and CI must be smart enough to only run affected package tests. A polyrepo with a published shared library is simpler to operate for each repo in isolation but requires careful versioning discipline and coordination when the shared library has a breaking change. For a small team with two apps sharing a library, a monorepo wins on simplicity of day-to-day development. A strong answer also notes that monorepo does not mean monolith: deployment can still be independent per package.

Expect these follow-ups

• How do you handle a security patch in a shared library in a polyrepo setup with 5 consuming apps?