I was interviewing for a solutions engineering role and the company sent over a challenge document: pick three technical problems from a list, prepare a presentation, present to a panel. One of the required challenges came with a note.
“The expectation of this challenge is to perform a demonstrable scenario beyond utilizing PowerPoint.”
I was told later that most candidates get a couple of weeks to prepare. All I knew was that I had 48 hours.
The document had nine optional challenges and four required ones. Pick three total. I could have picked three, prepared three clean answers, maybe shown a Postman walkthrough or a quick script for the demo portion. I figured that’s what most people would do. It would have checked the box.
I didn’t think about it that way. I looked at the challenge and thought:
“How would I handle this if it were a real engagement? If I’d just finished discovery with a prospect and it was time for the follow-up pitch?
I won’t walk in with homework answers. I’ll tell a story.
I’ll show them I understand their world, make them feel the weight of the problems they’ve been living with, and then show them what solving those problems actually looks like.”
That’s how you sell. You’re not the hero. You’re the guide. You’re turning their pain into a path forward.
So that’s what I decided to do. Skip the homework and run a meeting.
I knew what would separate me from every other candidate. Not the slides. Not domain knowledge. I’d been doing this for many years. It was the demo. Nobody else was going to walk in with a working platform that talks to a live cloud tenant. If I nailed the demo, the rest would follow.
So I allocated my time accordingly. Most of it went to the demo. The deck got just enough. Practicing got the remainder.
I’d never built anything with this tech stack before. Python, Streamlit, SQLite. I’d spent years working with Azure AD, but writing a custom integration against the Graph API was new territory. The domain knowledge was there. The development experience wasn’t, but that’s exactly the kind of gap AI closes.
I spent the first six hours not writing a single line of code.
I followed a methodology called BMAD (Build More Architect Dreams), an open-source AI development framework that walks you through the full lifecycle from ideation through agentic implementation. I’d already been using it extensively on a much larger project, a full content operations platform I’d been building for months. By the time this challenge landed, BMAD was how I built anything that needed structure. I wasn’t learning a methodology under pressure; I was running one I already trusted.
In six hours, BMAD helped me produce:
- A product brief
- A PRD with 41 functional requirements and 25 non-functional
- Architecture decisions
- A UX specification
- 4 epics and 10 stories with acceptance criteria
- An implementation readiness report that validated everything was consistent before a single function got written
The dev agents, the code reviews: all BMAD. The testing discipline was something I’d built on top of it. I’m a firm believer in test-driven development. Write every test before writing any implementation code, have a separate agent review the tests to make sure they’re comprehensive, and only then move forward with the build. That’s not default BMAD. That’s how I’ve adapted it to work for me. It’s why the project ended up with a 3:1 test-to-code ratio.
Six hours. Zero code. That was 18% of my total time, and it was the most important investment I made.
Every module knew exactly what to build, what to return, and what not to touch. When the coding started, AI wasn’t guessing. It was executing against a clear spec. That’s the thesis: the planning is what makes the speed possible.
The first three stories laid the foundation. Database schema. Azure AD client. Dashboard UI shell. These were the slowest ones, and not because they were the most complex. They were slow because I was still ironing out how the workflow actually ran. The code reviews surfaced things that needed fixing, not just in the code but in the process itself. Configuration that should have been in environment variables. Documentation gaps. Patterns that needed to be established so the next story wouldn’t hit the same friction.
That’s the part people don’t see. The early stories aren’t just building the product. They’re building the machine that builds the product. You fix the snags, tighten the workflow, and by the time you’re three or four stories in, AI just flows. It knows the patterns. The boundaries are defined, and the friction is gone.
Then velocity kicked in. Stories shipped in rapid succession. Aggregation engine: 12 minutes from implement to merge. Correlation engine: 20 minutes. Joiner workflow: 19 minutes. Each one faster and cleaner because every prior story had smoothed the path.
Then I closed the laptop, went inside, and had dinner with my family.
This is 33 hours of work, not 33 hours at a computer. I ate. I slept. I knew that if I showed up to the panel groggy and red-eyed, nothing else would matter. The last commit that night was around 11:30. The first one the next morning was around 8:30. Nine hours off, deliberate, because managing your energy is part of managing your time.
I got up the next morning and kept going. Demo operations. UX polish. Orphan governance. Final integration fixes.
33 hours from first commit to last:
- 48 commits
- 11 pull requests
- 137 tests at a 3:1 test-to-code ratio
- Every story went through code review
- No shortcuts
The platform handled the full identity lifecycle. Someone gets hired, their account gets created. They change departments, the system detects it and pushes the update. They leave, their account gets disabled. Orphaned accounts with no matching record get flagged for remediation. All of it live, against a real cloud tenant. Not mocked. Not simulated. Working.
That left the deck.
I already had the talk track built with Claude Code. I knew the narrative: start with what the prospect is living with, push on the pain they’ve been tolerating, show them what it looks like when those problems are actually solved, and then open the conversation about where this goes next. A real pitch, not a challenge response.
I used Gamma to build the slides. The free version gives you 10 slides, which turned out to be a useful constraint. Ten slides forced me to figure out what actually mattered. I gave it the talk track framework, it generated the initial slides, and I spent about two hours cleaning them up. Refining the flow. Making sure the progression felt like a conversation, not a presentation.
Two hours. From nothing to a polished deck using another AI tool in the stack.
The night before the panel I ran through the whole thing three times. Not just the words, but the transitions. The moment you leave the slides and switch to the live demo, the moment you come back. Making it feel like one conversation, not three separate challenge responses bolted together.
I got up the next morning and did it one more time. I wasn’t nervous about presenting, but I needed some muscle memory.
Here’s what I want you to notice about how the time broke down.
The demo took roughly 33 hours. The deck took 2. Practice took about 3 or 4. That ratio was deliberate. I knew where the differentiation was and I bet my time there. AI is what made that bet possible.
Without it, 33 hours gets you a half-finished prototype and no deck. With it, you get a production-quality platform with 137 tests, a polished presentation, and time left over to practice the delivery.
I got the job.
I couldn’t have built that platform by myself. If you gave me two months instead of two days, I still couldn’t have built it by myself. I don’t have the development experience. That’s not false modesty, it’s just true. What I had was the ability to think through the problem, break it down, and conduct an orchestra I couldn’t play a single instrument in.
But that ability didn’t come from nowhere. When I first saw what AI could do, I didn’t know where it would lead. I’m still not sure I do. But I knew there would come a point where if I was ready, I could pull the trigger. So I started getting my reps in on everything. I built a content operations platform from scratch just to learn. I found BMAD, adopted and customized it. I built a repo just to manage my liquor cabinet so I could have better conversations with AI about cocktails. Serious stuff, silly stuff, it didn’t matter.
Every project taught me something. When to kill an agent that’s going in circles and start fresh. That TDD catches what you’d otherwise miss at 2am. That the first few stories are always slow because you’re building the workflow, not just the product.
There’s a saying: luck is when opportunity meets preparation. The 48 hours was the opportunity. Everything before it was the preparation. I didn’t know a panel interview was coming, and I didn’t know Annie would ask about a blog. But when those moments showed up, I was ready because I’d already been doing the work.
The tools will keep changing. The models will keep getting better. But the reps are what give you the intuition to know what to build, how to break it down, and when AI is giving you something good versus something that just looks good. That’s not something you can read about. You have to do it.
In my first post, I built a blog in three hours on a Tuesday afternoon with no stakes. Here, I had 48 hours with my career on the line. Same approach. Same reason it worked.
What compounds isn’t the speed. It’s the discipline behind it.
Get notified when I publish.
What worked, what didn't, what I'd do differently. Delivered to your inbox.