Interview guides · Colonial Life & Accident Insurance

Colonial Life & Accident Insurance Software Engineer Interview Guide

Colonial Life & Accident Insurance Software Engineer interview guide: reported rounds, JavaScript and CSS questions, behavioral prep and a 7-day plan.

The 60-second brief

Colonial Life & Accident Insurance offers financial protection benefits to working Americans. Candidates describe the Software Engineer role as building and maintaining the web tools that policyholders, employers and internal teams use to manage enrollments, process claims and administer benefits. The work reported for the role includes modernizing older systems, building web portals and shipping new flows such as policyholder enrollment or an internal dashboard for claims adjusters. In practice that means user-facing pages, forms and data views, built mostly with JavaScript and CSS, that sit on top of insurance rules and have to stay dependable for the people using them.

This guide is for someone applying to the Software Engineer role at Colonial Life & Accident Insurance. It covers the two reported rounds, the JavaScript, CSS, web-performance and DOM questions candidates report, the resume and background questions, and the behavioral prompts. The front-end questions are the technical core of the reported loop, so the guide spends its time there rather than on algorithm puzzles. If you come from a back-end background, plan extra time for CSS layout and browser mechanics.

Candidates report two rounds over roughly 2-4 weeks: a Preliminary Screening with an HR recruiter, then Core Team Interviews with a team lead and team members, either as one panel or as back-to-back virtual sessions. The team rounds are described as conversational, with resume, JavaScript and CSS, and behavioral questions.

Focus areas

JavaScript
CSS
Front-End Web Development

Overview

The reported questions fall into three groups. The first is web fundamentals: the difference between let, const and var, centering a div both ways in CSS, event bubbling and capturing in the DOM, closures with a practical use, and how to speed up a slow page. The second is experience: your background, a recent project and its technical challenges, taking over someone else's codebase, how you test before a pull request, and a performance or reliability improvement you delivered. The third is fit and communication: five-year plans, constructive criticism, explaining a technical idea to a non-technical stakeholder, keeping your skills current, and why you want this company.

Candidates describe the technical side as practical and centered on JavaScript and CSS, and they do not typically report LeetCode-style live coding. That changes how you should spend your time. Instead of grinding algorithm problems, be able to explain each language feature with a tiny example, say why it behaves as it does, and sketch the code on request. Vanilla JavaScript and plain CSS matter even if your daily work is in a framework, because the reported questions are about the platform itself.

The domain gives you material for the open-ended answers. The role is described as building enrollment, claims and benefits-administration tools for policyholders, employers and internal staff, and modernizing older systems alongside newer web portals. Choose project stories that show forms, data-heavy pages, reliability, and working around code you did not write. When a question asks why this company, you can refer to those concrete product areas rather than generalities. Requirements candidates describe also list Git, general engineering principles, and clear verbal communication, so practice speaking your reasoning aloud, not just knowing it.

The Colonial Life & Accident Insurance interview process

Candidates describe two stages, and the exact format of the second can change by team and location. Treat the list below as a reported pattern, not a published process.

Preliminary Screening

Candidates report that this first stage is an interview with an HR recruiter. It checks your background and basic qualifications and settles practical points such as location and work authorization. No technical deep dive is reported for this stage, so the preparation is mostly about a clear, short account of who you are and where your experience fits a web-focused Software Engineer role. Have your resume dates, current situation, and logistics answers ready so the conversation stays smooth.

What to demonstrate

Whether your resume and stated experience line up with the role
Basic qualifications for a web-focused Software Engineer position
Practical fit such as location and work authorization

How to prepare

Write and rehearse a short spoken narrative for the background question: where you started, the web work you have shipped, and why this role is the next step
Prepare one sentence on each recent role covering the stack (JavaScript, CSS, any framework) and your own contribution
Settle your answers on location, work authorization and availability before the call
Prepare a brief, concrete answer to why this company, built from its enrollment, claims and benefits-administration software

Core Team Interviews

