Forem: Ishika-jain

How to ask awesome questions as a dev (Without Dying of Imposter Syndrome)

Ishika-jain — Mon, 12 Jan 2026 14:47:29 +0000

I have been there. Trust me, I have. In concrete jungles. With beasts in suits. (Okay fine, hoodies. Always hoodies.)

I hated asking questions - admitting there were things I didn’t know was my worst nightmare when I first joined.

So I know how hard it is. Especially when everyone around you looks like they popped out of the womb knowing Docker, Git, and the difference between == and ===.

So here’s a guide on how to ask awesome questions.

Whether you’re just starting out or you’ve been in the game for a while, one thing is inevitable: you will not understand certain things. You will get stuck. And the longer you keep those questions trapped in your head, the bigger your imposter-syndrome monster grows.

It starts whispering things like:

“Everyone else gets this.”
“You’re just dumb and don’t deserve to be here”
“If you ask, they’ll know you’re a fraud.”
“Just stare at the bug harder. It’ll fix itself.”

(It won’t.)

“So how do you get your questions answered?” you ask.
“You just ask them,” I say.
DUH.
But how you ask matters.

What Is a Good Question?

Before we talk about how to ask good questions, let’s define what a good question actually is.

A good question is… a question.

Yup. That’s it. Any question you genuinely have is a good question—as long as it’s asked out of curiosity and effort, not laziness.

Good questions:

Help you get better answers, faster
Show that you care about understanding, not just un-blocking yourself
Build credibility over time
Strengthen your problem-solving muscles

Bad questions aren’t the ones that sound “basic.” Bad questions are the ones where zero effort happened before asking.

Do Your Homework (Yes, This Is Mandatory)

Before asking a question, do a quick reality check:

Have you:

Googled it?
Checked Stack Overflow?
Read the documentation (at least skimmed it)?
Tried debugging on your own?
Searched if this exact question has already been asked?

In other words: ask the question to yourself first and see how much information you can gather.

You don’t need to solve it completely. You just need to try. Effort is obvious. And effort is respected.

How to Structure Your Question (So People Actually Want to Help)

1. Provide Context

Start with what you’re trying to do, not just what’s broken. People can’t help if they don’t understand the bigger picture.

Instead of saying “This just doesn’t work” try “I’m trying to fetch user data after login and render it in a table.”

2. Show What You’ve Tried

Nothing earns goodwill faster than saying “Here’s what I’ve already tried.”

List your attempts and what happened. Even if they were wrong. Especially if they were wrong.

3. Include Relevant Details (Not Your Life Story)

Include:

Your environment (OS, language version, framework version)
Exact error messages (copy-paste them)
Minimal code that reproduces the issue
What you expected to happen vs. what actually happened

Exclude:

Your entire codebase
400-line files
Unwillingness to learn

4. Be Specific

Instead of “My code doesn’t work., try something like “My React component throws Cannot read property 'map' of undefined when I try to render API data before the request completes.”

Specific questions get specific answers.

5. Make It Easy to Help You

You are not just asking for help—you are collaborating.

So:

Format your code properly
Keep examples minimal
Remove distractions

If helping you feels like homework, people will quietly back away.

Question Templates (Steal These)

Debugging Help

I’m trying to [goal], but [what’s happening instead].
Here’s my code: [minimal example]
Error message: [exact error]
I’ve tried: [list attempts]
Environment: [relevant versions]

Conceptual Questions

I’m learning about [topic] and trying to understand [specific concept].
From what I understand so far: [your current understanding].
What I’m confused about: [specific gap].
Context: [why this matters to you].

Best Practices / Design Decisions

I need to [accomplish task].
I’m considering [approach A] vs [approach B].
My constraints are: [limitations].
What are the tradeoffs here?

What NOT to Do (Please)

“Can I ask a question?” — just ask it
“This is probably a dumb question” — don’t undermine yourself
Expecting others to debug your entire codebase
Asking five unrelated questions in one message
Vanishing after you get help

After You Get an Answer

Do these things. They matter more than you think:

Say thank you
Share what worked
If you solved it later, post the solution
Pay it forward when you can

Today’s confused developer is tomorrow’s senior engineer answering questions on Teams at 11 PM.

