JPMorgan Rejected Me. Two Years Later I Rejected Them
The complete Code for Good playbook, including the part nobody tells you about how the offer is actually decided.
Two years ago, JPMorgan rejected me after the HireVue round for Code for Good.
Last week, I declined their full time offer before joining.
I posted that on LinkedIn along with a screenshot of the email I sent turning the offer down. In 22 hours it crossed 300,000 views. My inbox has not been quiet since, and almost every message asks the same thing:
How do I get into Code for Good?
So this is the full answer. Not a motivational post, not a highlight reel. This is the actual process, stage by stage, including the part nobody tells you about: how the return offer is really decided.
First, what Code for Good actually is
Code for Good is JPMorgan Chase’s hackathon for students in India. On paper it is a social impact hackathon where you build technology for NGOs. In practice it is one of the largest hiring funnels the firm runs in the country. Perform well and you can walk out with a summer internship, and after that a full time offer.
I applied in my second year and got rejected. I applied again in my third year, cleared everything, and won the national round at the Bengaluru edition. That rejection year taught me more than the winning year did, so I am going to talk about both.
The overall structure
There are three stages before you reach the finals:
- Online Assessment on HackerRank
- HireVue recorded interview
- Offline hackathon finals at Mumbai, Hyderabad, or Bengaluru
Each stage filters hard. The composition of who survives changes at every step, and the skill being tested changes completely from one round to the next. That last point is what most people miss.
Registration and eligibility
Applications usually open a few months before the finals, and the form goes live on JPMorgan’s careers portal. Keep an eye on their India careers page and on LinkedIn, because the window is not open for long and there is no second chance in the same cycle.
You fill in the usual details: college, branch, graduation year, resume. The eligibility criteria vary slightly year to year, so read the posting carefully rather than relying on what a senior told you last year. Once you register, everyone who is eligible gets moved to the assessment. There is no resume shortlisting filter that meaningfully cuts people at this point, which is good news if you are from a tier two or tier three college. This is one of the few programs where your college name does not decide whether you get a shot.
Stage 1: The Online Assessment
The OA is conducted on a single day for all participants, on HackerRank.
You get two DSA questions. They usually sit in the easy to medium range. Occasionally a set will include something genuinely hard, but that is the exception, not the pattern.
Here is what actually matters:
You need to pass all test cases on both questions. Partial solutions rarely carry you through. A half solved question is closer to zero than to half.
Speed and accuracy together. The time limit is not generous enough to let you flail. If you are solving in your head first and coding second, you will finish. If you are debugging your way to an answer, you will not.
Consistency beats cramming. If you have been doing basic DSA regularly for a few months, this round is very doable. If you are starting the week before, it is not. There is no clever hack here. Arrays, strings, hashmaps, basic recursion, sorting, two pointers, and prefix sums will cover the vast majority of what shows up.
One thing I want to be blunt about: do not use AI tools in the OA. It is monitored, it is against the rules, and getting flagged ends your candidacy for the entire program. Save the AI for the finals, where it is not just allowed but genuinely an advantage. I will come back to that.
Stage 2: HireVue, where most people die
Everyone who clears the OA moves to HireVue. And this is the round that eliminates the largest number of people.
I know because it eliminated me.
Here is the format. It is a recorded video interview, no human on the other side. You get two behavioral questions. For each one you get one minute to think, and then two attempts to record a two minute answer.
That is it. No coding. No technical depth. Just you, a webcam, and two questions about how you work.
And that is exactly why people fail. Students who can solve graph problems in fifteen minutes freeze when asked to describe a time they disagreed with a teammate. Nobody practices this. Everybody assumes it is the easy round because there is no code in it.
What went wrong for me in year two
I treated it as a formality. I read the question, started talking, and hoped structure would emerge. It did not. I rambled, I ran out of time mid sentence, I gave a vague answer with no specific example in it, and I burned my second attempt trying to fix the first one instead of just delivering a clean answer.
What I changed in year three
I prepared stories, not answers. You cannot predict the exact question, but you can predict the categories. Teamwork. Conflict. Failure. Leadership. Taking initiative. Handling pressure. Learning something quickly. I wrote out six to eight real incidents from my own life and made sure each one could be told in under two minutes.
I used the STAR structure without sounding like a robot. Situation, Task, Action, Result. Thirty seconds of context, sixty seconds on what you specifically did, thirty seconds on the outcome and what you learned. When you have that skeleton in your head, the one minute of thinking time is enough to slot a story into it.
I practiced on camera. This is the single highest leverage thing you can do. Record yourself answering on your phone. Watch it back. It will be painful. You will notice you say “basically” nine times, that you look away from the lens, that your first fifteen seconds are filler. You cannot fix any of that without seeing it.
I used AI for mock interviews. Ask a model to act as a behavioral interviewer, give it the JPMorgan context, have it fire questions at you, and then ask it to critique your answer for structure, specificity, and length. It is not a substitute for practicing out loud, but for feedback loops at 2 AM it is unbeatable.
Small things that matter more than they should. Test your camera and mic beforehand. Sit in decent light with the light in front of you, not behind. Plain background. Look at the camera, not at your own face on the screen. Speak slightly slower than feels natural. Use the full two minutes but do not run over.
The reason this round matters so much is that it is the first real signal JPMorgan gets about whether you are someone people want to work with. Keep that in mind, because it becomes the theme of everything that follows.
Stage 3: The offline finals
Clear HireVue and you get invited to the finals, held in person at Mumbai, Hyderabad, or Bengaluru. You get assigned a location. Travel and stay are handled.
Get Vyom Goyal’s stories in your inbox
Join Medium for free to get updates from this writer.
This is where the format gets interesting.
You do not pick your team
JPMorgan forms the teams. Each team has around six to seven people, and no two members are from the same college. That constraint is deliberate. They want to see you work with strangers, and they want to remove the advantage of showing up with your usual project group.
You will meet your team for the first time on the day. You have no shared history, no established roles, no idea who is good at what. Figuring that out fast is part of the test.
Every team gets two mentors
Each team is assigned two mentors from JPMorgan. These are senior engineers currently working at the firm. Their stated job is to help you with technical blockers, unstick you when you are stuck, and answer questions.
Remember this. I am coming back to it, and it is the most important paragraph in this article.
The problem statements
Four to five NGOs present real problem statements. Real organizations with real operational pain, not made up prompts. Teams choose which problem to work on, and multiple teams end up on the same problem, so you are competing directly against other teams solving the same thing.
Listen carefully during these presentations and ask questions. The NGO representatives are available, and the teams that ask good clarifying questions early build things that actually fit the need. The teams that do not ask end up building an impressive thing that solves a problem nobody has.
The build
You get roughly fifteen to seventeen hours. In that window you have to design the solution, build it, and prepare a presentation.
Next day you present to a jury. The top two teams per problem statement present again in front of everyone. Then one winning team is selected per problem statement.
How to actually do well in the hackathon
This is the part where I want to challenge how most students think about hackathons.
Start with the problem, not the tech. The most common failure I saw was teams opening with “let’s use AI for this” or “let’s build a microservices architecture” before anyone had articulated what the NGO actually needs. A clear, practical idea beats an overengineered one every single time in a fifteen hour window.
Build fewer features, properly. A team with two or three solid features, a smooth user flow, a clean interface, and a deployed link will beat a team with eight half working features. Every time. Ruthlessly cut scope in hour three, not hour thirteen.
Deploy it. Deployment alone puts you ahead of a surprising number of teams. A working URL that the jury can open on their own phone is worth more than any slide.
Use AI properly, not just for code. Most students only use AI to generate code. That is the basic level and everyone is doing it, so it is not an edge. The edge is using it for idea validation, feature prioritization, debugging, improving your UI and UX, writing your presentation, and pressure testing your pitch by asking it what a skeptical judge would attack. In a hackathon this is not cheating, it is leverage. Students who do not learn to use these tools well are going to fall behind students who do.
Sleep a little. A team that sleeps four hours and presents coherently beats a team that pulls an all nighter and stumbles through the demo. Smart work over hard work is not a cliche here, it is the actual strategy.
Now the part nobody tells you
Here it is.
The result of the hackathon does not decide your offer.
I have seen winning teams where members got nothing. I have seen teams that lost where multiple people walked away with internship and full time offers.
The two mentors assigned to your team are the ones who decide whether you get the return offer. Not the jury. Not the trophy.
Once you understand that, everything changes about how you should approach those seventeen hours.
Your mentors are sitting with you the entire time. They are watching how you behave when your code breaks at 3 AM. They are watching whether you listen when someone else proposes an idea. They are watching whether you take over the whole project because you do not trust anyone else, or whether you help the weakest member of the team contribute something. They are watching whether you communicate what you are working on, or disappear for four hours and resurface with something nobody asked for.
Anyone can act like a solo builder. What they are evaluating is whether you can function inside a team, because that is what the job actually is.
And please, do not act desperate
This is the mistake I watched sink several genuinely talented people.
The mentors know you want the offer. Everyone in that room wants the offer. You do not need to perform it. When you hover around them, fish for reassurance, or make it obvious that your entire life depends on this outcome, it reads as insecurity, and insecurity is not what anyone wants in a teammate.
Personally, I was straightforward with my mentors. I told them I already had an internship offer from Amazon, and that if the return offer did not come through, I would be fine. Not as a flex, just as a fact. It changed the dynamic completely. We talked like colleagues instead of like an examiner and a candidate.
Meanwhile I watched other people spend the hackathon visibly auditioning. They did not get offers.
Be yourself. Enjoy the hackathon. Work as a team. Work smart rather than hard. That is genuinely the whole formula.
Closing the loop
Two years ago the HireVue round ended my run before it started. I sat with that for a while, figured out exactly what I had done wrong, and came back with a better answer.
The second time I cleared every stage, won the national round at Bengaluru, got the internship, and eventually the full time offer.
And then I said no, because by that point my definition of success had changed.
Funny how quickly that happens.
If you are applying for Code for Good 2026, the process is not a mystery and it is not luck. It is a DSA round you can prepare for, a behavioral round almost nobody prepares for, and a hackathon where the thing being measured is not the thing you think is being measured.
Prepare for all three accordingly. Good luck.
If this was useful, I write about placements, hackathons, and engineering careers in India. Feel free to reach out on LinkedIn if you have questions about any specific round.