Candidates report that this stage is interviews with a team lead and several team members, either as a single sit-down panel or as back-to-back virtual sessions. The reported content is resume questions, front-end technical knowledge with a strong lean toward JavaScript and CSS, and behavioral questions about teamwork and long-term interest. This is where the web-fundamentals questions are practised: let, const and var, vertical and horizontal centering, event bubbling and capturing, closures, and slow-page optimization. It is also where the project, testing, codebase-handover, feedback and stakeholder questions fit. Prepare to explain with small code examples and to tell stories in the first person.

What to demonstrate

Working knowledge of JavaScript and CSS, which candidates report as the focus
Ability to describe past projects, your own contribution and how you resolved problems
Collaboration, handling of feedback and clarity when explaining technical ideas
Interest in the role over the long term

How to prepare

Be able to write, from memory, a closure-based counter, a loop that behaves differently under var and let, and an event-delegation handler
Build one page that centers a box with Flexbox, Grid and absolute positioning, and know when each is the right choice
Rehearse a project deep dive covering stack, your ownership, one hard bug and one trade-off
Prepare stories for taking over unfamiliar code, receiving criticism, explaining a concept to a non-technical colleague, and a measured performance or reliability improvement

Where candidates lose points

Treating CSS and vanilla JavaScript as beneath a Software Engineer interview and stumbling on the centering or closure questions

Candidates report that JavaScript and CSS are the technical focus. Build a centered box three ways (Flexbox, Grid, absolute plus transform) and write a closure counter from memory, so basic questions are easy points.

Answering the let, const and var question with three one-line definitions

Cover scope (function versus block), hoisting and the temporal dead zone, reassignment versus mutation of a const object, and the classic setTimeout-in-a-loop example that behaves differently under var and let.

Answering how to optimize a slow page with a pile of tips and no measurement

Say you would start by measuring with browser dev tools or Lighthouse, find the actual bottleneck (network waterfall, bundle size, images, long tasks), fix the biggest one, and measure again.

Describing the project walkthrough and handover stories as 'we did' with no clear personal contribution

For each project write down what you owned, one hard problem and the trade-off you chose. Say 'I' for your decisions and name teammates for theirs.

Giving generic answers to the five-year and why-this-company questions that could apply to any employer

Reference the enrollment, claims and benefits-administration software and the modernization work, and give a growth path consistent with that kind of role.

Questions & practice

Can you explain the concept of closures in JavaScript and provide a practical use case?

Medium · Technical and Web Development

Approach

Define it precisely. A closure is a function together with its lexical environment: the variables in scope where the function was created. The inner function can still read and update those variables after the outer function has returned. It holds live bindings, not a snapshot of their values.
Private state: function createCounter() { let count = 0; return { inc: () => ++count, get: () => count }; }. count can't be reached from outside, so only the returned methods can change it. This is the module or factory pattern.
Give a practical example and write it out. debounce(fn, ms) declares let timer in the outer function and returns (...args) => { clearTimeout(timer); timer = setTimeout(() => fn(...args), ms); }. The timer id persists between calls only because of the closure. memoize (a cache Map in the closure) and once (a called flag) work the same way.
Name the pitfalls. Callbacks created in a var loop all see the final value; fix it with let or an IIFE. A long-lived closure, such as an event listener that captures a large array, keeps that array in memory until the listener is removed. In React, a setInterval inside useEffect with stale dependencies reads old state.
Function factories such as makeMultiplier(n) => x => x * n show partial application. Each returned function keeps its own n.

Follow-up

Write once(fn), which runs fn only on the first call and returns the cached result after that.
How can a closure cause a memory leak, and how would you confirm it in a DevTools heap snapshot?
Why does a setInterval callback inside a React useEffect keep logging an old state value, and how do you fix it?

Merge partitioned event streams into one ordered feed with bounded lateness

Hard · k-way merge · watermarks · out-of-order streams

