Write a conventional commit for a non-US date sorting bug

What's really being asked

This question probes whether you view commit history as a primary communication channel between developers, release tooling, and future maintainers. The interviewer cares about your fluency with the Conventional Commits specification and your ability to justify structure beyond habit. They want to see that you understand how a commit message drives automated CHANGELOG generation, SemVer bumps, and root-cause archaeology.

The full answer

First, the candidate should pick the correct type and scope, such as fix(date-parser):, because the change patches a bug in a specific subsystem. Second, the subject line should be imperative, concise, and under 50 characters, for example fix(date-parser): handle locale-aware date sorting. Third, the body should explain the what, why, and impact in short paragraphs: it should note that the sorter previously assumed US MM/DD/YYYY formats, causing non-US dates to parse incorrectly and return wrong order; it should describe the fix, such as switching to ISO parsing or locale detection; and it should mention the user-visible impact, like corrected sorting for international users. Fourth, the candidate should articulate the persuasive and documentary value: the type fix signals a PATCH release to SemVer-aware tooling, the scope helps reviewers filter history, and the body prevents future developers from reverting the change out of confusion. Fifth, they should mention that this structure enables automation, including release notes and downstream CI triggers.

The mistakes people make

Vague subjects such as fixed bug or sorting issue waste the most important real estate and force readers to open the diff. Passive voice like date sorting was fixed obscures agency and intent. Omitting the body entirely leaves the locale nuance undocumented, which means the next engineer might reintroduce the US-only assumption. Treating footers as optional decoration rather than structured metadata misses the chance to reference issue trackers or breaking changes. Finally, confusing feat with fix or omitting the exclamation mark on a breaking change shows weak grasp of the SemVer contract.

What usually comes next

The interviewer might ask how you would handle a breaking change to the date API, such as requiring consumers to pass a locale parameter, and where the BREAKING CHANGE footer or exclamation mark belongs. They might ask how you enforce this convention across a team, probing for git hooks, commitlint, or PR templates. They might also ask how you write a body when the fix is a one-line change, testing whether you still document the surrounding context.

A concrete example

fix(date-parser): handle locale-aware date sorting. Previously the sort utility parsed all date strings with a hardcoded US locale, causing DD/MM/YYYY entries to misorder for users in the UK and EU. This change detects the browser locale and falls back to ISO 8601 when ambiguous. Sorting now respects regional formats without manual configuration. Closes #442.