You are in a 45–60 minute phone screen (with screen sharing) for a Fullstack/Frontend role. The interviewer shares a link to a simple calculator web app and asks: **"Build a calculator that matches this reference app's functionality and styling as closely as you can."** The reference is a standard four-function calculator in the familiar mobile-calculator style: - A **display** at the top showing the current value (starts at `0`). - A **button grid** below it with: digits `0–9`, a decimal point `.`, the four arithmetic operators `+`, `−`, `×`, `÷`, equals `=`, clear `AC`, sign toggle `+/−`, and percent `%`. Expected behavior (the interviewer expects you to reproduce what a normal calculator does): - Tapping digits builds up the current number on the display; tapping an operator stores it as the pending operation; tapping `=` applies the pending operation and shows the result. - Chained input like `2 + 3 + 4 =` evaluates as you go (left to right), showing intermediate results. - `AC` resets the calculator to its initial state. - The layout and visual style should be a close approximation of the reference (button grid, display alignment, operator column styling). You may use vanilla JavaScript or a framework of your choice. Talk through your decisions as you code — you will be evaluated on correctness, code cleanliness, and visual fidelity, not just on "getting numbers to add." ```hint Model the state explicitly Do not derive the calculator's behavior from the DOM or from string parsing of the display. Keep a small explicit state machine, e.g. `{ display, storedValue, pendingOperator, overwriteNext }`, where `overwriteNext` marks that the next digit starts a **new** operand (right after an operator or `=`). Every button press is a pure transition on this state. ``` ```hint Enumerate the tricky sequences early Before coding, list the sequences that break naive implementations: `2 + 3 + 4 =` (chained operators must evaluate eagerly), pressing `=` twice, changing your mind (`2 + × 3` should replace the operator), a second `.` in the same operand, typing a digit right after `=`, and leading `0`s. Handling these deliberately is most of the interview signal. ``` ```hint Separate the engine from the UI Put all calculator logic in a pure function like `next(state, key) -> state` with no DOM access. The UI layer just renders `state.display` and forwards button presses. This makes the logic easy to reason about, easy to test by calling it in sequence, and keeps the rendering code trivial. ``` ### Constraints & Assumptions - Timebox: roughly 45–60 minutes, live coding with screen share. - Any framework (React is common) or plain HTML/CSS/JavaScript; no third-party calculator or math-expression libraries. - Standard immediate-execution calculator semantics (left-to-right as operators are pressed), not mathematical operator precedence, unless the interviewer says otherwise. - Evaluation dimensions stated by the interviewer: functional correctness, code cleanliness and naming, edge-case handling, how closely the look matches the reference, and communication throughout. ### Clarifying Questions to Ask - Should operators follow immediate execution (`2 + 3 × 4` → `20`) or mathematical precedence (`→ 14`)? - What should repeated `=` presses do — repeat the last operation (like many phone calculators) or be a no-op? - How should division by zero be displayed (`Error`, `∞`, something else)? - Is there a display length limit, and how should long decimals be rounded or truncated? - Is keyboard input required, or is mouse/touch-only acceptable? - How pixel-perfect should the styling be — exact colors and spacing, or a close approximation? ### What a Strong Answer Covers - **State modeling**: a small, explicit state shape that cleanly distinguishes "typing an operand" from "just applied an operator/equals," rather than ad-hoc flags scattered through event handlers. - **Edge-case handling**: chained operators, repeated equals, operator replacement, duplicate decimal points, leading zeros, digits after `=`, division by zero, and display overflow. - **Code organization**: a pure calculation engine separated from rendering, clear naming, and small functions — the interviewer explicitly evaluates cleanliness and the ability to debug by reading, without running the code. - **Visual fidelity**: a proper button grid (e.g. CSS Grid), sensible sizing/spacing, and styling that visibly tracks the reference app. - **Communication**: stating assumptions, narrating trade-offs, and testing key sequences out loud as they are implemented. ### Follow-up Questions - How would you add keyboard support and make the calculator accessible (focus management, ARIA roles, announcing results to screen readers)? - How would you extend the engine to support full expressions with operator precedence and parentheses? - How would you unit test the calculator engine, and which sequences would be in your test suite? - `0.1 + 0.2` shows `0.30000000000000004` — how do you deal with floating-point artifacts in the display?