The read-model service consumes 64 log partitions carrying about 4,000 events per second in total. Each partition is ordered within itself, but partitions drift by up to 30 seconds, and the activity feed must present a tenant's events in occurred_at order. Produce the merge. State its complexity, the buffer it requires in events and in bytes, what happens when one partition is idle, and what you do with an event that arrives after you have already emitted its position. Payloads average 1 KB.

Approach

Merge with a min-heap over the 64 partition heads keyed on (occurred_at, event_id): O(log P) per event and O(n log P) overall. The tie-break on event_id is what makes the output deterministic when two partitions carry the same millisecond, which matters because the feed is paginated and a non-deterministic order reorders pages under the reader.
Emitting the heap head is only correct once every partition has produced everything up to that timestamp, so the emit condition is a watermark: the minimum across partitions of the highest occurred_at seen, less the allowed lateness. Events are held until the watermark passes them, which is what turns individually ordered streams into a jointly ordered one.
Size the buffer from the lateness rather than guessing: 4,000 events per second times 30 seconds is 120,000 buffered events, and at 1 KB each about 120 MB of heap. That number is the real price of the ordering guarantee and belongs in front of whoever asked for it.
Handle the idle partition explicitly, because it fails the feed rather than corrupting it: a partition with no traffic never advances its own maximum, so the watermark freezes and output stops entirely. Either every partition emits a periodic idle marker carrying the broker's current time, or the watermark falls back to wall clock for a partition silent beyond a threshold.

Follow-up

The lateness budget is raised to five minutes. What is the new buffer, and what besides memory changes?
The consumer restarts. Where does it resume from, and what does the feed look like for the first 30 seconds?

Collapse a redelivered event batch into per-aggregate high-water marks

Easy · hashing · at-least-once · aggregation

You drain a batch of up to 5,000,000 events, each (aggregate_id BIGINT, aggregate_version INT, event_type, payload). The log guarantees order within one aggregate only; the batch merges 64 partitions, and a relay failover has redelivered a range, so an older version for an aggregate can appear after a newer one. Given a map of last_applied_version per aggregate, produce the events worth applying, at most one per (aggregate_id, version), plus the count discarded. Target O(n) time. State the memory for 2,000,000 distinct aggregates and what you do when it does not fit.

Approach

One pass, one hash map from aggregate_id to the highest version kept, and a discard counter. An event whose version is at or below last_applied_version for its aggregate is dropped without further work, which is the whole reason the event carries its version rather than a delta. O(n) expected time, O(d) space in distinct aggregates.
Keep the maximum, never the last occurrence. The redelivered range means the final appearance of an aggregate in the batch can be an older version than one seen earlier in the same batch, so last-wins applies stale state over newer state and the projection regresses with no error anywhere.
Cost the memory instead of calling it large: an 8-byte key plus a 4-byte version is 12 bytes of payload, and an open-addressed table held at a 0.7 load factor costs roughly 17 bytes per entry before per-slot metadata, so 2,000,000 aggregates is tens of megabytes in a native layout and several times that in a runtime that boxes both key and value.
If the distinct set exceeds memory, partition on hash(aggregate_id) mod P and reduce each partition independently. Every event for one aggregate hashes to the same partition, so the per-partition result is exact and the merge is concatenation rather than a second reduction.

Follow-up

The payload is a patch rather than a snapshot, so applying only the highest version loses the intermediate changes. What changes in your reduction?
How do you detect that version 7 arrived while version 6 was never delivered, and what should the consumer do about the gap?

Find version gaps and relay lag with window functions

Medium · window functions · event tables · frame semantics

outbox_event holds event_id, aggregate_type, aggregate_id, aggregate_version, event_type, payload, status ('pending','published','dead'), attempts, created_at, published_at. A projection is missing rows and you must decide whether the relay skipped events or the consumer dropped them. Write three queries over the last seven days: one listing every aggregate_id whose published aggregate_version sequence has a hole, one giving per-day counts with a running total, and one returning the newest published event per aggregate. For each, say where the window function is evaluated relative to WHERE and LIMIT. PostgreSQL 16.

