Frontend · Interview

How to Interview a Frontend Candidate Whose Resume Screams 'Over-Packaged'

By 掘金安东尼 · Jul 4, 2026

Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Small and medium-sized companies hire for immediate delivery, not long ramp-up. This playbook gives interviewers a repeatable method to expose whether a candidate's dense tech-stack claims reflect real problem-solving or just tutorial-level exposure, reducing the chance of a costly mis-hire.

Summary

A frontend interview manual built around a single candidate resume loaded with modern terms: Vue3, TypeScript, AntV X6, WebSocket, RAG, and streaming AI. The resume is worth an interview but triggers immediate skepticism—too many technologies for one undergraduate, no work timeline, and AI claims that often inflate frontend responsibilities. The playbook walks through three interview rounds designed to surface what the candidate actually built versus what they only integrated.

The HR round filters for motivation and project ownership with direct questions like "Which modules were not done by you?" The technical round abandons algorithm trivia for real business problems: designing approval-node TypeScript types, explaining WebSocket reconnection logic, and defending a claimed LCP improvement from 3.7s to 1.8s. The supervisor round tests whether the candidate can ship an MVP when requirements are incomplete and locate a production white-screen without blaming the backend.

Every question targets a specific risk—inflated AI claims, shallow TypeScript usage, or performance metrics the candidate cannot reproduce. The underlying argument is that small-company hiring should optimize for delivery risk, not keyword matching, and that honest boundary-drawing in a resume earns more trust than claiming ownership of everything.

Takeaways

— A resume dense with Vue3, WebSocket, RAG, and Agent keywords from an undergraduate with no work timeline is a red flag that demands verification, not automatic rejection.

— HR should ask directly: "Which modules were not done by you?" Candidates who cannot draw clear boundaries between their work and the team's work are high-risk.

— Replace algorithm trivia with business-problem questions: design TypeScript types for approval nodes, explain WebSocket heartbeat and reconnection, defend a claimed LCP drop from 3.7s to 1.8s with measurement details.

— On AI projects, verify whether the candidate built retrieval pipelines or merely called APIs and rendered results; frontend candidates rarely implement Embedding and similarity recall themselves.

— Supervisor rounds should test MVP thinking: "Build an approval configurator in two weeks with incomplete requirements" reveals whether a candidate can prioritize a closed loop over perfection.

— Resume advice for candidates: replace "proficient in" with "solved X by doing Y," explicitly state what you did not build, and keep only 2-3 deep-diggable highlights per project.

— Post-interview feedback should name the specific gap—fundamentals, project articulation, role mismatch, or salary—instead of the generic "comprehensive assessment did not match."

Conclusions

The core tension in small-company frontend hiring is not skill level but delivery risk: can this person enter an existing codebase, handle incomplete specs, and debug production issues without a safety net.

Keyword density on a resume functions as an inverse signal for interviewers—the more hot terms packed in without ownership boundaries, the higher the probability the candidate cannot defend any single one under follow-up questioning.

Honest boundary-drawing in a resume ("I did the frontend streaming rendering; Embedding and recall were backend") earns more trust than claiming full ownership, because real projects are rarely solo efforts and interviewers know this.

The LCP metric on a resume is a high-value verification lever: a candidate who cannot explain how they measured it, what they changed, and whether it is reproducible reveals packaging instantly, regardless of how impressive the number looks.

Small-company interviews that mimic big-company algorithm rounds misallocate time; a candidate who can design a dynamic form schema with field dependencies and remote validation is more likely to ship working software than one who can invert a binary tree.

Concepts & terms

LCP (Largest Contentful Paint)

A Core Web Vital metric measuring the render time of the largest visible content element in the viewport. A drop from 3.7s to 1.8s signals significant perceived performance improvement, but the claim is only credible if the candidate can explain the measurement tool, the specific optimizations applied, and reproducibility.

ReadableStream

A web API that allows reading chunks of data as they arrive from a network request, used for streaming AI responses. Unlike EventSource, Fetch with ReadableStream supports custom headers, POST bodies, and complex authentication, making it the preferred choice for AI chat frontends that need to send context and receive token-by-token output.

TanStack Virtual

A headless virtual-list library that renders only the visible portion of a long scrollable list to reduce DOM node count. In AI chat interfaces with hundreds of messages, it prevents rendering slowdown, but dynamic row heights from expanded code blocks or images require additional measurement and caching logic.

RAG (Retrieval-Augmented Generation)

A pattern where a language model's prompt is augmented with relevant documents retrieved from a knowledge base. The retrieval pipeline—document chunking, embedding vectorization, similarity search—typically runs on the backend or in a vector database; the frontend's role is usually limited to displaying retrieved citations and streaming the augmented answer.

Source: juejin.cn ↗ Google Translate ↗ Backup ↗