Published on

When Building the Wrong Thing Taught Me the Right Lesson

Authors
  • avatar
    Name
    Sedky Haider
    Twitter

I was once invited to apply to an AI company that builds developer-facing agents.

(Tangential) My advice:  Always respond to these invitations.
**Especially** if you are happy in your current position.
You meet interesting people and build your network.
You learn more about a given market or product.
You increase self-awareness in your strengths + weaknesses

The take-home assignment was clear: implement an automation integrating their solution with Github using the LLM APIs.

Heck -- I have already built, rolled out, and use these solutions every single day. I could do this with my eyes closed. I've worked and built with AI agents in Slack, GitHub slash commands & label workflows, and more.

Straightforward enough.
But I didn’t do that.

Instead of building a small API demo, I created an end-to-end Slack integration — a full developer workflow where you could list, analyze, and close GitHub issues without ever leaving Slack.

It worked beautifully.

It was practical.

It was closer to how developers actually work.

And it completely missed the brief.

The Hard Truth

When the feedback came in, it was short and polite:

The solution didn’t fully align with the prompt or introduce new functionality beyond what already exists.

Translation: You built something cool — but not what we asked for.

They also already had a Slack integration — and instead of building on top of it, I ignored it and built my own from scratch.
That was the second mistake. In my mind, I was demonstrating technical depth and ownership; in theirs, I was reinventing the wheel.

They were right.
I didn’t fail technically; I failed contextually.
I solved a different problem than the one being evaluated.

What That Moment Clarified

It stung at first.
But after I cooled off, it clicked:

Even great solutions fail if they’re scoped for the wrong lens.

Engineering isn’t only about what you build. It’s about who you’re building it for and what problem they think they have.

Sometimes the difference between success and rejection isn’t skill or creativity. It’s empathy. It's realizing what level your audience is speaking at, and matching them.

Vision vs. Alignment

That experience reminded me of something subtle:
Take-homes are not an invitation to innovate.

Sometimes the right move is to deliver exactly what’s asked.

There’s a time for pushing boundaries, and a time for showing you can follow them.

The Takeaway

A few lines I keep coming back to:

  • Match the solution to the moment. Not every task needs reinvention.
  • Read the altitude. Deliver detail to engineers, vision to leaders.
  • Don’t confuse capability with context. Being able to build more doesn’t mean it’s the right play.

That assignment didn’t show my best work, but it taught me one of my best lessons:
The gap between a good engineer and a great one isn’t technical — it’s contextual.

And sometimes, learning that means building the wrong thing first.

View on GitHub