Approach

Gaps: compute lead(aggregate_version) OVER (PARTITION BY aggregate_id ORDER BY aggregate_version) in a subquery, then filter next_version <> aggregate_version + 1 in the outer query. Window functions are evaluated after WHERE, GROUP BY and HAVING and before the outer ORDER BY and LIMIT, so the predicate cannot sit in the same WHERE clause and PostgreSQL 16 has no QUALIFY.
Say what the seven-day filter does to the answer: it truncates every partition, so the first row per aggregate has no predecessor inside the window and a hole spanning the boundary is invisible. Widen the window, or join to resource.version as the authority for the true maximum.
Running total: SELECT date_trunc('day', created_at) AS d, count() AS n, sum(count()) OVER (ORDER BY date_trunc('day', created_at) ROWS UNBOUNDED PRECEDING). An aggregate inside a window call is legal because grouping runs before windowing. The grouping key is unique per row here so ROWS and RANGE agree, but write the frame anyway — over ungrouped rows with tied timestamps the default RANGE frame pulls in every peer row and the total jumps.
Newest per aggregate: DISTINCT ON (aggregate_id) ... ORDER BY aggregate_id, aggregate_version DESC is the cheap PostgreSQL-only form when an index matches that order; row_number() OVER (PARTITION BY aggregate_id ORDER BY aggregate_version DESC) = 1 is the portable form and needs a subquery for the same evaluation-order reason as the gap query.

Follow-up

Relay failover redelivers events. Does a duplicate break the gap query, and how would you detect one from this table alone?
Turn the gap check into a continuous monitor rather than a query someone runs after an incident. What does it watch?

Stop tag and share joins from fanning out a page

Medium · join fan-out · semi-joins · many-to-many

resource_tag is (resource_id, tag_id) with PK (resource_id, tag_id); resource_share is (resource_id, shared_with_user_id, permission). The tagged-and-shared listing inner-joins resource to both, filters tenant_id, tag_id = ANY($2) and shared_with_user_id = $3, orders by updated_at DESC and takes 50. Pages come back with fewer than 50 distinct resources and the total in the header is far too high. Explain the row multiplication, rewrite both the page query and the count query so each is correct, and name the index each one needs. PostgreSQL 16.

Approach

Do the arithmetic against the predicates that are actually there. An inner join emits one row per matching child row, and both joins are filtered: tag_id = ANY($2) admits only the requested tags, shared_with_user_id = $3 admits one user's share rows. So a resource holding three of the requested tags and shared with $3 once yields three rows, not one — the multiplier is its count of matching tags times its share rows for that single user, and that second factor is 1 unless the table admits duplicate (resource_id, shared_with_user_id) pairs. LIMIT 50 then limits rows rather than resources, and COUNT(*) counts pairs — the header is the product, not the population.
Reject DISTINCT as the fix. It deduplicates after the product has been built, so the planner must materialise and sort the fanned-out set before the LIMIT can apply, and it leaves any SUM or AVG in the same select list wrong.
Rewrite both filters as semi-joins, keeping resource as the only row source: AND EXISTS (SELECT 1 FROM resource_tag rt WHERE rt.resource_id = r.resource_id AND rt.tag_id = ANY($2)) and the same shape against resource_share. A semi-join stops at the first match per resource and preserves the driving index order, so ORDER BY updated_at DESC, resource_id DESC LIMIT 50 still stops after 50 rows.
Count with the same predicates and no join at all: SELECT count(*) FROM resource r WHERE r.tenant_id = $1 AND r.status = 'active' AND EXISTS (...) AND EXISTS (...). Nothing multiplies a resource, so the number is the population.

Follow-up

The filter changes from 'any of these tags' to 'all of these tags'. Rewrite it and state what it costs relative to the ANY form.
A resource can be shared with the same user twice under different permissions. Does your count change, and should it?

Can you explain the difference between `let`, `const`, and `var` in JavaScript?

