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

Tu Aran · tuaran Frontend / AI Agent / Government-Enterprise Solutions Writes technical research, AI engineering practices, and indie development notes at 2aran.com. About the author →

Research scope: This article only evaluates the interview based on the public resume information in the screenshot, without judging the candidate's true personality, academic value, or final hiring conclusion. It is more like a deconstruction manual for frontend interviewers at small and medium-sized companies: how to read this type of resume, how to ask questions, how to avoid misjudgment, and how to help candidates articulate their abilities clearly.

1. First Impression: Worth an Interview, But Not Mid-to-Senior Level

If I were a frontend interviewer at a small or medium-sized company, my first judgment on this resume would be:

Worth bringing in for an interview, but with a verification mindset.

The candidate's main focus is frontend development, with keywords concentrated on Vue3, TypeScript, Pinia, Vue Router, Axios, Vite, Element Plus, Vant4, AntV X6, WebSocket, Fetch Stream, ReadableStream, RAG, Agent, markdown-it, and TanStack Virtual. Compared to resumes that only list admin panels, CRUD operations, and page restoration, this resume clearly has more content density.

It has four highlights.

First, the tech stack is relatively new. Vue3, Composition API, TypeScript, Vite, and Pinia are common combinations for frontend positions in small and medium-sized companies, not an outdated stack.

Second, the projects are not purely static pages. The dual-end integrated process collaboration approval platform involves process canvases, form linkages, permissions, WebSocket, and PC and H5 adaptation; the multimodal Agent intelligent conversation platform involves streaming output, Markdown rendering, RAG citations, and virtual lists. These are closer to real complex business scenarios than ordinary list pages.

Third, the resume includes verifiable result metrics. For example, LCP dropped from 3.7s to 1.8s. This metric may not be real, but it at least gives the interviewer a concrete handle.

Fourth, the candidate knows how to organize project narratives. The project descriptions include business scenarios, tech stacks, project work, performance optimization, and cross-platform reuse, indicating that the candidate has a certain ability to express and package their experience.

But the risks are also obvious.

First, the technical points are too dense. An undergraduate candidate simultaneously lists process platforms, Monorepo, X6, WebSocket, RAG, Agent, Function Calling, ReadableStream, and TanStack Virtual. Without a real project background, these are easily learning projects or packaged projects.

Second, there is a lack of work experience support. The screenshot does not show internships, companies, positions, or timelines. Without a real organizational environment, it is crucial to verify whether these projects are course projects, internship projects, outsourced projects, open-source projects, or personal simulation projects.

Third, AI projects are easily inflated. Terms like RAG, Embedding, similarity recall, and Function Calling are common now, but a frontend candidate might only be calling APIs and rendering results, without participating in the retrieval pipeline and tool-calling orchestration.

Fourth, the depth of TypeScript knowledge is questionable. The resume mentions TypeScript, but does not reflect details like type modeling, generic constraints, interface abstraction, component props design, or API response type specifications.

So, I would give a cautious judgment:

Dimension	Assessment
Interview Value	Yes
Position Level	Junior-to-upper or Junior-to-mid Frontend
Cannot Directly Assume	Mid-to-senior level, architectural ability, deep AI engineering
Biggest Verification Point	Project authenticity, technical depth, independent delivery capability
Biggest Opportunity Point	Complex business frontends, approval flows, AI conversation interaction, backend systems

2. What Small and Medium Companies Really Look For Is Not Keywords, But Delivery Risk

The hiring logic of small and medium-sized companies differs from that of large companies. Large companies can place people into mature processes for gradual training, or have one person responsible for only a very narrow module. Small and medium-sized companies are more concerned about whether a candidate can quickly enter the business scene after joining.

The real questions an interviewer needs to judge are these.

• Can they understand existing projects, not just build demos from scratch?
• Can they independently complete a complex page, including API integration, state management, exception handling, permission control, and post-launch debugging?
• Can they accept changing requirements, incomplete documentation, and temporary backend API adjustments?
• Can they explain technical solutions clearly to product managers, testers, and backend developers?
• When encountering a white screen online, API errors, or performance degradation, do they know where to start investigating?
• Are they honest in distinguishing "what I did," "what the team did," "what the backend did," and "what I just integrated"?

Therefore, the focus of the interview for this resume is not to ask "Do you understand RAG?" but to ask:

What problems have you personally solved? Why did you design it this way? How would you locate the problem if something went wrong? Could you still build it for a different business scenario?

This is the main line that small and medium-sized company interviews should stick to most.

