A rant before the experience: It’s frustrating to see people search LeetCode, Reddit, and other sites for interview questions, ask others for detailed experiences, and then respond with “I’m under NDA” when someone asks about their round.
Most of us encounter confidentiality obligations during interviews. I’m not asking anyone to ignore theirs, but the one-way exchange gets tiring: use the community to prepare, then offer nothing back—not even the format, stack, or unexpected difficulties.
Sometimes it feels less like confidentiality and more like people worrying that sharing will give the next candidate an easier round or a better outcome. That feeling is understandable. But if that’s the concern, I’d appreciate the honesty rather than the moral superiority around sharing interview experiences. We also can’t know everyone’s reasons or exactly what they agreed to.
If nobody contributed anything, this community wouldn’t have the preparation value we all benefit from. Knowing the general task doesn’t make an unfamiliar repository familiar, make a slow AI respond faster, or explain Spring Boot and JPA for you.
With that said, here’s the round I encountered.
Round and environment
- Company: Atlassian
- Role: Backend, P40
- Round: AI-enabled coding
- Duration: Approximately one hour
- Platform: HackerRank
- Stack: Java, Spring Boot, H2, and JPA
- An existing repository and an AI assistant were provided.
- The AI was noticeably slow during my session.
Problem: validate a card PIN
The repository contained a card model with multiple fields, a controller, and a repository backed by H2 through JPA.
There was an existing PATCH endpoint to update a card’s PIN. The requirement was to add validation:
- The PIN must be exactly four digits long.
- It must contain only numeric digits, with no letters or symbols.
- It must not contain any repeating digits.
- It must be a positive value.
“Non-repeating” meant no duplicate digit anywhere, not merely no consecutive repeats. For example, 1213 was invalid even though the repeated digits weren’t adjacent. The wording initially left room for interpretation, so this was worth clarifying.
The main catch: the existing data model
The PIN wasn’t a new field we were adding. The card model already stored a PIN as an int, and existing records already contained numeric PIN values. The controller also accepted the PIN directly as an int parameter, without a separate update-request DTO.
Leading zeros therefore required more than adding validation to the endpoint. An integer cannot preserve a PIN such as "0123"—its numeric value becomes 123.
We needed to change the PIN representation in the card model itself to String, and follow that change through the controller, service, and persistence mapping. Changing only the controller parameter would leave the underlying representation problem unresolved.
What was expected
Understand the existing request flow and implement the change across the relevant layers:
PATCH request → controller → service/validation → card model → JPA/H2 persistence
Valid input should update the intended card’s PIN while preserving leading zeros. Invalid input should be rejected without modifying the stored card or its other fields.
The change also needed verification through tests covering the validation rules, leading-zero handling, and unchanged state after rejected updates.
This was an existing Spring Boot application with JPA persistence—not a standalone validation function or a repository implemented using a Java Map.
If you’re comfortable with Java but haven’t worked much with Spring Boot, brush up on Spring Boot and JPA fundamentals. Request binding, controller/service flow, entity mappings, repository methods, transactions, and dirty checking are worth understanding before this round.
