"What do they actually ask you to build in a company hackathon?"
Since I wrote about my HCLTech GIFT City hackathon experience, this is the question people have asked me the most. Developers preparing for their first hackathon, candidates interviewing at fintech companies, and engineers who simply want a realistic weekend project.
So here it is. The complete sanitized problem statement from the Java Full Stack track, explained flow by flow. You can also download it as a PDF and keep it for your own preparation.
A note on "sanitized": this is a public-safe rewrite of the hackathon use case. Event-internal formatting and names have been removed, and it is not the official source document. The substance is intact though. The flows, the rules, and the engineering expectations are all here.
The challenge in one sentence
Build a credit card application system for a sample bank. It starts at the application form, goes through credit scoring and card issuance, and ends with first-time PIN setup. All of it in one day, as a working Java full stack solution.
Easy to describe. Not so easy to build well. Let me show you why.
The expected architecture
Before any feature, the problem statement sets architectural expectations:
- Java backend services for the main business flows
- React frontend for an interactive user journey
- API gateway or an equivalent routing layer for service access
- Service boundaries suitable for application, credit rating, card activation, and PIN setup flows
- Database persistence for customer, application, card, score, and audit data
- Event-driven communication where useful, for example Kafka for service-to-service events
Read that list again. The jury is not looking for one big Spring Boot monolith with four controllers. They want to see whether you can draw service boundaries. It is a system design question hiding inside a coding task.
Flow 1: Apply for a new credit card
A new customer submits a credit card application with minimal required information:
- Basic user information
- Employment information
- Identity document type and document number
On valid submission, the system triggers a credit rating check for the customer. That trigger is your first service-to-service interaction, and your first chance to show whether you think in synchronous calls or in events.
Flow 2: Customer credit rating
The credit rating service returns an existing numeric score if one is available. If not, it calculates one from the customer's salary and existing credit card count:
| Condition | Score |
|---|---|
| Already holds 2 or more credit cards | 300 |
| Annual salary greater than 200,000 USD | 500 |
| Annual salary between 50,000 and 200,000 USD | 150 |
| Annual salary below 50,000 USD | 50 |
The acceptance expectation: update the customer's credit score after validating customer information.
Look at that table again. The conditions overlap. A customer can hold two cards and also earn above 200,000 USD. Which rule wins? The statement does not say. I believe that ambiguity is intentional. Writing down your assumption and coding it consistently is worth more than silently picking one.
Flow 3: Approve or activate the credit card
Based on the calculated score, the system approves a card or asks for more documents:
| Score | Decision / Card Type | Limit |
|---|---|---|
| 500 | Platinum card | 40,000 USD |
| 300 | Gold card | 20,000 USD |
| 150 | Visa card | 10,000 USD |
| 50 | Request additional documents | N/A |
Acceptance expectation: generate a card number and a first-time PIN for approved customers.
Out of scope: physical card delivery and the workflow after additional documents are requested. That saved us a lot of time on the day.
Flow 4: First-time login and PIN change
The final flow closes the loop. A new cardholder changes their default PIN after validating:
- Credit card number
- First-time PIN
- The identity document ID used during the application
- New PIN and confirmation PIN
On valid submission, the system updates the PIN and creates an audit entry. That audit entry is easy to skip under time pressure, and it is exactly the kind of detail a fintech jury checks.
The review expectations (where rankings are decided)
The statement ends with what the jury actually evaluates:
- Mandatory-field and format validations
- Business validations for all flows
- Functional programming style where appropriate, using JDK 8+ features
- Unit test cases where applicable
- Consistent error handling across APIs and UI flows
On the hackathon floor, this section is what separated the teams. Everyone had a form that submitted. Very few had validations on every flow, unit tests, and errors that behaved the same way in the API and the UI.
How to use this for your preparation
If you are preparing for a hackathon or a fintech interview, do not just read the PDF. Run the drill:
- Timebox it. Give yourself one day, like the real event. The constraint is the lesson.
- Design before you code. Spend the first 30 minutes on service boundaries and the data model. It pays back three times over.
- Build vertical, not horizontal. One complete flow from apply to score to approve beats four half-finished ones.
- Write down your assumptions. The score rules overlap and some edge cases are missing. Note your decisions in the README the way you would explain them to a jury.
- Leave an hour for polish. Validations, error messages, and a clean demo path are what people remember.
Download the problem statement
The full sanitized brief is one page of flows, tables, and expectations. Download it below and keep it handy for your next practice run:
FREE PDF DOWNLOADIf you want the story of how the day actually went, with the floor, the pressure, and the jury questions, and how this hackathon eventually led to my role at HCLTech, read the companion post: From Hackathon to Senior Technical Lead: My HCLTech GIFT City Experience.
And if you build your own version of this system, I would love to see it. My inbox is open.