Code Review of TypeScript Against a Design Doc: Nulls, Interfaces, Logic Bugs, Tests

You receive about 200 lines of TypeScript together with the design doc that the code is meant to implement, and you review it as you would a pull request: you write your feedback as review comments and do not change the code. The report names four focus areas: the handling of `undefined` and `null`, the interface definitions, bugs in the business logic when the code is checked against the design doc, and whether the test cases are reasonable. The code and the design doc used in the interview are not reproduced in the report. Explain how you would carry out the review, and for each of the four focus areas describe what you would look for and show the kind of review comment you would write, using short code fragments of your own as illustrations. ```hint Doc before diff Think about what you should extract from the design doc before reading the first line of code, and how that helps you find logic bugs instead of only style issues. ``` ```hint Where undefined hides List the places in TypeScript where a value can be `undefined` at run time even though its declared type looks safe. ``` ### Clarifying Questions - Is the project compiled with `strict` (in particular `strictNullChecks`), and can I see the `tsconfig` and lint settings? - Should I label comments by severity, for example blocking, suggestion and nit? - When the code, the tests and the design doc disagree, is the design doc the source of truth, or could it be out of date? - Should I also comment on naming and style, or keep to correctness? ### What a Strong Answer Covers - Reads the design doc first and turns its rules into a checklist of behaviours to verify in the code and in the tests - Finds `null` and `undefined` hazards that the types hide: optional fields, lookups, non-null assertions, casts and falsy checks - Judges the interfaces: required versus optional fields, `any`, unions for states, and agreement with the doc's data model - Traces each business rule through the code, including boundaries and error paths - Checks that tests cover the doc's rules and boundaries, assert behaviour rather than implementation, and actually wait for asynchronous results - Writes specific, actionable, prioritised comments in a constructive tone ### Follow-up Questions - You find more issues than you can write up in the time left. How do you decide which to comment on? - The code contradicts the design doc, but all the tests pass. What do you write, and to whom? - Which compiler options or lint rules would have caught some of these issues automatically?