Train in unfamiliar codebases. Identify your blind spots. Expand your engineering range.
Most engineers grow inside the same codebase for years. You become comfortable. You know where everything lives, everything is intuitive
Inside that environment, you feel capable — and you are.
But growth slows down in familiarity. A good test of engineering is adaptability.
That's why transitions become difficult — interviews, new teams, unfamiliar stacks. Not because of inability, but because of limited exposure to systems you didn't build yourself or haven't yet lived in.
Not because you couldn't, but because you never had to.
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.phpsrc/
├── routes/
│ ├── orders.js
│ ├── products.js
│ └── inventory.js
├── models/
│ ├── Order.js
│ └── Product.js
├── services/
│ └── purchaseService.js
├── middleware/
│ └── auth.js
└── __tests__/
└── stockManagement.test.jsinventory/
├── views/
│ ├── orders.py
│ ├── products.py
│ └── purchase.py
├── models/
│ ├── order.py
│ └── product.py
├── serializers/
│ └── inventory.py
├── migrations/
└── tests/
└── test_stock_management.pysrc/main/java/com/app/
├── controller/
│ ├── OrderController.java
│ └── InventoryController.java
├── model/
│ ├── Order.java
│ └── Product.java
├── service/
│ └── PurchaseService.java
├── repository/
│ └── ProductRepository.java
└── src/test/java/
└── StockManagementTest.javainternal/
├── handlers/
│ ├── orders.go
│ ├── products.go
│ └── inventory.go
├── models/
│ ├── order.go
│ └── product.go
├── services/
│ └── purchase.go
├── middleware/
│ └── auth.go
└── tests/
└── stock_management_test.gosrc/
├── 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.tsThe 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.Your solution runs against a comprehensive test suite. No subjective grading — just clear, automated verification that your fix works under all tests.
> 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.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.
The inventory purchase endpoint has a critical bug: it checks and decrements stock without any database transaction or locking. This means:
app/Http/Controllers/Api/InventoryController.php
Get early access to structured, real world engineering challenges.