Katkat
Back

Build a Web Calculator That Matches a Reference App

Jane StreetFrontend Engineer · Technical Screen
MediumFrontend EngineerTechnical ScreenSoftware Engineering Fundamentals

Last updated

This question evaluates frontend engineering competencies—interactive UI implementation, state management, event-driven logic, and visual layout fidelity—within the domain of software engineering fundamentals and web frontend development.

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."

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?

Hints

Hint 1

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 2

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 3

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.

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?