Explain What You Would Change When Rebuilding a Technical Project

Choose a technical project you have completed. Explain what you would change if you could build it again, using what you learned after the original decisions were made. ### Constraints and Clarifications Use a real project and distinguish hindsight from information available at the time. Describe one or two meaningful improvements in architecture, implementation, validation, or delivery, rather than replacing the entire project with a fashionable technology stack. Keep confidential details and personal identities out of the explanation. ### Clarifying Questions - What problem did the original project solve, and which constraints shaped its design? - Which later observation showed a weakness or unnecessary cost in that design? - Would the proposed change have been feasible under the original time, team, and dependency constraints? - How would you verify that rebuilding this way improved the outcome? ```hint Connect the redesign to observed evidence An incident, maintenance burden, or usage pattern can justify a different design. State that evidence before naming the technology or process you would change. ``` ### What a Strong Answer Covers - The original project's purpose, relevant constraints, and the speaker's contribution. - A specific design or delivery choice and its observed consequences. - A proposed improvement with a causal explanation of why it addresses those consequences. - Costs, migration or delivery risks, and reasons the new choice might not have been appropriate initially. - A validation plan and a distinction between a worthwhile rebuild change and unnecessary overengineering. ### Follow-up Questions 1. Which part of the original design would you keep, and what evidence supports keeping it? 2. How would you prioritize the improvement if you had to evolve the running system rather than rebuild it? 3. What result would convince you that the proposed improvement was not worth its added complexity?