Remember

Everyone was a beginner once.
Asking questions doesn’t make you less capable—it makes you a (better) learner.
The best developers don’t magically know everything.
They just got really, really good at asking great questions.

And now, so can you.

A Beginner's Guide to Winning Smart India Hackathon

Ishika-jain — Thu, 01 Feb 2024 05:59:40 +0000

This article, do not be misguided, is not about my journey in SIH. Instead, it is about how to win SIH, which I believe is a topic far more interesting for far more people.

Before you question my credibility, allow me to introduce myself. Hi, I am Ishika Jain. My team won SIH for the second time in 2023 and for the first time in 2022. I have also secured victories in other hackathons, including the "Most Inspirational Hack" in NASA Space Apps and Sahaj Nan(0). With participation in over 10 hackathons, I've garnered some insights worth sharing.

Is there a foolproof way to win SIH (or any hackathon )? Well, I'd argue there is, given that it has worked twice. But as wonderful as it would be to have a secret sauce for success, it must always be taken with a grain of salt. And while I would not hand over the baggage of our success to luck alone, I would also not discredit its occasional helping hand—like the time when our entire website crashed but Conveniently, we were the last ones to be judged, giving us enough time to bandage the product.

Each hackathon has its quirks. Some let you assemble teams moments before kick-off. SIH? Not so much. It's a marathon, not a sprint. To play it right, you have to be prepared.

Armour up, soldiers, because here we start.

Step 1: Form your dream team

Find good hackers: Hackers in this context are different from programmers. Hackers are solution finders, not just solution builders. Get yourself a team that is involved and innovative. If your friends don't fit into that criteria—well, then they don't. In addition to tech, look for a designer (the difference between a tacky website and an aesthetic one could be a winning one), an ideator (the fresher the idea, the more the impact), and a charismatic speaker (they will keep you entertained and the judges impressed)

Pro Tip: Get someone with an inclination towards business and marketing while still being technically proficient. They will be your mastermind, your strategist, or, as we call ours, the professor.

Embrace diversity: Ensure your team has as wide a variety of skill sets as you can find. Don't compromise compatibility for diversity, however. Vibes matter.
Know your team: Your team should be well-knit. A cohesive team trumps a discordant one. You're hacking solutions, not each other.

In an ideal world, you'd have your dream team in place from the start. In the real world, you will need to cultivate and shape individuals to fit these roles—while still encouraging them to think outside the box.

Step 2: Sacrifice a rubber duck to the coding gods. This step is crucial

Look up rubber duck debugging.

Step 3: Get a muddy idea and refine it till its clear

Read the problem statement: Read it 20 times in 20 different places at 20 different times - or maybe not, but ensure that you understand the problem statement clearly. Have each member read it and explain their understanding. Leverage everyone's unique perspective. (In SIH 2022, a competitor team was asked to redo everything they had done because they had not “understood the problem statement completely”)
Talk Talk Talk: Talk to different stakeholders to identify the problem. Problems are easier to solve when it is clear what the problem is. Conversations fuel clarity. (In Sih 2022 we emailed ~100 retired judges and were in close contact with around 10 stakeholders: from judges, lawyers, advocates, and law students to families involved in court cases)

Problems are easier to solve when it is clear what the problem is. Conversations fuel clarity.