Medium · Technical and Web Development

Approach

Start with scope. var is scoped to the enclosing function, or global at the top level. let and const are scoped to the nearest block ({}), such as an if body or a loop body. A top-level var in a classic script also becomes a property of window/globalThis. A top-level let or const does not.
Explain hoisting and the temporal dead zone. All three declarations are hoisted. var is initialised to undefined, so reading it before the declaration line returns undefined. let and const stay uninitialised until their declaration runs, so reading them earlier throws a ReferenceError.
Cover redeclaration and reassignment. Declaring a var twice in the same scope is allowed. Doing that with let or const is a SyntaxError. const must be initialised where it is declared, and assigning to it again throws a TypeError. const fixes the binding, not the value: a const object or array can still be mutated, and Object.freeze is shallow.
Walk through the loop example: for (var i = 0; i < 3; i++) setTimeout(() => console.log(i)) logs 3, 3, 3 because every callback shares one i. With let, each iteration gets a fresh binding, so it logs 0, 1, 2.
End with the rule you follow: const by default, let only when the variable is reassigned, and no var in new code.

Follow-up

What does typeof return for a let variable read inside its temporal dead zone, compared with a variable that was never declared?
Without let, how would you fix the setTimeout loop so it logs 0, 1, 2?
How would you make a nested configuration object fully immutable?

How do you center a `div` both vertically and horizontally using CSS?

Medium · Technical and Web Development

Approach

Flexbox on the parent: display: flex; justify-content: center; align-items: center. Say that the parent needs a height (for example min-height: 100vh). Without one there is no vertical space to centre in.
Grid on the parent: display: grid; place-items: center. place-items is shorthand for align-items plus justify-items. This is the shortest version and works when the child's size is unknown.
Without flex or grid: give the parent position: relative and the child position: absolute; top: 50%; left: 50%; transform: translate(-50%, -50%). The transform shifts the child back by half its own size, so the child's dimensions don't need to be known. If the child has a fixed width and height, inset: 0; margin: auto also works.
Point out a common mistake: margin: 0 auto centres a block that has a width horizontally only, and does nothing vertically in normal flow. Inside a flex container, margin: auto on the child centres it on both axes.
Cover edge cases. If the child is taller than the container, centred content overflows at both edges and the top can't be reached by scrolling. align-items: safe center falls back to start alignment in that case. The translate method can also blur text at sub-pixel offsets.

Follow-up

If the flex container uses flex-direction: column, which property centres vertically and which horizontally?
How would you centre a modal that has to stay centred while the page behind it scrolls?
How would you centre a single line of inline text inside a fixed-height box?

Walk me through how event bubbling and capturing work in the DOM.

Medium · Technical and Web Development

Approach

Name the three phases. In the capture phase the event travels from window down to the target's parent. In the target phase it reaches the element. In the bubble phase it travels back up to window. addEventListener(type, handler) listens in the bubble phase by default. Passing { capture: true } (or true) listens in the capture phase.
Distinguish event.target, the element where the event started, from event.currentTarget, the element whose listener is running. Explain the stop methods. stopPropagation stops the event reaching further nodes. stopImmediatePropagation also skips the remaining listeners on the current element. preventDefault cancels the browser's default action and has nothing to do with propagation.
Explain event delegation as the practical use. Put one listener on a container such as a list or table, then use event.target.closest('li') to find the item and container.contains to confirm it belongs to that container. This handles rows added later and needs fewer listeners.
Mention events that don't bubble: focus, blur, mouseenter and mouseleave. For delegation, use focusin/focusout or mouseover/mouseout instead, or a capture-phase listener.
Give a real bug. A document-level click handler that closes a dropdown also fires for clicks inside the dropdown, because those clicks bubble up. Fix it by checking whether the dropdown contains event.target, not by calling stopPropagation everywhere.

Follow-up

Inside a listener added with addEventListener, does returning false stop propagation or the default action?
Where would a capture-phase listener be the right choice instead of a bubble-phase one?
How would you delegate click handling for a table whose rows are re-rendered after every API call?

