After an update, some users occasionally load new HTML with old JavaScript and the page fails. How would you design asset naming, cache policies, and release order to reduce inconsistency?

Shared reading guide · question-specific review pending

The sections below are shared prompts, not verified conclusions about this question. Restate the concrete problem and check which prompts actually apply; do not infer a candidate trait from this guide.

Objective problem to resolve or clarify

Question-specific objective analysis has not been reviewed yet. First restate the decision, uncertainty, or task that this prompt asks you to resolve.

What it examines

Tests caching and version-transition mechanics for frontend build artifacts.

Signals worth noticing

Separates caching policies for HTML and versioned assets
Accounts for a window in which old clients still reference old assets
Proposes release-order, rollback, and compatibility strategies

Context worth asking for

【How do you order cache and deployment when users receive new HTML with old assets?】A CDN has cached new HTML while some edge nodes still hold old JavaScript. The page fails to start, and purging creates a traffic spike. How would you change asset naming, rollout order, and cleanup?
How do you handle old pages that request lazy assets much later?
When is it safe to delete assets from the previous release?
【Static assets still show old content after ETags are added, while clearing caches causes a traffic spike. How would you design HTTP cache validation and invalidation?】Static assets still show old content after ETags are added, while clearing caches causes a traffic spike. How would you design HTTP cache validation and invalidation?
If HTML must update immediately while hashed assets can be cached long-term, how should deployment coordinate them?
How would you diagnose inconsistent behavior across browser cache, service worker, and CDN layers?
What goal, baseline, constraints, and responsibility boundary applied?
What options were available, and what evidence or dependencies shaped the choice?
Who was affected, what changed, and over what time window?
How was the result verified, and what alternative explanation or downside was considered?

Shared analysis and assessment prompts

What else the answer may imply

No question-specific inference has been reviewed. Treat the stated intent as a hypothesis, and check alternative explanations against the person’s role, opportunity, responsibility, and evidence.

Decision after context

After establishing context, compare plausible options against the stated goal and constraints. Make the decision rule explicit, note uncertainty and reversible steps, and say what evidence would change the choice.

Examine the trade-offs

Benefits created

Which part of the stated objective does each option address, and who benefits?
What observable outcome, baseline, and time window would show improvement?

Costs and risks

What direct, ongoing, and opportunity costs would each option introduce, and who carries them?
What could fail, become harder to change, or affect other people; what evidence would justify the risk?

Assessment guide

Use these as evidence anchors for this capability, not as an automatic score or an overall judgment of a person. Calibrate expectations to the role, level, and scope. A score of 2 is the usual baseline; excellent evidence in one or two dimensions is meaningful, while exceptional evidence is rare.

1 · Not passing

Core concepts or basic facts are unclear; the reasoning or account of events cannot be followed. For experience questions, the person cannot distinguish their own actions and responsibility. Confirmed deliberate fabrication is not passing; inconsistency or missing detail alone is a reason to verify, not proof of dishonesty.

Cannot explain the question’s relevant concepts, facts, or reasoning in a way that can be checked.

2 · Passing

Explains the basic concepts and approach clearly and gives credible evidence of having done the work or being able to reason through it.

Explains a reasonable basic approach and supports it with relevant experience or a coherent, checkable line of reasoning.

3 · Excellent

Gives a structured account, reflects clearly on what worked and what did not, weighs benefits against costs or risks, and offers an insight or practice above the ordinary expectation for the role and level.

Shows structured reasoning, relevant comparisons, trade-offs, and a useful insight above the usual expectation for the role and scope.

4 · Exceptional

Shows an outcome or practice at an exceptional, field-leading level for the relevant scope. The impact is measurable, independently supportable, and credibly attributable to the person’s decisions and work.

Provides independently checkable evidence of exceptional impact for the relevant scope and explains contribution, attribution limits, and conditions.

Question context and related views

RoleFrontend · General software engineering · Backend · Mobile

Responsibility scopeIndividual work · A project or team · Multiple teams

Career trackIndividual contributor · Team manager · Senior manager

Select questions for the responsibility you actually hold or seek. These labels are not universal stage requirements. Stage expectations

Same question, different stage expectations

The question stays the same. Choose a target to compare responsibility, reasoning, and evidence. This changes the reading framework, not the question’s difficulty or your score.

Loading stage model…

Target roleTarget responsibility

These are rule-based reading prompts, not separately reviewed stage-specific answers or a verdict that this question applies to every stage. Use your actual role and authority.

View the full role and stage model →

Compare expectations across stages

This table compares responsibility lenses, not mandatory question coverage or a ranking of people.

Stage	Responsibility	Result evidence

Want deeper feedback? Generate a prompt with this question’s evidence framework, then choose an AI tool yourself.

AI analysis prompt

# Interview Compass response analysis
Analyze the candidate response using only evidence provided. Do not invent facts.

