Writing an Effective Retrospective

The Three Retrospective Prompts

When submitting a solution, you'll respond to three specific questions. Each serves a purpose and gives you an opportunity to reflect on different aspects of your work.

Prompt 1: "What are you most proud of, and what would you do differently next time?"

This prompt asks you to evaluate your own work critically and constructively.

What to include:

• Specific features or code patterns you implemented well
• Design decisions that worked out successfully
• Problems you solved elegantly
• Things you learned that you'd apply differently

Example of a strong response:

I'm really proud of how I implemented the mobile navigation. I used a CSS-only approach with a checkbox hack, which keeps the JavaScript footprint minimal. The animation feels smooth and the accessibility is solid - I tested it with VoiceOver and keyboard navigation works throughout.

Next time, I'd plan my CSS custom properties from the start rather than adding them incrementally. I ended up refactoring colors twice, which could have been avoided with better upfront organization.

Weak response to avoid:

I'm proud I finished it. Next time I'd make it better.

Prompt 2: "What challenges did you encounter, and how did you overcome them?"

This is your chance to share the struggles that don't show up in the final code.

What to include:

• Specific bugs or problems you faced
• Concepts that were difficult to understand
• How you researched and found solutions
• Resources that helped you

Example of a strong response:

The biggest challenge was getting the card grid to behave responsively without hard-coded breakpoints. I wanted the cards to flow naturally based on available space. After trying several approaches, I discovered CSS Grid's auto-fit with minmax(), which solved it elegantly.

I also struggled with the hover state on touch devices - it was getting "stuck" after tapping. I learned about the @media (hover: hover) query and used it to only apply hover effects on devices that truly support hover.

Weak response to avoid:

It was hard but I figured it out by searching online.

Prompt 3: "What specific areas of your project would you like help with?"

This prompt directly invites the feedback you want most and ensures your solution shows up in the "feedback requested" tab on the /solutions page.

What to include:

• Specific code sections you're uncertain about
• Design decisions you'd like opinions on
• Performance concerns
• Accessibility questions
• Best practices you're unsure about

Example of a strong response:

I'd love feedback on my approach to the form validation. I wrote custom JavaScript rather than using a library, and I'm not sure if my error messaging pattern follows accessibility best practices. Specifically, I'm announcing errors with aria-live, but I'm unsure if the timing is right.

Also, my CSS feels repetitive in the button styles section. Is there a cleaner way to handle the different button variants while keeping the code DRY?

Weak response to avoid:

Any feedback is welcome!

Why Retrospectives Matter

They Attract Better Feedback

Community members are more likely to leave detailed, helpful feedback when they understand:

• What you were trying to achieve
• Where you struggled
• What specific help you need

Generic submissions get generic responses. Thoughtful retrospectives get thoughtful feedback.

They Help You Reflect

The act of writing about your work forces you to think critically about your decisions. You'll often realize things while writing that you hadn't consciously considered:

• "Why did I choose this approach?"
• "What would I do differently?"
• "What did I actually learn here?"

This reflection accelerates your learning far more than simply finishing projects and moving on.

They Create a Learning Record

Your retrospectives become a personal log of your development journey. Looking back at past submissions, you can see:

• Problems you've overcome
• Skills you've developed
• Patterns in your challenges

This perspective is incredibly valuable for recognizing your growth.

Good vs. Weak Retrospectives: A Comparison

Weak Retrospective

Proud of: I finished the project and it looks like the design.

Challenges: Getting things to line up was difficult. I used flexbox.

Help needed: Let me know if you see any issues.

This tells reviewers almost nothing. It doesn't invite specific feedback and doesn't demonstrate any reflection.

Strong Retrospective

Proud of: I implemented a fully responsive testimonials section using CSS Grid with auto-fit, meaning the layout adapts to any screen width without a single media query. I also used the picture element with srcset for art direction on the hero image, loading a cropped version on mobile to keep the subject visible.

Challenges: The pricing toggle was tricky - I needed to animate between two pricing tiers smoothly while keeping it accessible. My first attempt used JavaScript to swap content, but it felt jarring. I eventually used CSS to animate max-height and opacity, triggered by a hidden checkbox. The hidden checkbox meant I could style the toggle as a button while maintaining keyboard accessibility.

Help needed: I'm uncertain about my semantic HTML in the feature comparison table. I used a description list rather than a table because it felt more appropriate for two-column key-value data. Is this the right choice, or would an actual table element be more accessible for screen readers?

This gives reviewers clear context, demonstrates thoughtful problem-solving, and asks a specific question that can be answered helpfully.

Tips for Writing Better Retrospectives

1. Be specific - Name actual CSS properties, JavaScript methods, or design patterns
2. Explain your reasoning - Share why you made decisions, not just what you did
3. Admit uncertainty - It's okay to say you're not sure if your approach is best
4. Ask focused questions - Instead of "any feedback," ask about specific concerns
5. Include code references - Point reviewers to specific files or line numbers if relevant
6. Mention resources - Share articles, videos, or documentation that helped you

Your retrospective is your chance to turn a code submission into a learning conversation. Take the time to write it well, and you'll get far more value from every solution you submit.