JPMorgan Code for Good: How to Scope, Build, and Demo a Team Project

Preparing for JPMorgan Code for Good means preparing to build something useful with a team. Start with one nonprofit user journey, agree on the data and interfaces it needs, integrate a working version early, and demonstrate both the outcome and its limitations. A long feature list is less useful than a small workflow your teammates can explain and verify.

Official: JPMorganChase describes Code for Good as students working in teams, guided by its technologists, to solve problems for social good organizations. Its public overview does not establish a single event duration, team size, judging formula, or hiring outcome for every location. Your event instructions govern those details. Official program overview

This article is an original preparation exercise for invited participants, not a report of a particular event. Use J.P. Morgan Software Engineer questions to rehearse implementation and teamwork explanations alongside the project work.

Confirm the rules before preparing reusable material

Read the invitation for your country, program, and event. Identify the schedule, required submission, presentation format, permitted preparation, and available support. Check rules for existing code, external services, open-source packages, and AI assistance directly; the firm's use of a tool elsewhere does not establish permission at your event.

Keep pre-event practice separate from event deliverables. Learning your editor, Git workflow, and familiar framework is useful preparation. Whether you may bring starter code or reuse an earlier project depends on the stated rules. Do not build against an imagined nonprofit brief and then force the actual problem into it.

The existing JPMorgan Software Engineer Program OA guide covers recruiting-stage questions. Here, the decision is what your team can deliver once it has a problem, not what an assessment score predicts.

No candidate anecdote is used below to infer current judging or recruitment rules. The suggested checkpoints and demo are preparation advice, adjustable to the time and constraints you actually receive.

Turn a nonprofit need into one observable outcome

Original practice brief: A small food-aid organization coordinates scheduled grocery pickups. Volunteers currently compare messages and a spreadsheet to determine whether a pickup slot still has space. Build a prototype that lets a coordinator reserve one place and immediately see the remaining capacity.

The first user is the coordinator. The beneficiary outcome is a dependable pickup reservation, but this first version does not require a beneficiary account, a recommendation model, delivery routing, or automated eligibility decisions. Use synthetic records during rehearsal.

Ask the nonprofit representative what makes the current process fail. Is the main problem overbooking, inability to cancel, language accessibility, or volunteers working from different lists? These answers can change the project. If capacity is rarely a problem but cancellations dominate, this sample scope is the wrong starting point.

For our exercise, assume overbooking and repeated submissions are the important failures. The smallest demonstration is: open a slot with two places, make a reservation, and show that one place remains. Retrying the same operation must not consume the second place.

Write that acceptance condition before choosing a technology. It gives the team a shared definition of done and keeps a visually polished page from being mistaken for a working service.

Prioritize the workflow instead of dividing up features

Use a short scope table to decide what must work and what can wait. The priorities below belong to this fictional brief; they are not a Code for Good rubric.

A feature belongs in the first version when the main journey cannot be demonstrated honestly without it. SMS confirmation is helpful, but an on-screen reservation reference can prove this exercise's core outcome. A route optimizer solves another problem and introduces another set of dependencies.

When teammates disagree, compare the proposals against the same user journey. “Which failure does this prevent?” is more productive than “Which technology is more impressive?” Record the decision and the condition that would cause you to revisit it.

Choose a familiar stack that the team can run together. A new framework is not automatically wrong, but its setup cost should be justified by a requirement. Keep deployment and environment assumptions visible before separate branches start depending on them.

Agree on the interface before building separate pieces

An interface contract is the shared agreement about inputs, outputs, error cases, and state changes between components. For this prototype, the frontend and backend must agree on identifiers, capacity, version, and what a successful reservation means.

Use a response such as this for a slot:

{
  "slot_id": "slot-a",
  "remaining": 2,
  "version": 0
}

The proposed reservation request includes a stable identifier for the operation and the slot version the coordinator saw:

{
  "request_id": "r1",
  "slot_id": "slot-a",
  "expected_version": 0
}

In this original contract, success returns reservation identifier res1, remaining capacity 1, and version 1. A retry with the same request and payload returns that existing reservation without another decrement. Reusing the identifier for a different payload must be rejected rather than treated as the same operation.

A version is a number that changes when the slot changes. If another reservation has updated it, a request based on the older version receives a conflict response and the UI refreshes availability. The backend must enforce the capacity check and update together; disabling a button is only a user-interface convenience.

Do not confuse a documented response with an implemented guarantee. A real concurrent backend needs suitable transactional or conditional-write behavior, plus durable handling of request identifiers. The small model used for this article verifies sequential state transitions, not production concurrency or a deployed service.

Assign ownership around integration boundaries

Give each workstream a clear owner and reviewer. These are responsibilities, not a required four-person team: combine or split them according to your actual group.

The interface owner implements the list, reservation form, and user-visible outcomes. The service owner handles state transitions and request validation. The verification owner maintains the seed data and failure cases. The integration owner keeps the shared version runnable and coordinates the demo path.