## Question and review status
Question: After an update, some users occasionally load new HTML with old JavaScript and the page fails. How would you design asset naming, cache policies, and release order to reduce inconsistency?
Analysis review status: Shared reading guide · question-specific review pending. The sections below are shared prompts, not verified conclusions about this question. Restate the concrete problem and check which prompts actually apply; do not infer a candidate trait from this guide.
Objective problem: Question-specific objective analysis has not been reviewed yet. First restate the decision, uncertainty, or task that this prompt asks you to resolve.
Assessment intent: Tests caching and version-transition mechanics for frontend build artifacts.
Possible inference (a hypothesis to verify): No question-specific inference has been reviewed. Treat the stated intent as a hypothesis, and check alternative explanations against the person’s role, opportunity, responsibility, and evidence.

## Evidence framework
Observable signals:
- Separates caching policies for HTML and versioned assets
- Accounts for a window in which old clients still reference old assets
- Proposes release-order, rollback, and compatibility strategies
Context worth asking for:
- 【How do you order cache and deployment when users receive new HTML with old assets?】A CDN has cached new HTML while some edge nodes still hold old JavaScript. The page fails to start, and purging creates a traffic spike. How would you change asset naming, rollout order, and cleanup?
- How do you handle old pages that request lazy assets much later?
- When is it safe to delete assets from the previous release?
- 【Static assets still show old content after ETags are added, while clearing caches causes a traffic spike. How would you design HTTP cache validation and invalidation?】Static assets still show old content after ETags are added, while clearing caches causes a traffic spike. How would you design HTTP cache validation and invalidation?
- If HTML must update immediately while hashed assets can be cached long-term, how should deployment coordinate them?
- How would you diagnose inconsistent behavior across browser cache, service worker, and CDN layers?
- What goal, baseline, constraints, and responsibility boundary applied?
- What options were available, and what evidence or dependencies shaped the choice?
- Who was affected, what changed, and over what time window?
- How was the result verified, and what alternative explanation or downside was considered?
Comparison dimensions:
Decision after context: After establishing context, compare plausible options against the stated goal and constraints. Make the decision rule explicit, note uncertainty and reversible steps, and say what evidence would change the choice.
Benefits to examine:
- Which part of the stated objective does each option address, and who benefits?
- What observable outcome, baseline, and time window would show improvement?
Costs and risks to examine:
- What direct, ongoing, and opportunity costs would each option introduce, and who carries them?
- What could fail, become harder to change, or affect other people; what evidence would justify the risk?

## 1–4 evidence anchors
- 1 · Not passing: Core concepts or basic facts are unclear; the reasoning or account of events cannot be followed. For experience questions, the person cannot distinguish their own actions and responsibility. Confirmed deliberate fabrication is not passing; inconsistency or missing detail alone is a reason to verify, not proof of dishonesty. Question-specific reference: Cannot explain the question’s relevant concepts, facts, or reasoning in a way that can be checked.
- 2 · Passing: Explains the basic concepts and approach clearly and gives credible evidence of having done the work or being able to reason through it. Question-specific reference: Explains a reasonable basic approach and supports it with relevant experience or a coherent, checkable line of reasoning.
- 3 · Excellent: Gives a structured account, reflects clearly on what worked and what did not, weighs benefits against costs or risks, and offers an insight or practice above the ordinary expectation for the role and level. Question-specific reference: Shows structured reasoning, relevant comparisons, trade-offs, and a useful insight above the usual expectation for the role and scope.
- 4 · Exceptional: Shows an outcome or practice at an exceptional, field-leading level for the relevant scope. The impact is measurable, independently supportable, and credibly attributable to the person’s decisions and work. Question-specific reference: Provides independently checkable evidence of exceptional impact for the relevant scope and explains contribution, attribution limits, and conditions.

## Analysis instructions
1. Separate explicit evidence, missing context, and hypotheses. Cite exact words or facts from the response.
2. List the most important follow-up questions first. If there is not enough evidence, state “insufficient evidence; do not score.”
3. Assess each relevant signal against the 1–4 anchors only when supported; explain evidence and uncertainty.
4. Discuss comparison choices, causal reasoning, trade-offs, and the candidate’s actual participation where relevant. Identify strengths, unsupported conclusions, and one concrete next practice.
5. Do not provide a sample answer, rewrite the response as a script, diagnose personality, infer dishonesty from inconsistency alone, combine scores into an overall score, or recommend hiring/rejection.

If the response is not provided, ask the candidate to paste their response first; do not analyze or score the question alone.
Do not write a sample answer.

Primary capability

Engineering systems

Role

Frontend General software engineering Backend Mobile

Use case

External job interviews Campus hiring Designing as an interviewer

Topic

Frontend Engineering systems Reliability DevOps Computer networks

Responsibility scope

Individual workA project or teamMultiple teams

Career track

Individual contributorTeam managerSenior manager

Question format

Case analysisSystem designDebuggingKnowledge explanation

Source

Inspired by：Front-end Interview Handbook — JavaScript and frontend interview topics
Interview Compass 原创扩充批次 2026-10-15 G
Interview Compass 原创扩充（2026-10-14）