[DOCS] Add questions

[ChanHHOO]

Background

In this assessment, Three questions are required.

[claude]

Code Review: PR #28 - Add Questions Documentation

Summary

This PR adds a questions.md file documenting the technical decisions, rationale, and reflections on the NEM12 parser project. The changes are documentation-only with one minor dependency cleanup in README.md.

---

✅ Strengths

1. Excellent Technical Communication

• Clear, honest explanations of design decisions and trade-offs
• Good self-reflection on what could be improved with more time
• Demonstrates understanding of architectural principles (Layered Architecture, DI patterns)

2. Transparent About Constraints

• Honest assessment of the DI limitation without Spring Framework
• Recognition of the missing CI pipeline for automated testing
• Shows maturity in acknowledging technical debt and trade-offs

3. Well-Structured Documentation

• Answers all three questions clearly
• Proper markdown formatting
• Good balance of technical depth and readability

---

📝 Suggestions for Improvement

1. Code Quality & Best Practices

Minor README.md cleanup is good:

• Removing the "Kotest" dependency line is correct since it's not actually used
• ✅ This aligns the documentation with the actual dependencies

2. Documentation Enhancements

questions.md:1-16 - Technology Rationale

While you mention "object-oriented design principles," it would strengthen this section to mention specific Kotlin features you used (e.g., data classes, sealed classes, extension functions, null-safety). For example:

• Did you use Kotlin's sealed class for the ParserState or FailureReason?
• Did you leverage Kotlin's use function for resource management?
• Any extension functions for cleaner code?

questions.md:26-40 - What Would You Do Differently

Your acknowledgment of the DI limitation is excellent. Consider mentioning specific lightweight DI options you'd consider:

• Koin (popular Kotlin DI framework)
• Kodein
• Or even a simple Service Locator pattern

This shows you've thought through practical alternatives beyond "use Spring."

questions.md:42-59 - Design Rationale

The reference to "in #12 PR" is helpful but consider:

• Adding the actual PR link: (in #12 [PR](https://github.com/ChanHHOO/flo-energy-tech-assessment/pull/12))
• Or briefly summarizing what that refactoring included

---

🔍 Potential Issues

No Critical Issues Found

This is a documentation-only PR with minimal risk. The changes are:

1. ✅ Removing incorrect Kotest reference (good)
2. ✅ Adding well-written documentation (good)

---

🚀 Performance Considerations

N/A - Documentation changes have no performance impact.

---

🔒 Security Concerns

N/A - No security implications for documentation changes.

---

🧪 Test Coverage

No test changes needed for documentation. However, your self-reflection in questions.md about missing CI is spot-on. Consider adding a GitHub Actions workflow in the future to automatically run tests and code quality checks on PRs.

---

🎯 Overall Assessment

Verdict: ✅ APPROVED

This PR demonstrates:

• Strong technical communication skills
• Self-awareness about architectural decisions
• Honest reflection on trade-offs and improvements

Minor suggestions above are for enhancement only - none are blockers.

---

📚 Additional Comments

Your documentation style is clear and professional. The honest acknowledgment of limitations (DI without Spring, missing CI) shows maturity. These questions.md responses would serve well in a technical interview or design review.

One final thought: Consider keeping this documentation style for future features. Having design rationale documented upfront (or in PR descriptions) helps reviewers and future maintainers understand the "why" behind decisions.

Great work! 🚀