From Interview Task to Production Feature

When I started the interview process at WunderGraph, I didn't think much of the take-home assignment. I assumed it would just be a solid frontend task to showcase how I think. What I did not expect was that it would end up in production with actual users.

This is the story of how a single interview task became my first open-source contribution to Cosmo—and marked the start of my journey at WunderGraph

I applied for a Senior Frontend Engineer role. The assignment was to build a small but thoughtful UI feature inside Cosmo Studio , WunderGraph's frontend for managing GraphQL federation.

The task was to allow users to share their current Playground session with a link. It sounded simple on paper, but it involved:

• Selecting which parts of the session to include (operation, variables, headers)
• Compressing and encoding the selected state into a shareable URL
• Restoring the session state cleanly on page load
• Designing a smooth UI flow for it all, and handling edge cases gracefully

I went all in. I treated it like a real feature, not just a task. I took time to understand the architecture, asked questions when I got stuck, wrote tests, and focused on the full experience. I had no idea it was based on an actual customer request.

After submitting the assignment, I had a review call with WunderGraph's CTO, Dustin . He liked the approach and suggested that, if I was interested, I could clean it up and raise a PR to the main repo as an open-source contribution.

That's when it clicked: this thing might actually go live.

It didn’t ship right away. After joining the team, I spent some time refining the feature before finally pushing it into production.

I cleaned up the code, polished the user experience, and addressed feedback before submitting this PR . It introduced a modal-based UI for generating shareable session links that are encoded via lz-string. The goal was to make it easier for teams to collaborate, debug, and share reproducible setups.

Shortly after it shipped, I found out it was already being used in production by companies like SoundCloud . That was a surreal moment.

While implementing the feature, I made a few deliberate technical and UX decisions to keep the experience clean, performant, and intuitive:

• Compression Strategy: I used lz-string to compress the session state. It's widely supported, easy to use in the browser, and produces small payloads that are suitable for URLs without relying on newer APIs like CompressionStream, which don't work in older browsers.

• State Restoration: The logic restores the active Playground session on load using a custom query parameter (playgroundUrlState). It handles both optional and required fields carefully, only restoring headers and variables if they were selected and present.

• UI Edge Cases: The share modal disables options when no data is available (like headers or variables), shows toast messages when the URL is too long, and handles hydration errors with clear messaging. These patterns ensure that the feature feels stable, even in messy or unexpected scenarios.

• No Backend Dependence: The feature is completely stateless, requiring no backend logic or persistence—all state is stored directly in the URL.

• Navigating a Custom GraphiQL Setup: WunderGraph's Playground builds on top of GraphiQL with several extensions and internal overrides. Understanding the internal structure and identifying the right integration points took some effort — but once it clicked, it was a rewarding challenge.

These kinds of product and architectural decisions are what made this fun: solving small but meaningful UX problems while thinking about scale, resilience, and clarity.

I also wrote the official developer-facing documentation for the feature: Sharing Playground Sessions . The guide walks users through:

• What's included and not included in the link
• How to generate and share it
• Security considerations
• Use cases for collaboration and debugging

This was my first time contributing to public OSS docs, and I loved being able to treat documentation as a first-class part of the product.

Looking back, this experience taught me a lot:

• Start with ownership: I treated the assignment like a real feature.
• Communication matters: Thoughtful PR descriptions and async reasoning helped build trust early on.
• Know what to prioritize: Done is better than perfect, especially when it solves a real user problem.

Finalizing and shipping this feature was more than just a technical milestone—it showed me that WunderGraph genuinely values trust, autonomy, and thoughtful engineering. The team was supportive from the start. They were quick with feedback, open to ideas, and always willing to dive into details together. I got to dive into a complex codebase, shape the user experience, and contribute to something real from day one.

If that sounds like your kind of work, you might enjoy being part of the team. We're hiring .

Curious about the feature? Check it out in Cosmo .

Questions or feedback? I'd love to connect — you can find me on LinkedIn or drop a note in the WunderGraph Discord .