At Qwasar we’re known for challenging learners to build databases, simulate distributed systems, and master modern backend technologies but sometimes, a foundational lesson in engineering thinking comes from something simpler, like a probability puzzle involving goats.
Enter the Three Doors Problem, one of our most popular collaborative coding sessions. It’s hands-on, open-ended, and deceptively deep. On the surface, it’s a game show scenario. Underneath? It’s a logic challenge, a modeling exercise, and a crash course in statistics, all wrapped into one.
This kind of session captures what Qwasar is all about: collaborative problem-solving, simulation-driven learning, and building your reasoning as much as your technical skills.
The Three Doors Problem: Would You Change Your Choice?
You’re a contestant. There are three closed doors. Behind one: a car. Behind the other two: goats. You pick a door. The host, who knows what’s behind all the doors, opens one of the two remaining doors to reveal a goat.
Now you’re faced with the question at the heart of the puzzle:
Do you stay with your original choice or switch to the other unopened door?
Most people guess. At Qwasar, you prove it with code.
Why Switching Works (Even If It Feels Wrong)
At first glance, it might seem like your odds are 50/50. Two doors remain, after all. But that intuition is misleading—and that’s exactly what makes this challenge so powerful as a teaching tool.
Here’s the logic:
- When you first pick, there’s a 1 in 3 chance you chose the car.
- That means there’s a 2 in 3 chance you chose a goat.
- The host, knowing what’s behind the doors, always reveals a goat after your first pick.
- So if you initially picked a goat (2 out of 3 times), switching means you’ll win the car.
- Only if you initially picked the car (1 out of 3 times) will switching cause you to lose.
Bottom line: Switching gives you a 2/3 chance of winning. Staying gives you just 1/3.
It’s counterintuitive, it feels wrong, and that’s why it’s famous.
At Qwasar, we don’t stop at explaining the answer, we simulate it.
Prove It With Code: Simulation as Discovery
In this collaborative session, learners work together to build a program that simulates this scenario thousands of times. They run two models: one where the player always sticks with their first pick, and one where the player always switches.
The result? Evidence that switching wins about two-thirds of the time.
But the value isn’t just in the answer. It’s in the process:
- Modeling randomness
- Structuring logical branches
- Communicating assumptions and results
- Refining code collaboratively
It’s not just a probability puzzle, it’s a lesson in simulation, system design, debugging, and reasoning under uncertainty.
Why This Session Sticks With Learners
The Three Doors problem teaches more than math or logic, it teaches learners how to:
- Write simulations that reflect the real world
- Understand probability through implementation
- Collaborate and communicate technical decisions
- Defend and validate a strategy with data
It’s deceptively simple, surprisingly deep, and a perfect example of Qwasar’s approach: learning by building and by thinking.
Live Coding at Qwasar: A Different Kind of Challenge
While the Three Doors session is collaborative and asynchronous, live coding sessions at Qwasar are something else entirely. These are real-time, high-engagement events where learners join a Zoom room, share screens, and build together on the spot.
One example? A session where learners write a bitwise-based map parser in C.
Welcome to the Maze: A Live Coding Session in Action
In this challenge, learners receive a .map file containing a grid of walls, open spaces, and designated entry/exit points. Their task? Write a C program that:
- Loads the map from a file
- Stores the grid using bitmaps (1 bit per cell)
- Visualizes the result in the terminal
The twist? No 2D arrays allowed.
Instead, learners manipulate memory directly using set_bit and get_bit functions. Each cell is encoded using bitwise operations, requiring learners to reason at the binary level, together, live, in real time, and they do it all under time pressure, often in under 90 minutes.
Along the way, they’ll:
- Parse metadata like map dimensions and symbols
- Use a Map struct to encapsulate data and functions
- Debug memory allocation issues or visual glitches
- Divide tasks, ask questions, and collaborate on design
It’s intense, fast-paced, and incredibly rewarding. Because by the end, learners don’t just have a working maze visualizer, they’ve practiced real software collaboration, systems-level design, and low-level reasoning.
Why Both Experiences Matter
These two sessions couldn’t be more different on the surface:
- One’s a logic puzzle about goats.
- The other’s a deep dive into memory representation and parsing.
But they both reflect core elements of Qwasar’s pedagogy:
- Open-ended challenges instead of step-by-step instructions
- Real-world thinking instead of rote coding
- Communication, reasoning, and iteration, not just execution
Whether you’re collaborating asynchronously to simulate probabilities or building live under pressure to map bit-level data, you’re practicing what engineers actually do: solve problems, work together, and defend your approach.
Learning by Building and by Thinking
At Qwasar, we don’t separate technical skill from critical thinking. We teach both, side by side.
Some days that means simulating game shows. Other days, it means parsing mazes with bits. Either way, our learners are doing more than writing code, they’re learning to think like engineers and sometimes, that’s all it takes to turn learners into engineers.
