Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GH-167: Update FAQ answers to highlight mistake handling lessons #171

Merged
merged 1 commit into from
Mar 3, 2025
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
48 changes: 20 additions & 28 deletions systems/cms/content/pages/faq.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,47 +9,39 @@ questions:
Tell me about a time you made a mistake. How did you communicate that
mistake?
answer: >
In a previous project, I had the opportunity to build a custom in-app
notification system to replace an existing SaaS solution. We needed to
decide on the technical stack and approach to integrate business logic and
tooling effectively.
#### Situation:


Without conducting deep research or strategic evaluation, I proposed using
ActivityPub for message transfer and InversifyJS for dependency injection,
assuming they would be a good fit. However, as development progressed, we
encountered significant challenges.
In a previous project, we needed to replace a third-party SaaS
notification system with an in-house solution. I proposed using
ActivityPub for message transfer and InversifyJS for dependency injection.


* ActivityPub was overly complex for our use case, making implementation
difficult.
#### Task:

* InversifyJS had an unfriendly developer experience, which slowed down
our progress.

My role was to design the system architecture and ensure smooth
implementation. However, I made the mistake of not validating the
complexity and feasibility of these technologies before committing.

As a result, our team of four developers spent two weeks solely on backend
configuration, barely managing to get a working prototype—with no frontend
demo ready by the deadline. We realized these technology choices were a
mistake only after development was well underway.

#### Action:

When we missed the development timeline, I acknowledged my mistake during
the retrospective meeting. I took full responsibility, apologized to the
team, and committed to refactoring the complex codebase in the future.
However, before we got the chance to revisit it, the business requirements
changed, and the project was ultimately deprecated.

Once development started, we faced unexpected challenges—ActivityPub was
overkill for our use case, and InversifyJS added unnecessary complexity.
After two weeks of backend work, we still had no frontend demo ready.
Realizing the issue, I acknowledged my mistake during the sprint
retrospective, apologized to the team, and proposed alternative solutions.

This experience taught me the importance of validating technical decisions
upfront. Had I conducted a proof of concept (PoC) or gathered more
feedback before committing, we could have avoided wasted effort and
delays.

#### Result:

Now, before introducing new technologies into a project, I thoroughly
evaluate feasibility, conduct PoCs, and seek input from colleagues to
ensure alignment with the project’s needs.

Although we missed our initial timeline, we learned from the mistake and
avoided making similar choices in future projects. This experience taught
me to validate technical decisions with PoCs before full adoption,
ensuring they align with project needs.
group: "\U0001F6E0 Problem-Solving & Challenges"
- question: >-
Tell me about a time when you had to develop a new skill. How did you
Expand Down