Quillon frontend interview

The interviewers’ interest held through a detailed invoice-list design; the director said they would recommend moving forward. You lost ground on accessibility: you named the basics but had limited audit experience; recruiting will call September 25 with details.

Study roadmap

1. Make design trade-offs measurable. State assumptions, show the calculation and connect it to the proposed design; practise estimating data size, request volume and freshness from stated inputs. In this interview, you calculated 25 MB, about 2 requests per second per large customer, and “a few hundred” requests per second across active customers, then estimated polling load as “nothing” without showing the arithmetic.
2. Turn accessibility basics into a practical approach. Practise explaining how you would check keyboard use, labels and semantics, and how you would find and address issues in a review. At 07:16, you named semantic HTML, filter labels and keyboard navigation, then said you had not done a proper audit.
3. Make experience claims consistently evidence-backed. Prepare one concrete example, number and outcome for each claim about work you liked or improved. Your mistake story included about 40 affected agents and a rollback within an hour; your reports-page example at 07:43 had no result or specific outcome.
4. Keep date and timezone assumptions explicit. Before choosing an API contract, clarify whose calendar defines a date and how the server receives it. At 04:49, you correctly identified that “due today” depends on the business timezone and offered two API approaches.

Where they dug longest

• They spent the most time on scale and list behaviour: Marco asked about 50,000 invoices, traffic, search, due-date edge cases, empty states and freshness (01:04–06:01). You answered each follow-up yourself, covering server-side filtering, cursor pagination, debouncing, URL state, timezone handling and polling.
• They spent the most time clarifying what customers need from the list: you asked about pain points, and the senior frontend engineer named slowness on large accounts and filters resetting after opening an invoice (08:07–08:24). You connected URL filters to the reset issue yourself.
• Expect these same points—large-account performance, persistent filters and accessible list behaviour—to matter in the next conversation.

Strengths and weaknesses

Strengths

• You clarified concurrency, paging and freshness before designing (01:22); that gave your proposal useful constraints.
• You connected pagination choice to both performance and changing data: cursor pagination avoids slow deep offsets and skipped rows (02:56).
• You anticipated stale search responses and suggested cancellation to prevent older results replacing newer ones (04:17).
• Your mistake story was specific: a Safari autofill regression affected about 40 agents; you rolled back within an hour and added Safari to the test run (06:37).
• You asked about customer complaints, then linked URL-based filters to the reported reset problem (08:07–08:24).

Weaknesses

• Your cross-customer traffic estimate was “a few hundred requests a second” without showing the inputs behind “a few hundred customers.” State the assumed number and show the multiplication.
• You called 20 people polling twice a minute “nothing” without calculating the total. State the resulting request rate and qualify the trade-off.
• Your accessibility answer identified basic techniques but no audit experience or example (07:16). Describe a concrete way you would validate keyboard and semantic access, without implying experience you have not had.
• “That’s the kind of work I liked most” and “I want to work where the frontend is the product” were not backed by an outcome (07:43). Your mistake story, by contrast, had affected users, response time and a process change; prepare comparable evidence for the reports page.

Your weakest answer, rewritten

Question: How do you approach accessibility on something like the invoice list?
Your answer: “Semantic HTML for the table, labels on the filters, keyboard navigation. Honestly at Copperleaf we never did a proper audit, so I know the basics more than I’ve done it at scale.”
A stronger version, using only your stated facts: “For the invoice list, I’d use semantic HTML for the table, label the filters and support keyboard navigation. At Copperleaf, I didn’t do a proper accessibility audit, so my experience is with the basics rather than accessibility at scale.”
Borrowed from: Your invoice-list design answer, where you described the table and filters, and your original accessibility answer.

The interview by time

The design segment was strongest: you clarified constraints and addressed scale, search, date handling and update freshness.

Your questions

• You asked what customers complain about most; the senior frontend engineer said large accounts are slow and filters reset after opening an invoice.
• You asked how slowness is measured; they said real-user timings are tracked per page and the large-account p95 is around four seconds.
• You asked how sprint work is chosen; the director said the product manager brings problems, engineers estimate, and they cut scope together.
• Worth asking next: what contributes most to the four-second p95 on large accounts, and how the team will judge whether a change improved it.
• Worth asking next: whether URL filters are already planned to address resets, given the reported behaviour and your proposed solution.

Follow-up email

Draft — check before sending

Thank you both for the conversation and for recommending that I move forward.
I’m especially interested in the invoice-list challenges on large accounts, including the roughly four-second p95 and filters resetting after an invoice is opened.
My accessibility experience is at the fundamentals level: semantic HTML, labelled filters and keyboard navigation; I haven’t conducted a proper audit at Copperleaf.
I’ll look out for Ana’s call tomorrow.