Market Research: Does a similar product exist? What does it lack? How is your product better? Is it unique? Scout competition, identify gaps, and flaunt your uniqueness. I would say at least 30% uniqueness in the idea alone, apart from the tech. (In Sih 2022, our market research made such a significant impact on the judges that they acknowledged us after dinner. They went so far as to introduce us to their colleagues and even captured a memorable selfie with us. While the selfie moment wasn't directly tied to our research, it underscored just how much the judges valued our presentation and efforts and no - we did not get the selfie from their phone.)
Know Your Idea: Inside Out. Upside down. Sideways. Address potential flaws before the judges do. A flaw can be disguised as a feature if found in time. (Only speak about them if asked, do not dig your own grave). Anticipate judge queries and be prepared for them. (In Sih 2022 we were asked why we were using mongoDB when SQL would have been a better fit. we did not have an answer. In SIH 2023, we knew it was because collaborating on a cloud platform like Atlas made the process from a hackathon point of view faster )
Jugaad: This one is controversial but I believe one should know when to use this weapon. Your entire product should not be a jugaad but if you need a screw to hold up the door to your castle, use a damn screw.

After all, it is a hackathon - a few hacks are allowed.

Step 4: Build to perfection.

This is your magnum opus. Plan meticulously and code diligently. While I won't delve extensively into this step since it can get super specific, it remains pivotal. Ultimately, it's a hackathon, and your product and its technology are under scrutiny. Preparation is crucial, and each problem statement requires a distinct approach. In general - plan before your build, know your tech stack, use git and push constantly.

Step 5: Pitch and Pray

Tell them everything you have: Judges rely on the information you provide, so be candid about every detail. If there were plans you couldn't execute, communicate them. If you initially pursued an idea but later deemed it impractical, share that insight.

Be transparent about your journey, hurdles, and pivots. Keep the clock in mind though.

Back it up like your life depends on it: Every small thing on your project should be backed by reason. Whether it's a question on why a button is blue or why you chose a certain tech - for every question have an answer. Stand your ground, be confident but not cocky. (In SIH 2022, the judges critiqued our product for its lack of practicality. Our response? We highlighted that the stakeholders found it remarkable. This pivotal moment underscored our success: convincing them that our product isn't just good—it's essential.)
Glitter: There is nothing more eye-catching than glitter. Make sure your product and pitch have their glitter. Remember, glitter lingers. Incorporate impactful elements that resonate, embedding themselves firmly in the judges' minds. (In sih 2023 - our product, a real-time infrastructure monitoring system- went one step ahead and included a project management software - it was not the only thing we had but having it made the project look complete and ready to use as opposed to a WIP )
Know your judges: This might not always work but it did for us (In our experience, when faced with panels that included business analysts, our strategic advantage became evident. Incorporating a Business Model Canvas (BMC) and competitor analysis into our pitch set us apart from the competition and earned us brownie points)
Pray to the heavenly lords: Mistakes are inevitable. Our entire app crashed minutes before finals leaving us with nothing to show. But when life throws lemons, we make a lemon tart. And When nothing else works - we revert the changes. (In SIH 2023, I faced a significant hiccup during our final presentation, struggling with stammering and eventually falling silent. Yet, my team's expertise and readiness shone through. Without hesitation, they seamlessly assumed control and finished the pitch. An important lesson: every team member should be prepared with the pitch for such scenarios. Our collective effort not only salvaged the situation but also resonated with the judges. Their feedback highlighted our team's synchronized knowledge and collaborative spirit, garnering us unexpected recognition.)

Bonus tips: Flattery is good as long as you can be discreet (in Sih 2023, we used the judge's name as our sample user).

Bonus tip 2: Do not send your judges a LinkedIn request before or during the hackathon.

Step 6: Use the opportunity

Learn a lot. Network a lot. Have fun. Make memories. Record as much as you can. and Celebrate your victory. Remember, it's not about fame or fortune. It's about the experience and, of course, the bragging rights. And finally, turn that hackathon project into the next unicorn startup or, at the very least, a hilarious story to tell at parties.

And there you have it, folks! While some may say it's all about the code, the caffeine, or the endless nights of debugging, the real secret sauce? Well, it's a mix of strategy, teamwork, a touch of luck, and maybe sacrificing a rubber duck or two to the coding gods. Remember, in the world of hackathons, it's not always about who codes the fastest but who tells the most compelling story with their code. So, assemble your dream team, polish that pitch, and who knows? Your next hackathon might just be the start of something legendary—or at the very least, a tale sprinkled with glitter, rubber ducks, and a few unexpected selfies. Happy hacking!

SIH - My stepping stone into the world of hackathons

Ishika-jain — Mon, 29 Aug 2022 15:16:00 +0000

My team and I won “Smart India Hackathon Software edition 2022”, and we honestly haven't left a single chance to rub it in everyone's face. The reason is simple to say the least. We are excited. Sih was our first hackathon and not only did we go into the world's biggest hackathon with no prior experience, we bagged the first prize.

“It's not the destination, it's the journey”

Our journey began way back in January. One fine day, Janvi casually approached me to tell me she had given my name for a hackathon team. I felt a flurry of emotions. I was excited, scared and nervous. I met my team leader Dinesh and other team members Vinit and Prince shortly after. Thus, the team was formed even before we knew the problem statements. However, we were still short of one team member. After a lot of searching, we found a 3rd year student(Unnamed) to be a part of our team. We worked relentlessly, upskilling ourselves, discussing strategies, and working on various aspects of a hackathon. Our schedules included G-meets till 3 am after a full day at college. And not once did fatigue overpower our passion.

When the problem statements began to roll out, we started out with a problem statement by the ministry of Rajasthan, working on a queue management system. A few days after working on this statement, we had our research, our solution and a prototype of our app. And then things slowly took a turn. We began hitting dead ends with our project. It was infuriating, exhausting even.
Then our college released the officially selected problem statements for us. We were back to square one. Among the 20 or so problem statements provided to us we were all drawn to one. Problem id: “NR1174”. Our problem statement required us to build smart legal aid, to reduce the pendency of cases, increase the efficiency of courts and educate the masses about the working of the legal sector.

Our first step was to research: We read research papers, news articles, e-court manuals, all in a frantic attempt to understand the underlying problem. Our second step in research was to talk to people. We set out in and out of college, on streets, buses and every nook and corner of our neighbourhood, interviewing people about their experience with courts, problems they faced and solutions they would suggest. It was in one of these interviews that we met a young man, who told us, “Doosre deshon mein courts ache hai, par ye India hai na” (other countries have a better court system, but this is India). The validity of that statement is of rather little importance here, because that statement sparked something in us. It was at that point that this problem statement stopped being just a “hackathon thing” and began to mean so much more to us. That day, my teammate, Vinit said “Doosre deshon ke paas hai toh kya, hum bhi bana lenge!”. (so, what if other countries have it, we will also make it.)

With that began the real journey of team hum bhi bana lenge. We immersed ourselves in our work. Contacting judges, advocates, law students to reach to the root cause of our problem (this will be important later on.) There was a point where we had emailed over 100 judges and contacted over 15 advocates. [I’d like to take this space to thank Saumitra Singh Bhataudia (probation judge at the Ahmedabad high court), Mohammed Ali (criminal lawyer in high court of Karnataka), Mehul Thakkar (registrar at Baroda district court), Vaibhavi Venugopal and Rahul Ranjan (2nd year law students)]. Without the help of these law-versed selfless individuals and their insights in the litigation system, it would have been impossible for us to garner the information that we did and thus build our project.

Slowly we inched towards march, our research was done. We knew the product as well as the back of our hand. We cleared the internal hackathon organised by our seniors at point blank, submitted the ppt to SIH portal, and with that, we were done. We decided to take a break from SIH while awaiting results and work for our upcoming college exams.

Results began rolling in around the first week of July. We were all on the edges of our seats. The first set of results rolled in, and our problem statement was nowhere to be seen. The second week rolled by, our nails were chewed with anxiety but yet again, the results for our problem statements had not been announced. We were scared, perhaps none of the solutions had been selected for our problem statement? It wasn’t long before the third set of results rolled in, and this time we were jumping in our rooms. We had made it, we had gotten selected. Our excitement was through the roof. Out of the 20 teams that had applied for our problem statement, we had emerged as the top 3.

Soon after the results were declared we got the tentative dates for the hackathon and learnt that one of our team members would not be able to make it there. We felt dejected. Did this mean we wouldn’t be able to go? It was no use whining so we set to action. A new hunt for a new member. On hopped Dheeraj, our final member, our ML expert.

This would be a good point to begin explaining our initial approach to the problem. We were sure that we didn't want a predictive algorithm for three main reasons, 1. Any predictive algorithm would learn from previous data, making it biassed owing to prejudices from the past. 2. We wanted our product to help judges make faster decisions, but not at the risk of compromising on justice. FAIR AND FAST, was our motto. 3. Outright having AI give judgements was a step that would take a lot of time for both the common man and jury to trust and appreciate, and we did not want our product to give unsatisfactory results like the digitise courts movement from 2013.

The solution we came up with was intricate and promised results. It involved a scheduling system, a mobile app and a web-app.
Our notification system (built with Twilio for the sake of the hackathon) would send notifications a day prior to the hearing date, to all concerned authorities and relevant parties, and use a confirmation system (yes /no reply system). Details of the Parties who confirm their presence will be sent to part 2 of the solution. Parties that deny their presence, will be rescheduled to a different date. Each party gets up to 3 turns to postpone their hearing owing to emergencies, after which they are mandated to attend.
Part 2 of the solution takes in confirmed party details as input and generates an ai score based on a multitude of parameters like case type, case stage, and case age. This score generated is used to schedule the Judges day. This scheduling is reflected in the judges mobile app. The judge can see any case details relating to a particular case, these details include the entire case affidavit, the summary of the case up until that point of jurisdiction and a list of precedents (cases of similar nature that have been resolved by any court higher than the court seeking it) with a similarity score.
A web app questionnaire for the common man, where within a few clicks, users answers questions relating to their cases, a report is generated at the end, providing valuable information like average timeline of case, average cost, laws applicable, documents required, a YouTube link for easy understanding etc.

With the game plan ready, the grind that would lead us to the winning moment began. With our persistent requests we were able to secure a room to work in. Work hours ran from 9 am to 7 pm, at which point department doors were shut and the only way to leave was with us jumping over walls. We faced a multitude of challenges during this entire process, mainly due to the lack of technical knowledge. Our team wasn’t the strongest technically, but we would not that deter our confidence. Vinit and Janvi worked on the mobile application. Dheeraj worked on the ml models, while I worked on deploying them and the product pitch. Dinesh worked on the design and website aspect of our app, while Prince worked on building the dataset, making the product more accessible and occasionally on the front end of the website. We struggled the most with APIs and Deploying the ml models. The model gave multiple errors when deploying on Heroku and when it finally did deploy, it was too large to deploy on the free version. The API from backend, was made with tokens and empty functions, proving to be a very hard task to use in the android app.

With barely any of the product ready, and new challenges popping up every step of the day, it was time for the finals. I mean, final internals exams. Right before SIH. But we managed to waddle through internals, SIH prep and made our way into the humongous campus of ACS college of engineering. Once the hackathon began, everything seemed to pass by in a blink. We were the last problem statement, seated between our competitors. Seeing both teams have a mentor, instilled some fear in us, but not for long. Fear was quickly replaced by Hunger, Drive, Passion. Our first review went extremely well, we were applauded by both members of the jury, and were feeling pretty confident. The second review was the exact opposite. We fumbled, our project had crashed and we couldn't seem to figure out the problem, and we couldn’t answer the questions asked by the jury. It was disheartening. Few of us were already in tears. This is where our team leader stepped in to the rescue, he told us we needed to calm down. We went outside, letting the cool air soothe us. We contacted seniors and friends, seeking help. It was then that one of the jury met us, told us we were on the right track and asked us to keep moving forward (and asked to take a selfie with us). That changed everything. We were back in form. Better actually. We were determined to make this work. In the final evaluation, our project was still not fully functional. We had bits and pieces of code breaking. Errors. Empty Screens. Blank Faces.
(Remember I told you, the research would be important later on)

With what we had, we were able to convince the judges and show them the utility our project had. All the research we had done began to pay off, and despite not having a fully functional model ready, judges saw and appreciated the groundwork we had done. We were not building a product for a hackathon, we were building it to solve a major problem in our country, and that earned us the brownie points that we needed to win.

Within an hour after our final presentation, we had reached the final deciding moment. We waited with bated breath as the results were being announced. “The winner for ps id NR1174, our last problem statement is…”, we were on the edge of our seats. Sweat trickling down our backs, “Team hum bhi bana lenge”. There was an uproar, emerging from us of course. In no time we were sprinting towards the stage, so fast Usain Bolt would’ve been scared and then we were there. On stage receiving our cheque, taking blessings from our jury and other officials. Out of the 36 hours allocated to us, we had been up for 32+ hours. Despite that, as we held our prize, the expected fatigue never set in. We were smiling end to end, dialling phone numbers of parents, friends, jumping with excitement. We had done it. We had won our first ever hackathon!
In the span of six months, I had won a hackathon, made friends for life, and I was only just getting started!