Compare manual JSON serialization versus json_serializable

WHAT THIS TESTS: This question probes whether you understand the difference between compile-time developer ergonomics and runtime behavior in Dart. Interviewers want to see that you recognize code generation as a build-step tool that does not affect end-user performance, and that you can weigh boilerplate verbosity against team scalability and long-term maintenance.

A GOOD ANSWER COVERS: A strong answer hits four points in order. First, manual methods give you total control over parsing logic and eliminate any build-step dependency, which is useful for one-off scripts or environments where build_runner is unavailable. Second, manual serialization creates brittle boilerplate that drifts from backend contracts, requires hand-written tests for every field change, and becomes error-prone as nested objects grow. Third, json_serializable automates adapter generation, enforces consistency through annotations like JsonKey, and scales cleanly when you have dozens of models because adding a field is a one-line change. Fourth, the generated approach introduces compile-time latency from build_runner, adds package dependencies that can version-lock, and occasionally fights you with custom types or non-standard JSON shapes that need handwritten converters anyway.

COMMON WRONG ANSWERS: A red flag is claiming that generated serialization slows down app startup or runtime frame rendering; the code is plain Dart at runtime, so performance is identical to handwritten equivalents. Another mistake is asserting that manual parsing is inherently simpler for small teams without acknowledging the hidden cost of maintaining fromJson contracts across a growing codebase. Interviewers also frown on candidates who dismiss code generation because they forgot to run build_runner once; that signals unfamiliarity with standard Flutter tooling rather than a principled engineering stance.

LIKELY FOLLOW-UPS: Expect the interviewer to push on edge cases. They might ask how you handle renaming a field while keeping backward compatibility with existing cached JSON. They could ask when you would reach for built_value or freezed instead of json_serializable. Another common thread is version control strategy: do you commit generated files or ignore them and let CI run build_runner? Finally, they may ask how you inject custom parsing logic, such as converting Unix timestamps into DateTime objects, when the generator does not support it out of the box.

ONE CONCRETE EXAMPLE: Imagine a backend change that adds an optional userSettings object nested inside every profile response. On a team with fifty models, manually writing the fromJson and toJson methods for the new nested class, plus null-safety checks, takes roughly thirty minutes and usually introduces two or three copy-paste bugs. With json_serializable, you define the new UserSettings class with the correct annotations, add the field to Profile, and run build_runner; the generated code handles nullability, nested serialization, and type safety in under ten seconds. The tradeoff is that a new teammate must understand the annotation syntax and the build step, but the team avoids an entire class of human error.