The final exams of my CDAC course were multiple choice: 40 questions per module, eight modules. There was nowhere to practise. Nobody asked us to build anything. We needed it ourselves.
So four of us started writing questions, and I ran a Telegram bot that posted them. We called it QuizzaHut.
What we built
The setup was small on purpose:
- Four of us wrote a set of 40 questions each day.
- The bot posted one question a minute, so a day's set took 40 minutes.
- After every test, we asked for feedback.
There was no app to install, no website, no login. Students were already on Telegram, so that is where the questions went.
3,000 members in 3 days
The Telegram group reached 3,000 members in 3 days. That year, CDAC admitted about 4,000 students in total.
We didn't advertise. Students sent the group to each other because it helped them pass. When something solves a problem people have this week, they become the marketing.
That number is the group's member count, so it counts people who joined, not people who answered every question. Even so, 3,000 joins in three days, from a batch of about 4,000, with no advertising, told us the need was real.
What it taught me about building for a community
Build what you need yourself. We were the users. We knew the exam pattern and the modules because we were sitting the same exams. Paul Graham's test for a good startup idea has three parts: the founders want it, they can build it, and few other people see that it is worth doing. QuizzaHut passed all three, before any of us had read that essay.
Go where people already are. We didn't ask anyone to download anything or create an account. The fastest way to adoption was to remove every step between the student and the first question.
Keep it narrow. One exam, one format, one question a minute. Four students were running it during their own exam prep, so anything bigger would not have survived.
Listen after every round. The questions got better because people told us which ones were wrong. Four people writing 40 questions a day will make mistakes. A few thousand people answering them will find those mistakes fast. The feedback after each test was the most useful part of the whole system, and it cost nothing to collect.
This lesson carried straight into my AI work later. My first AI feature that fell flat, a policy chatbot, only got better once we read what it actually answered, one response at a time, and stopped trusting that it worked. Same lesson: the users find the failures. Your job is to make it easy for them to tell you.
It stopped, and that's fine
QuizzaHut was a student activity. Once our team got placed, we moved on to our jobs, and the bot stopped.
A tool doesn't have to live forever to count. This one did one job, for one season, for a few thousand people, and it worked. That is a complete story.
What it gave me that a course didn't
Looking back, QuizzaHut gave me the three things I now look for in a developer's profile. It had users other than the people who built it. It had a number: 3,000 members in 3 days. And it had things that broke: questions with wrong answers, reported by the people using it and fixed as we went.
None of that came from a syllabus. It came from putting something small in front of real people and listening. If you are trying to prove you can build AI systems, the same shape works, and I wrote about it in what gets a profile a reply. A small tool your batch really uses says more than a large project nobody touched.
Why build again now
Because the problem moved.
Then, the problem was passing an exam. Now, for the developers I talk to, it is getting hired in a field that changes every few months. The job descriptions change, the interview questions change, and the tools people use to keep track are a mix of spreadsheets, documents and chat windows.
The idea is the same as before: build the tool people need, give it away, and put it where they already are. If it helps, people will pass it on, and a community forms around it. The community I'm building now, Qohort, comes from the same instinct.
What I'm building this time, and why it is a command-line tool, is in the QuizzaHut 2 note.
This week
Look at your own batch, team or group of friends. Find one thing everyone does by hand, every week, and complains about. Build the smallest version that helps, and put it where they already are: the group chat, the shared drive, the terminal.
Then ask them what was wrong with it after every use.
You don't need permission to build for your own people. You need a problem you share with them, and the patience to keep listening.