Work on
Train in unfamiliar codebases. Identify your blind spots. Expand your engineering range.
- Real codebases
- Constraint-driven challenges
- Fast validation
System familiarity creates blind spots.
Most engineers grow inside the same codebase for years. You become comfortable within it and since you know where everything lives, it all becomes intuitive
Inside that environment, you feel capable.
But when you face an interview, join a new team or tackle a different stack that familiarity doesn’t help. You slow down because you haven’t trained for unfamiliar systems.
Knowing Isn't the Same as Doing
- ✓ Understand what an N+1 query is
- ✓ Know that transactions prevent partial failure
- ✓ Know caching improves performance
- ✓ Understand race conditions conceptually
- ? Refactor a controller to eliminate N+1 without breaking pagination
- ? Wrap a multi-step purchase flow in a safe transaction
- ? Implement cache invalidation without serving stale data
- ? Fix a race condition inside an existing service layer
1. Interviews. 2. New teams. 3. New problems.
You slow down in unfamiliar systems because you didn't build them or haven't lived in them yet
How Widebase Works
Step into a real codebase
You receive a full project - controllers, models, services, migrations, tests. This isn't a blank canvas but a system with history. Choose the stack you want to test yourself in
app/
├── Http/Controllers/
│ ├── OrderController.php
│ ├── ProductController.php
│ └── Api/InventoryController.php
├── Models/
│ ├── Order.php
│ └── Product.php
├── Services/
│ └── PurchaseService.php
├── database/migrations/
└── tests/Feature/
└── StockManagementTest.php
src/
├── routes/
│ ├── orders.js
│ ├── products.js
│ └── inventory.js
├── models/
│ ├── Order.js
│ └── Product.js
├── services/
│ └── purchaseService.js
├── middleware/
│ └── auth.js
└── __tests__/
└── stockManagement.test.js
inventory/
├── views/
│ ├── orders.py
│ ├── products.py
│ └── purchase.py
├── models/
│ ├── order.py
│ └── product.py
├── serializers/
│ └── inventory.py
├── migrations/
└── tests/
└── test_stock_management.py
src/main/java/com/app/
├── controller/
│ ├── OrderController.java
│ └── InventoryController.java
├── model/
│ ├── Order.java
│ └── Product.java
├── service/
│ └── PurchaseService.java
├── repository/
│ └── ProductRepository.java
└── src/test/java/
└── StockManagementTest.java
internal/
├── handlers/
│ ├── orders.go
│ ├── products.go
│ └── inventory.go
├── models/
│ ├── order.go
│ └── product.go
├── services/
│ └── purchase.go
├── middleware/
│ └── auth.go
└── tests/
└── stock_management_test.go
src/
├── app/
│ ├── api/orders/route.ts
│ ├── api/products/route.ts
│ └── api/inventory/route.ts
├── lib/
│ ├── models/order.ts
│ ├── models/product.ts
│ └── services/purchase.ts
├── prisma/
│ └── schema.prisma
└── __tests__/
└── stockManagement.test.ts
Read the challenge
The purchase endpoint checks stock and decrements it in separate steps - no locking. Two users buy the last item simultaneously, and stock goes negative.
## Fix Stock Race Condition
Difficulty: Hard · 60-90 min
Skills: DB Transactions, Pessimistic
Locking, Concurrency
The purchase endpoint has a classic race
condition. Two concurrent buyers can both
pass the stock check and decrement -
leaving stock at -1.
Use transactions + locking to prevent
overselling. Don't break existing tests.
Submit and validate
Your solution runs against real tests. No subjective grading, just automated verification that your fix works.
> Validating solution...
✓ stock_never_goes_negative ........ PASS
✓ concurrent_purchases_handled ..... PASS
✓ sold_out_returns_409 ............. PASS
✓ successful_purchase_decrements ... PASS
✓ order_created_on_success ......... PASS
5 passed - Challenge complete.
Here's what working inside the platform looks like
Widebase already includes multiple challenges, with more continuously being added. Each one drops you into a full project with failing tests and a clear objective.
Fix Stock Race Condition
Context
The inventory purchase endpoint has a critical bug: it checks and decrements stock without any database transaction or locking. This means:
- Race condition - Two users buying the last item simultaneously can both succeed, driving stock negative
- Partial failure - If the second item in a multi-item purchase fails the stock check, the first item's stock is already decremented and never rolled back
Your Task
- Wrap the entire purchase in a database transaction
- Use row-level locking when reading product stock to prevent concurrent reads
- If any item fails the stock check, the entire transaction should roll back
- Return a 409 response for insufficient stock
Modify
app/Http/Controllers/Api/InventoryController.php
Hints
- Transactions auto-rollback on exceptions
- Row-level locks prevent concurrent reads on the same row
- Throwing a runtime exception inside the transaction triggers the rollback
Not algorithm puzzles. Not abstract problems. Not memorizing patterns.
This is Hands-on practice with real code, real constraints, and problems or features you've only read about.
If you feel strong in your own codebase
but slower in unfamiliar ones,
Widebase was built for you.