3. First Round: HR Interview, First Verify Motivation, Stability, and Project Authenticity

The HR interview should not just be about asking about salary, start date, and family situation. For this type of candidate, the core of the HR interview is to filter out basic risks and avoid wasting time in the technical interview.

3.1 Self-Introduction: See If They Can Grasp Business and Responsibilities

You can ask like this:

Please introduce yourself in 3 minutes, focusing on one project that best represents your abilities.

The ideal answer should not just be reciting a tech stack, but should include business, responsibilities, and results.

For example:

I mainly do Vue3 and TypeScript frontend development. I've worked on a process approval platform and an AI conversation platform. In the approval platform, I was responsible for the process canvas, dynamic forms, permission routing, and mobile adaptation; in the AI conversation project, I was responsible for streaming output, Markdown rendering, and long conversation virtual list optimization. I am relatively familiar with complex interactions and state management, and I also hope to continue working on enterprise business system directions.

If the candidate only says "I am familiar with Vue3, Pinia, Axios, Vite, Element Plus," it indicates their expression is still stuck at the skill list level.

3.2 Project Nature: Must Ask Clearly

You can ask directly:

What is the nature of these two projects? Course project, internship project, outsourced project, real company project, or personal project? Which modules were you responsible for? Which parts were not done by you?

This question is critical. Good candidates are not afraid to talk about boundaries.

A better answer is:

The process approval platform was a team project, I was mainly responsible for the frontend process canvas, form linkages, permission routing, and mobile adaptation. The backend process engine was not done by me, but I participated in API field discussions and integration. The AI project was a personal plus team collaboration project, I mainly did the frontend streaming rendering and message structure design, Embedding and recall were on the backend.

A dangerous answer is:

I did the entire project myself.

If the candidate says "I did it all," the technical interview must follow up in great detail on data structures, API design, backend pipelines, deployment methods, and exception scenarios. People who have genuinely done full-stack work can usually tell many details; packaged candidates will quickly become vague.

3.3 Job Motivation: See If They Are Only Chasing Hot Trends

You can ask:

Are you currently more interested in doing business systems, AI applications, or frontend engineering? Why?

This resume has many AI terms, and small and medium-sized companies need to confirm if they are willing to do real business work. Many companies hire frontend developers, but the actual work is still admin systems, mobile pages, permissions, forms, reports, approvals, marketing activities, and API integration. If the candidate only wants to work on large models, Agents, and cool demos, there is a matching risk.

A relatively stable answer is:

I am interested in AI applications, but at this stage, I hope to focus on business frontend work. Approval flows, permissions, dynamic forms, and complex state management can build a foundation, and AI conversations can serve as an extension of business capabilities.

3.4 Small/Medium Company Fit: Lay Out the Real Work Scenario

You can ask:

Can you accept a work style with rapidly changing requirements, incomplete documentation, and the need to proactively confirm issues with product managers and backend developers? Have you had similar experiences in the past?

This is not an exploitative question, but a way to align both sides with reality in advance.

The common environment in small and medium-sized companies is: requirements will change, APIs will be late, legacy code is not perfect, testing resources are limited, and the frontend needs to handle some experience and exception states on its own. If the candidate clearly expects "all requirements to be clear, all APIs to be stable, only writing new projects without maintaining old ones," it is easy for both sides to drain each other after joining.

3.5 HR Interview Judgment Criteria

Performance	Judgment
Can clearly explain project nature and personal responsibilities	Proceed to technical interview
Can accept business system and maintenance work	Plus point
Reasonable salary and position expectations	Plus point
Vague project ownership, claims to have done everything	Technical interview focuses on verification
Only wants to do AI, unwilling to do business pages	Be cautious
Chaotic communication, cannot clearly explain experience	Do not recommend continuing

4. Second Round: Technical Interview, Focus on Deeply Digging into Real Implementation

The technical interview should be divided into four layers: fundamental skills, Vue3 engineering capability, deep project digging, and on-the-spot problem solving.

This resume is not suitable for only asking algorithm questions. Frontend positions in small and medium-sized companies should use real business problems to judge whether a candidate can deliver.

4.1 JavaScript and TypeScript Fundamentals

First question:

What is the relationship between Promise and async/await? If an error is thrown inside an async function, how does the outer scope catch it?

Follow-up:

If multiple API requests are made concurrently, and one fails, but the successful results from the others still need to be displayed, how would you handle it?

The expected answer includes Promise.all, Promise.allSettled, try/catch, partial degradation, error prompts, and retry strategies. If a candidate can only write await request() but cannot clearly explain error propagation and concurrent handling, it indicates their fundamentals are not solid enough.