Everyone should understand the main journey. A frontend developer should know what “conflict” means, while the service developer should see how the screen recovers. Otherwise each component can look correct in isolation while the combined experience fails.

Begin with one working connection: the page reads a real seeded slot from the service. Next, make one reservation through that same path. Add the conflict and retry behavior before expanding the interface.

Keep branches small enough to review and merge while the author is available. When the contract changes, update the example payload, caller, service, and tests together. A message saying “backend done” is not evidence that the consuming screen can use it.

Rehearse the failure that crosses components

Suppose the server saves r1 as res1 and reduces capacity to one, but the response never reaches the browser. The coordinator still sees a loading indicator and tries again. If the frontend generates a new request identifier on every click, the service may interpret the retry as a second booking.

The repair is a shared behavior: retain the request identifier while the outcome is unresolved, and have the service recognize the original request. Once the operation is confirmed, a genuinely new booking uses a new identifier. Explain this distinction in the interface contract rather than relying on two developers making matching assumptions.

We ran a local rehearsal model and checked the following sequence. These are local state-model checks, not observations from a Code for Good event or proof of a live application's behavior.

For your actual project, exercise this path through the browser and service, not only a model. Inspect persisted records as well as the screen. Two success notifications can hide a duplicate reservation; a reassuring error message can hide a successful write whose response was lost.

If integration fails, identify the smallest broken boundary: wrong field name, stale version, missing response handling, or inconsistent seed data. Fix that boundary and rerun the journey before adding another feature.

Use mentors to test assumptions and unblock decisions

Bring a specific question to a technologist or nonprofit representative. “We can implement cancellation or SMS next; which prevents more coordinator work?” exposes a real scope decision. “Is our project good?” gives them less to evaluate.

Show what already works, what is uncertain, and the decision you need. If a mentor suggests an alternative, repeat your understanding and explain the trade-off to the team. Avoid treating advice as an unexplained instruction that one teammate uses to overrule everyone else.

Official example: JPMorganChase's CanCare story describes a relationship that began at a 2023 Dallas Code for Good event, where teams explored ways to support connections between patients and survivors. That is evidence of a concrete nonprofit problem context, not a template for this pantry exercise or your event's requirements. CanCare partnership story

Listen for operational constraints beyond the screen: who maintains records, what happens without connectivity, and how volunteers correct mistakes. The prototype can leave some issues unresolved, but the team should be able to name them and explain their importance.

Demo the outcome, the failure path, and the boundary

Prepare a short script that fits the allotted presentation time. The sequence below is an original rehearsal, not a prescribed duration or a transcript of a judged event.

Open with the user: “Our coordinator needs to reserve pickup places without comparing several message threads.” Show the seeded slot with two available places. Make one reservation and point to both the confirmation reference and the updated remaining capacity.

Then demonstrate the retry case. “This request already succeeded, but the caller did not receive the response. Repeating it returns the same reservation.” Show that the stored reservation count remains one. This explains a technical decision through a user consequence.

Close with the boundary: “This prototype demonstrates the reservation flow using synthetic data. Before real use, we would need to validate access controls, persistence under failures, operational ownership, and the organization's cancellation process.” State which of those checks your team actually completed.

If the live environment fails, explain the failure and use a clearly labeled recording or local demonstration only if the event allows it. Never present mocked responses, prerecorded actions, or a design diagram as a successful live transaction. A fallback should preserve understanding, not conceal what stopped working.

Separate prototype evidence from long-term impact

A demo can establish that a tested path worked under stated conditions. It cannot establish hours saved, fewer missed pickups, or improved access without corresponding evidence from users and operations.

Official example: JPMorganChase's Global Nomads story describes later Force for Good work to turn hackathon ideas into a sustainable application. The distinction matters: prototype development and long-term delivery are different stages. Global Nomads story

For this practice project, report reservation state, retry behavior, and known limitations. Propose a later evaluation with coordinators: can they complete the workflow, recover from mistakes, and keep records consistent? Do not invent a percentage improvement to make the closing slide sound stronger.

Prepare a concise handoff with setup steps, seeded data, known issues, and the verified demo path. The next person should be able to reproduce the result without relying on the teammate who configured the laptop.

Practice the decisions behind the project

These PracHub records are transferable exercises from multiple companies, not reported Code for Good tasks. Focus on the relevant part rather than importing an entire system-design problem into a small prototype.

Use the J.P. Morgan Software Engineer question hub for additional preparation. With a partner, rehearse one complete workflow, inject one failure, and explain both the repair and what remains unverified.

Sources and Further Reading

• JPMorganChase: Tech for Social Good Hackathons
• JPMorganChase: CanCare partnership story
• JPMorganChase: Global Nomads community project

Sources checked September 8, 2026. Official program examples are attributed; the pantry brief, interface, test sequence, and demo script are original preparation material.