How would you optimize a web page that is loading very slowly?

Medium · Technical and Web Development

Approach

Measure before changing anything. Use Lighthouse plus the Network and Performance panels in DevTools. Read Core Web Vitals (LCP, INP, CLS) and TTFB, and decide whether the time goes to the server (high TTFB), the network (bytes and request count) or the main thread (long JavaScript tasks).
Reduce network cost. Enable Brotli or gzip compression. Use long-lived Cache-Control headers on content-hashed asset filenames and serve static assets from a CDN. Serve images at the size they display, using srcset and WebP/AVIF, and add loading="lazy" to images below the fold.
Remove render-blocking work. Add defer or async to scripts, inline the critical CSS, preload the LCP image and key fonts with font-display: swap, then code-split and tree-shake bundles. To prevent layout shift, give images and embeds explicit width and height.
Reduce main-thread cost. Split long tasks, debounce input handlers, batch DOM reads before writes to avoid forced layout, and virtualise long lists or tables. For chained API calls, check the waterfall: parallelise independent requests and cache or index slow backend queries.
Finish with before-and-after numbers for the metric you targeted. Add a performance budget, for example Lighthouse CI on pull requests, so the regression can't come back unnoticed.

Follow-up

LCP is good but the page feels sluggish when users click. What do you look at?
How do you tell whether the slowness is on the server or in the browser?
Lab scores look fine but real users still complain. What data would you collect?

Walk me through a recent project you completed. What were the technical challenges?

Medium · Experience and Background

Approach

Choose one project you can cover end to end. Open with who used it and what problem it solved, in two sentences. Then give the architecture: front end, API, data store, and how they connect, plus the stack in one line.
Separate what you owned from what the team did, using I for your part. Candidates report questions that check which parts of a project were their own work.
Go deep on one or two technical challenges. Give the symptom or constraint, the options you considered, why you chose one, and its cost. Examples include a form that had to handle complex validation, a slow page, a legacy module you had to integrate with, or a cross-browser CSS bug.
Close with a result you can measure or verify (load time, error rate, release shipped, support tickets reduced) and one thing you would change next time.
Prepare to sketch the data flow verbally and to answer "why not X?" for each major stack choice. If the project used JavaScript and CSS, have one concrete detail ready for each.

Follow-up

If you rebuilt this project today, what would you design differently?
How was the project tested and deployed, and what broke after release?
Why did you pick that framework or library over the obvious alternative?

What is your process for testing your own code before submitting a pull request?

Medium · Experience and Background

Approach

Describe your process in layers. First, run the unit tests for the logic you changed (Jest or Vitest for JavaScript). Then add tests for each new branch and edge case: empty input, null or undefined, boundary values, invalid user input. For a bug fix, first write a test that reproduces the bug and fails, then show it passing.
For UI changes, add component or integration tests that check behaviour, not implementation (for example Testing Library queries by role or label). Then check the page by hand at mobile and desktop widths, in more than one browser, and with keyboard-only navigation.
Run static checks before pushing: the linter (ESLint), type checks if the project uses TypeScript, and the formatter. Then read your own diff line by line to catch leftover console.log calls, commented-out code and unrelated changes.
Keep the pull request small. In the description, say what you tested and how, attach screenshots for visual changes, and confirm CI is green before asking for review.
State the trade-off. You aim to cover risky logic and user-visible behaviour, not to hit a coverage number, and you fix or quarantine flaky tests instead of re-running them until they pass.

Follow-up

How would you test code that depends on the current date or on a network call?
Tell me about a bug that got past your tests. What did you change in your process afterwards?
What do you check differently when the change touches code you didn't write?

Exports duplicate a row range about once a week

Hard · leases · clock skew · idempotency