Second question:

What is the difference between type and interface in TypeScript? How do you model API responses in your projects?

Follow-up:

An approval node has types like manual approval, conditional branch, CC, and end node. How would you design the types?

A better direction is:

type NodeKind = 'approval' | 'condition' | 'cc' | 'end'

interface BaseNode {
  id: string
  type: NodeKind
  name: string
  position: { x: number; y: number }
}

interface ApprovalNode extends BaseNode {
  type: 'approval'
  approvers: string[]
}

interface ConditionNode extends BaseNode {
  type: 'condition'
  rules: Array<{ field: string; operator: string; value: unknown }>
}

type FlowNode = ApprovalNode | ConditionNode

The candidate does not need to write it perfectly, but should know about union types, base fields, type narrowing, and business-specific fields.

Third question:

What pitfalls do deep copy, shallow copy, and structured data updates encounter in Vue state management?

This question can verify whether the candidate has truly worked on complex forms and process node configurations. In a process platform, you often need to copy nodes, undo changes, save drafts, and compare differences. Just using JSON.parse(JSON.stringify()) is not enough.

4.2 Vue3 and Engineering Capability

First question:

What is the difference between ref and reactive? Why might reactive lose reactivity after destructuring? How to solve it?

The expected direction is reactive proxies, ref wrapping values, toRefs, storeToRefs, and preserving reactive references during destructuring.

Second question:

Compared to the Options API, what is the biggest engineering benefit of the Composition API?

Don't just listen for "cleaner code." A better answer should be logic reuse, concern aggregation, complex page splitting, testability, and maintainability.

Third question:

In Pinia, which states should be placed in the store, and which should stay inside components?

This reveals the candidate's awareness of state boundaries. Flowchart data for an approval process, current user permissions, and global menus can be placed in the store; dialog visibility, local input fields, and temporary hover states should generally not all be stuffed into the global store.

Fourth question:

How to implement permission control in Vue Router? Are dynamic routes maintained by the frontend or returned by the backend? How to handle the loss of dynamic routes after a page refresh?

The expected answer includes tokens, user information, menu permissions, route guards, whitelists, dynamic addRoute, re-fetching permissions after refresh, and handling 404 and unauthorized pages.

4.3 Deep Dive into the Approval Flow Project

The strongest part of this resume is the "dual-end integrated process collaboration approval platform," which must be heavily questioned.

First question:

What is the core business process of this approval platform? From a user initiating an approval to its completion, which parts does the frontend participate in?

The candidate should be able to clearly explain the closed loop of initiation, form filling, process matching, approver handling, rollback, CC, notifications, status transitions, and history records. If they only say "I did the process node editing," it indicates a narrow business understanding.

Second question:

What specific role does AntV X6 play? How are the data structures for nodes and edges designed?

Follow-up:

How are conditional branches expressed? If two branch conditions conflict, should the frontend validate them?

The expected direction includes node id, type, position, data, edges, source, target, condition, and validateRules. For more complexity, you can also ask whether the save format and display format are consistent, and how canvas data is converted to and from backend process definitions.

Third question:

How to implement dynamic form linkages? For example, if field A selects "reimbursement," field B is displayed, and field C becomes mandatory.

This question is very practical. Someone who has genuinely done this will usually mention schema, field dependencies, visibleWhen, requiredWhen, watch, unified validators, and remote option caching. Packaged candidates easily answer with "use v-if to judge."

Fourth question:

What problem does WebSocket solve in the project? Why not use polling? How are heartbeat and reconnection implemented? How to avoid duplicate connections?

The expected answer includes connection lifecycle, authentication, heartbeat packets, timeout detection, reconnection intervals, maximum retry attempts, page unload cleanup, message deduplication, and handling multiple tabs for the same user. Small and medium-sized companies do not require candidates to have handled all edge cases, but they should at least know these pitfalls exist.

Fifth question:

LCP dropped from 3.7s to 1.8s. What specific optimizations did you make? How did you measure it?

This is a key indicator for verifying project authenticity. A better answer will mention Lighthouse, Chrome DevTools Performance, Performance API, route lazy loading, on-demand component loading, concurrent first-screen API requests, resource splitting, caching, image compression, skeleton screens, and reducing blocking scripts.

If the candidate answers "just used lazy loading," "can't remember the specifics," or "a colleague measured it," this performance metric basically cannot be counted as a plus.

4.4 Deep Dive into the AI Conversation Project

