Software Engineer interview questionsTechnical Interview round

Purpose

Frames the hour as a ticket on an unfamiliar codebase, which is how this job meets most of its bugs, and makes asking for evidence part of the work. Say once that there is more and leave it there; which facts the candidate asks for is part of the read.

Purpose

Debugging from evidence, in code the candidate did not write. The read is whether one mechanism is made to explain every group of tickets on the page — this week's, April's and Australia's — rather than "the clock change" being recognised and left there. Most candidates find the stored offset. Fewer explain April's tickets and why re-saving cured them, and fewer still say who is next.

Signals to score

• Starts from early rather than late: nothing between the scheduler and the inbox can send an email early, which clears the template and the batch size
• Reads the handler: the setting is a minute of the UTC day, fixed with whatever offset the browser had when the user pressed Save
• Connects it to Sunday: a time saved in summer is now an hour early, and one saved in winter was an hour late all summer
• Explains the March and April tickets with the same mechanism, including why re-saving the setting made them go away
• Explains Australia and New Zealand as the mirror image: their clocks went forward, so times saved in their winter now arrive late
• Says who is next: most of North America from this Sunday, and Europe again in March
• Rules out the scheduler's move: a wrong clock would move default-time users and North America too
• Asks for the check that would prove it — whether any default-time user is affected, or when the affected users saved their setting
• Notices the flaw is wider than daylight saving: a setting saved from a browser on another zone's time is wrong by hours all year

Follow-up questions

• Can anything after the scheduler make an email arrive early?
• Why did re-saving the setting cure April's tickets?
• Who gets the wrong time next, and when?
• What would you ask me for, to be sure?

Purpose

Tests change risk where a mid-level engineer meets it most: a colleague's pull request whose arithmetic is right. Its defects are in who its `WHERE` clause selects, in what the handler still stores, and in the nights and the day the change has to survive — found by asking questions, not by checking the sums.

Signals to score

• Notices that the migration also moves users who saved in winter, who are on time today and would be an hour late after it
• Asks whether every `Europe/` zone changes its clocks, and sees users in zones that never change moved an hour wrong
• Says it does nothing for Australia and New Zealand or for North America on Sunday, and has to be reversed by hand in March
• Sees that the new handler still freezes an offset at the moment of saving — the profile zone's instead of the browser's — so every save made in summer repeats the bug
• Reads the test pinned to 15 January as blind to the bug: it checks what a winter save stores, never when it is sent in summer
• Proposes storing the chosen local time with the profile's zone and working out each send in that zone, as the default-time path already does
• Says what happens to a chosen time that does not exist, or happens twice, on a changeover night, and makes it one email either way
• Plans the backfill: rebuilds each local time from the stored minute and the offset in force when it was saved, as a dry run first, checked against choices it knows
• Covers the switchover day, so that no user gets two digests or none when the new schedule takes over
• Orders the work against the calendar: what must be live before Sunday, and what can wait for March

Follow-up questions

• A user in Munich saved 08:00 in January. What does this migration do to her?
• Which zones start with `Europe/`, and do all of them change their clocks?
• With the new handler, what does a Berlin user who saves 08:00 in July store?
• In your version, a user chose 02:30 in Berlin. What happens on the last Sunday of March?
• On the day the new schedule takes over, what stops a user getting two digests?

Purpose

Separates knowing the names of test types from choosing tests. Useful answers start from the property that broke — one digest a day, at the time the user chose — test it where it is cheap and cannot flake, and say which tests are not worth their upkeep.

Signals to score

• Says the test was not flaky: it failed because the date it ran on changed, and the code depended on that date
• Says what was wrong with the test itself: its expected value was a summer constant, so it could only pass in one season
• Injects the clock and pins it to chosen instants, the changeover days among them, instead of reading today's date
• States the property: one digest per user per local day, at the chosen local time whenever that time exists
• Tests the days the clocks change in a zone with the EU's dates, one with other dates, and one whose clocks never change
• Tests 02:30 in Berlin on both changeover nights: one digest each, never two and never none
• Generates cases over every day of a year and many zones, asserting the property instead of hand-written values
• Tests the backfill as a dry run on a production snapshot, judging the rebuilt times against known choices rather than only that it finished
• Adds a production check: users with no digest or two in one local day, or a send minute that differs from the chosen one, alerting a person
• Names what not to test — the time zone library's own conversions — and keeps tests whose expected values depend on today's date out of the suite

Follow-up questions

• It failed on every run since Monday. Was it flaky?
• Where should a test get the current date from?
• Which zones and dates would you pick, and why those?
• How do you test that 02:30 on the last Sunday of October sends once?
• In March, how would you know within a day if this had come back?