Roughly once a week an export writes a file containing a duplicated range of rows. The affected job_run rows show attempt = 1, status = succeeded, one started_at, and a lease_owner naming a different host from the one whose logs show the job starting. Leases last 30 seconds and are heartbeated every 10 from inside the handler; lease_expires_at is computed on the worker and compared against the database's now(). Find the mechanism, and give a fix that holds even if you cannot fix the clocks.

Approach

Start from the fact that eliminates the obvious answer. attempt = 1 means no retry was recorded, so this is not a re-run after failure; two workers ran the same row concurrently and the takeover path never touched the counter. lease_owner naming a host other than the one that started the job is the same statement from the other side.
Enumerate the mechanisms that cause a premature takeover, then find the signal that separates them. Either the lease genuinely expired because the heartbeat did not fire, which is what happens when the heartbeat runs on the handler's own thread and the handler makes a long blocking call, or it only appeared expired because two clocks disagree, since lease_expires_at is written from the worker's clock and evaluated against the database's. The discriminator is the distribution: incidents clustered on the longest exports indict the heartbeat, incidents clustered on one host indict skew. Measure both, and measure each host's offset against the database directly.
Read the reclaim query precisely. In PostgreSQL now() is transaction start time, not statement time, so a reclaimer holding a long transaction compares against an older timestamp than expected; clock_timestamp() is the statement-time function. This is worth ruling in or out before you redesign anything, because it changes which rows look expired.
Remove the second clock rather than trying to synchronise it. Issue and extend the lease in the database, with lease_expires_at = now() + interval '30 seconds' in both the claim and the heartbeat, so exactly one clock is ever compared and worker skew stops mattering to this predicate.

Follow-up

The displaced worker has already streamed half the file to object storage. What makes that side effect safe to repeat?
You now count takeovers. What alert fires on that counter, and at what threshold?

Suggested practice checklist

The plan gives the first day to your narrative and the recruiter screen, three days to JavaScript, CSS and DOM or performance topics candidates report, and the last three to project, behavioral and spoken rehearsal.

Day 1 — Narrative and recruiter-screen basics

Write a short spoken narrative for the background question: present role, two or three pieces of web work, and why this Software Engineer role.
List the logistics answers a recruiter screen covers: location, work authorization, availability, and the stack on your resume.
Write a few lines on why this company, using enrollment, claims and benefits-administration tools as the specifics.

Deliverable: A one-page narrative, a logistics answer sheet and a why-this-company paragraph.

Day 2 — JavaScript: scope, declarations and closures

Write short examples showing var, let and const: function versus block scope, hoisting, the temporal dead zone, and mutation of a const object.
Write the setTimeout-in-a-loop example with var and with let, and a closure-based counter and a once() wrapper.
Say aloud a practical use of closures, such as private state or a debounced search input.

Deliverable: A file of small, runnable snippets with a one-sentence explanation each.

Day 3 — CSS: centering and layout

Build a centered box in three ways: Flexbox, Grid with place-items, and absolute positioning with transform.
Rebuild a simple enrollment form layout that stays usable on narrow screens, using Flexbox or Grid and a media query.
Write down the box model, specificity order and when each centering method fails.

Deliverable: One HTML/CSS page with the three centering methods and a responsive form layout.

Day 4 — DOM events and a slow page

Write a page with nested elements that logs capture and bubble order, then replace many listeners with one delegated handler.
Run Lighthouse and the network panel on any page you have built, and list the fixes in order of expected effect.
Practise saying the slow-page sequence aloud: measure, find the bottleneck, fix the largest one, measure again.

Deliverable: An event-order demo and a ranked performance fix list for a real page.

Day 5 — Projects, testing and reliability

Write a project walkthrough: purpose, stack, your ownership, one hard bug, one trade-off.
Write your pre-pull-request testing routine, covering unit tests, manual checks in the browser, self-review of the diff and tests for edge cases.
Write up one performance or reliability improvement with a before and after measurement.

Deliverable: A project walkthrough, a testing checklist and a measured improvement story.

Day 6 — Behavioral stories