For AI projects, special attention must be paid to the frontend-backend boundary, and not to attribute backend algorithm capabilities to the frontend.

First question:

Why use Fetch + ReadableStream instead of EventSource?

A better answer is: Fetch can customize method, headers, and body, making it convenient for passing context, authentication, and complex parameters; EventSource is simple to use, but in many scenarios it is mainly a GET stream with weaker extensibility.

Second question:

During streaming output, does the server return complete Markdown? How does the frontend handle half-rendered code blocks, half-rendered tables, and half-rendered links?

Candidates who have genuinely worked on streaming Markdown will know this is very troublesome. You can expect them to mention buffer concatenation, chunk decoding, throttled rendering, re-parsing with markdown-it, handling unclosed code blocks, scroll following, and state recovery after abnormal interruption.

Third question:

What problem does TanStack Virtual solve? When is a virtual list not suitable?

A good answer is: it reduces the number of DOM nodes when there are many long conversation messages, lowering rendering pressure; but dynamic heights, asynchronous image loading, code block expansion, full-text search, and scroll positioning all require additional measurement and caching. If the candidate only says "optimizes performance," the depth is insufficient.

Fourth question:

In RAG, are Embedding and similarity recall done on the frontend or backend? What specifically did the frontend participate in?

A more credible answer is: Embedding, vectorization, and recall are usually done on the backend or in a vector database; the frontend is responsible for upload status, knowledge base selection, citation source display, recall snippet visualization, streaming answer rendering, and exception prompts.

If the candidate says "I implemented Embedding and similarity recall on the frontend," you must continue to ask about the model, vector dimensions, indexing method, recall threshold, performance, and security. It's not impossible, but the probability is low.

4.5 On-the-Spot Questions for the Technical Interview

Instead of biased algorithm questions, it's better to give two types of business problems.

First type, dynamic form design:

Design a dynamic form component that supports field show/hide, mandatory toggling, remote options, and form validation. Describe the data structure, component splitting, and validation flow.

Second type, streaming output implementation:

Write a simplified function that reads a ReadableStream, progressively appends content to the page, and handles exceptions and interruptions.

These types of questions are closer to his resume and closer to the real work in small and medium-sized companies. The interviewer can see whether the candidate truly understands state, asynchrony, boundaries, and user experience.

4.6 Technical Interview Evaluation Criteria

Performance	Conclusion
Can clearly explain business, data structures, exceptions, and trade-offs	Strongly recommend
Can write pages, but relies on memorized answers for complex problems	Cautiously recommend
Fundamentals are average, but honest and able to reason	Trainable
Only speaks keywords, falls apart under follow-up questions	Do not recommend
Project ownership is clearly exaggerated	High risk

5. Third Round: Supervisor Interview, See If They Can Fit Into the Team

The supervisor interview should not repeat technical details. The supervisor interview needs to judge: can this person work with the team to get things done after joining?

5.1 Business Advancement Capability

You can ask:

If the product manager asks you to build an approval process configurator in two weeks, but the requirements are not fully finalized, how would you proceed?

A good answer should include MVP thinking.

First confirm the core closed loop: node creation, connections, saving, display, and initiating approval. Then break down priorities: the first version supports basic approval; conditional branches, complex validation, batch operations, and audit logs can be deferred. Simultaneously, agree on the process definition data structure with the backend, do mockups in advance, and don't wait for the API to start writing pages.

This kind of answer indicates the candidate is not just someone who waits for tasks.

5.2 Technical Trade-off Ability

You can ask:

If you think a certain technical solution is better, but it will slow down delivery, how do you handle it?

Small and medium-sized companies need people who can weigh trade-offs. A good answer is not "I insist on the optimal solution," nor "I'll do whatever the product manager says," but:

First ensure the business closed loop and controllable launch risk. For complex solutions, reserve extension points, clearly record the technical debt, and schedule refactoring later based on business value.

5.3 Collaboration Ability

You can ask:

Backend APIs change frequently, and product requirements also change. How do you ensure you are not passive?

The expected answer includes API documentation, field conventions, mocks, integration checklists, change logs, daily syncs, and early risk exposure.

A dangerous answer is:

Wait for the backend to give me the API.

In a real team, no role can always wait for others to be ready.

5.4 Online Issue Handling

You can ask:

After launch, users report occasional white screens on the approval page. How would you locate the problem?

A relatively complete location chain is:

• First confirm the scope of impact: which page, which user, which browser, which environment.
• Check monitoring and logs: frontend errors, API status, resource loading, route jumps.
• Check recent releases: were there any changes related to permission routing, dynamic forms, or the process canvas.
• Try to reproduce: same account, same data, same operation path.
• Temporary stopgap: rollback, disable new features, fallback empty state.
• Root cause fix: add exception handling, add tests, add monitoring.

This question is very good at distinguishing "can write code" from "can handle production issues."

5.5 Growth Direction

You can ask:

What three capabilities do you most want to improve in the next year?

If the candidate answers JS/TS depth, complex component design, engineering, performance monitoring, or business modeling, it indicates they have a realistic sense of the frontend growth path.

If they only say "want to learn AI, architecture, large models," but cannot articulate their current shortcomings, it suggests their career plan might be adrift.

6. Resume Revision Suggestions for the Candidate

The biggest problem with this resume is not that the content is too little, but that every point is written too densely. Interviewers will naturally suspect "did they personally do all of this?" It is recommended to change from "stacking technical terms" to "responsibility, action, result, boundary."

For example, the original wording:

Integrated with the RAG retrieval augmentation process, implementing document chunking, Embedding vectorization, and similarity recall logic.

If these capabilities are mainly on the backend, it is recommended to change to:

Integrated with the backend RAG retrieval pipeline, responsible for document upload status, knowledge base selection, citation source display, recall snippet rendering, and streaming output of Q&A results, improving answer explainability.

This is more realistic and easier to gain the interviewer's trust.

Another example, the original wording:

Implemented real-time synchronization of process status changes based on WebSocket, covering approval triggers, rollback notifications, and exception alerts.

Can be changed to:

Responsible for the real-time approval status notification module, encapsulating connection, heartbeat, reconnection, and message deduplication logic based on WebSocket, enabling approval triggers, rollbacks, and exception alerts to be displayed synchronously on both PC and H5, reducing manual refreshes by users.

There are four principles for revision.

First, write less "proficient in" and more "what problem was solved."

Second, distinguish between personal responsibility and team responsibility. Honestly writing boundaries does not deduct points; it adds them.

Third, keep 2 to 3 deep-diggable highlights per project, don't stuff in every hot keyword.

Fourth, prepare the source for every metric. If you write LCP from 3.7s to 1.8s, you must know how it was measured, what was optimized, and whether it is reproducible.

7. Advice for Interviewers: Make the Interview a Win-Win

A win-win interview is not about lowering standards, nor about questioning the candidate until they are speechless. It should help the company identify real ability and also help the candidate understand the job requirements.

First, do not reject a candidate outright just because of a second-tier university degree. A degree is a signal, but not the delivery capability itself. Small and medium-sized companies especially should look at whether the candidate can quickly pick up business, communicate stably, and handle real problems.

Second, do not use large-company algorithm questions to screen business frontend developers. This resume is more suitable for testing Vue3, TypeScript, dynamic forms, permission routing, WebSocket, performance optimization, streaming rendering, and online debugging.

Third, questioning should start from real projects and then follow up layer by layer. First ask "what did you do," then ask "why did you do it this way," and finally ask "what if something goes wrong." This can identify packaging without misjudging candidates who are slow to express but have genuinely done the work.

Fourth, clearly explain the company's real environment. For example, whether there is legacy baggage, whether requirements change often, whether there is testing, whether it needs to cover both PC and mobile, whether there is AI business. The candidate also needs to judge if they are a good fit.

Fifth, give clear feedback after the interview. Even if not hired, you can tell the candidate whether it was insufficient fundamentals, insufficient project expression, a job mismatch, or a salary expectation mismatch. This is more valuable than a generic "comprehensive assessment did not match."

8. Final Conclusion

This is a frontend resume with interview value. It shows the candidate's attention to modern frontend tech stacks, complex business systems, and AI conversation interaction, but also exposes issues where project authenticity and technical depth need verification.

If the candidate can thoroughly explain the approval flow project, including X6 data structures, dynamic form linkages, permission routing, WebSocket stability, and performance optimization details, and can honestly explain the frontend-backend boundaries of the AI project, then a small or medium-sized company can consider hiring them, positioning them as a junior-to-mid frontend developer is more appropriate.

If the candidate can only recite keywords like Vue3, RAG, Agent, and WebSocket, and becomes vague when asked for implementation details, then the resume has a high packaging component and hiring is not recommended.

For the company, the best way is to verify delivery capability with real business problems. For the candidate, the best way is to prove themselves with real project details. Both sides should not stay at the keyword level probing each other; only then can the interview potentially be a win-win.