Outline stories for taking over a codebase and for receiving constructive criticism, each with a concrete outcome.
Prepare an example of explaining a technical concept to a non-technical colleague, plus a disagreement about a technical approach.
Write a recent-learning example for the keeping-skills-current question.

Deliverable: Four outlined stories and one recent-learning example.

Day 7 — Full spoken rehearsal

Answer the five-year question and the why-this-company question aloud, recording yourself.
Run through the background answer and one question from each group (JavaScript, CSS, DOM or performance, project) as if in the team interview.
Fix the two weakest answers and rehearse them again.

Deliverable: A recorded run-through and a short list of fixes applied.

Background and behavioral questions

Candidates describe the team rounds as conversational, with questions about your resume, your teamwork and how long you plan to stay and grow. For this web-focused role, prepare stories about code you inherited, feedback you acted on, explaining technical ideas to non-engineers, and a measured improvement, and keep each one centered on what you decided and did.

Describe a time you had a disagreement with a team member about a technical approach. How did you resolve it?
Tell me about a time you had to learn a new technology quickly to deliver a feature.

Tell me about your background and how your experience aligns with this role.

Medium · Experience and Background

Approach

Use a present, past, future shape: what you do now, the two or three pieces of web work that built your skills, and why this Software Engineer role is the next step. Keep the chronology short and spend the time on contribution.
Name the stack for each project (JavaScript, CSS, framework, Git workflow) and separate what you owned from what the team did. Say 'I built the enrollment form validation' rather than 'the team shipped a form'.
Link your experience to the work candidates describe for this role: user-facing portals, forms and data views, legacy code alongside new code, and working with leads and product managers. Mention insurance, finance or healthcare experience only if you have it.
Finish by inviting a follow-up on the project closest to this role, so the conversation moves to something you can discuss in depth.
The mistake that sinks it is a line-by-line recital of the resume with no outcome; for each job give one result you can explain.

Follow-up

Which of those projects did you own end to end, and which did you only contribute to?
Which part of your experience is furthest from this role, and how would you close that gap?
What would you change about the most recent project if you rebuilt it?

Describe a time when you had to take over a codebase written by someone else.

Medium · Experience and Background

Approach

Structure it as situation, first week, changes, result. State the context briefly (who left, how big the codebase was, what you were asked to deliver), then spend most of the answer on how you got oriented.
Describe a concrete orientation sequence: run the app locally, read the existing tests and README, trace one user flow from the browser through the API, use git log and blame to learn why odd code exists, and ask the previous owner or neighbors what was fragile.
Show how you made change safe: write characterization tests around the behavior you had to touch, ship small pull requests, and leave unrelated messy areas alone unless they blocked the work.
Be even-handed about the original author. Say what the code did well and explain choices in terms of the constraints at the time, not blame.
The mistake that sinks it is a 'I rewrote everything' story; a rewrite without evidence reads as poor judgment about risk.

Follow-up

How did you decide between refactoring a piece and leaving it alone?
What did you do when there were no tests and nobody left who knew the code?
How did you confirm you had not broken existing behavior?

Can you give an example of a time you improved the performance or reliability of an application?

Medium · Experience and Background

Approach

Open with the symptom and a baseline you actually measured: page load or interaction timing from browser dev tools or Lighthouse, an error rate, or a support-ticket count. A story without a before number cannot be checked.
Explain how you found the cause, for example a network waterfall showing an oversized bundle or repeated API calls, a long task in the performance profile, or a failing dependency that needed retries and a timeout. Name the single change you made first and why.
Give the result in the same unit as the baseline, using only your real figures, and say how you confirmed the improvement was yours, such as a comparison before and after release.
Cover the cost and the guardrail: what you traded away, and the monitoring, test or budget you added so the problem would not return.
The mistake that sinks it is a vague 'I optimized it and it was faster' with no measurement or attribution.

Follow-up

How do you know your change caused the improvement rather than something else released that week?
What trade-off did the fix introduce?
What would you look at next if it had not been enough?