💼 Hiring Quest – Full Stack PHP Developer @ Innov8

👋 We are Innov8, a software company building digital solutions that help businesses streamline their operations across multiple industries. Our products include ERP systems, Logistics Management Systems, and POS solutions, helping organizations automate workflows, manage inventory, optimize deliveries, and improve operational efficiency.

We're hiring a Full Stack PHP Developer (1-2 YOE) to join our engineering team and build business-critical modules that handle inventory movement, warehouse operations, purchase orders, deliveries, and financial transactions.

🕓 Start Date: Immediate

🌍 Location: Hybrid (Smouha, Alexandria)

     (Alexandria residents are preferred)

💰 Salary: 15K-20K EGP

🛠️ How the Hiring Quest Works

1. Register for the quest

2. Receive the full challenge after registration closes

3. Submit your solution before the deadline

4. Top candidates will be invited to a technical review session

5. One candidate will be hired — outstanding candidates may also be considered for future opportunities

🔍 Who We're Looking For

1. ✅ 1-2 years of professional PHP development experience 

2. ✅ Strong knowledge of Laravel and/or CodeIgniter

3. ✅ Excellent understanding of OOP, SOLID principles, and common Design Patterns

4. ✅ Experience with Dependency Injection and ORM

5. ✅ Strong SQL and MySQL optimization skills

6. ✅ Good understanding of JavaScript, jQuery, Bootstrap, HTML, and CSS

7. ✅ Experience designing and consuming REST APIs

8. ✅ Strong understanding of web security (OWASP Top 10, Authentication, Authorization, SQL Injection, XSS, CSRF, Input Validation)

9. ✅ Experience with Git

10. ✅ Comfortable working within Agile/Scrum teams

⭐ Bonus

1. React.js experience

2. Docker experience

3. Automated testing experience

🧩 The Challenge — "Warehouse Inventory Reservation Engine"

The Story

Innov8 provides ERP and Logistics software used by companies operating multiple warehouses.

When customers place sales orders, inventory cannot simply be deducted immediately.

Instead, products move through several business stages:

1. Available inventory

2. Reserved inventory

3. Picked inventory

4. Packed inventory

5. Shipped inventory

6. Delivered inventory

Meanwhile, many things may happen:

1. Multiple users reserve inventory simultaneously.

2. Warehouse operators cancel reservations.

3. Orders are edited after reservation.

4. Shipments fail.

5. Orders are partially fulfilled.

6. Background jobs may retry.

7. External shipping providers may send duplicate webhooks.

8. Inventory must never become negative.

9. The same inventory must never be reserved twice.

Your task is to design the Inventory Reservation Engine, the core component responsible for ensuring inventory always remains correct regardless of retries, duplicate events, or concurrent operations.

Think of this as the heart of an ERP system where inventory correctness is more important than feature count.

What the System Must Do

Build the inventory core responsible for:

1. Managing stock across warehouses

2. Reserving inventory safely

3. Releasing reservations

4. Confirming shipment

5. Handling partial shipments

6. Recording inventory movements

7. Receiving duplicate shipment callbacks safely

8. Maintaining inventory consistency even when jobs fail

At any point, the system should answer:

1. Current available stock

2. Reserved stock

3. Picked stock

4. Shipped stock

5. Inventory movement history

6. Which reservations remain open

7. Which orders have already consumed inventory

Real World Conditions

1. Your design should safely handle situations such as:

2. Two users reserve the last remaining item simultaneously.

3. The reservation command runs twice.

4. The same background job executes multiple times.

5. A shipment webhook arrives more than once.

6. A worker crashes halfway through processing.

7. Orders are partially cancelled after reservation.

8. Products are transferred between warehouses while reservations exist.

9. Inventory updates must remain consistent under concurrent requests.

Some Business Rules Are Intentionally Missing

Real ERP systems rarely have perfectly defined requirements.

For example:

1. Can reservations expire?

2. How should partial shipments affect reservations?

3. Can inventory be transferred while reserved?

4. Should reservations lock inventory immediately?

5. How should overselling be prevented?

These decisions are intentionally left open.

Choose sensible rules.

Document your assumptions.

Explain your trade-offs.

We are evaluating your engineering judgment as much as your implementation.

📦 What to Hand In

You do not need to build an entire ERP.

Focus on building the inventory engine correctly.

Required

1. Database Schema + Migrations

Include tables for:

1. Products

2. Warehouses

3. Inventory

4. Reservations

5. Orders

6. Shipment records

7. Inventory movements

8. Reservation history

2. Inventory Reservation Logic

Implement the business logic responsible for:

1. Reserving stock

2. Preventing overselling

3. Releasing reservations

4. Partial reservation handling

5. Reservation expiration (if you choose to support it)

3. Shipment Processing

Implement an Artisan command and queued jobs that:

1. Process pending shipments

2. Confirm inventory deduction

3. Handle retries safely

4. Prevent duplicate shipment processing

4. Mock Shipping Provider

Implement a fake shipping provider that randomly:

1. Succeeds

2. Fails permanently

3. Times out

4. Sends duplicate delivery confirmations

5. Delays confirmation before reporting success

Show how your design safely handles every case.

🤖 AI Usage Policy

AI tools are allowed.

However, this quest is designed to evaluate your engineering judgment, architectural thinking, and understanding of your solution—not just the final implementation.

Please include:

/docs/AI_USAGE.md

Cover the following:

1. How you used AI during the task

2. The main prompts or workflows you relied on

3. Which parts were fully generated versus manually designed or modified

4. The engineering decisions you personally made

5. What differentiates your solution from other submissions

6. Any architectural trade-offs or improvements you intentionally chose

You do not need to include every prompt.

Provide enough information for us to understand your workflow and level of ownership.

During the technical review we may ask you to:

1. Explain any part of your implementation

2. Modify part of the solution live

3. Justify architectural decisions

4. Discuss alternative designs

5. Explain why specific trade-offs were chosen

Submissions demonstrating strong understanding will score significantly higher than submissions that are merely feature-complete.

🎥 Video Submission (Required)

Submit a 15–20 minute walkthrough.

We're evaluating your engineering thinking—not just the finished code.

1. Introduction (2–3 min)

Introduce yourself.

Briefly discuss previous projects involving:

1. ERP systems

2. Inventory

3. Warehousing

4. Logistics

5. POS

6. Large CRUD business systems

Explain why you chose your architecture.

2. Architecture Walkthrough (5 minutes)

Explain:

1. Domain model

2. Database schema

3. Reservation lifecycle

4. Inventory movement strategy

5. Concurrency handling

6. Security considerations

7. Key architectural decisions

8. Design patterns used

9. SOLID principles applied

3. Failure Scenario Demonstration (5–7 minutes)

Demonstrate at least five scenarios:

1. Two users reserve the last item simultaneously

2. Running reservation twice

3. Duplicate shipment webhook

4. Worker retry after failure

5. Shipment timeout followed by confirmation

6. Reservation cancellation

7. Partial shipment

8. Inventory transfer

9. Concurrent requests attempting to update inventory

10. SQL transaction rollback after failure

Explain why inventory remains correct after each scenario.

4. Testing Strategy (2–3 minutes)

Explain:

1. What you tested

2. Why these tests matter

3. Which business risks they protect against

4. How unit tests validate business rules

5. AI Usage & Engineering Decisions (2–3 minutes)

Explain:

1. Where AI helped

2. What AI-generated suggestions you rejected

3. Important engineering decisions you made independently

4. How your solution differs from a typical AI-generated implementation

6. Future Improvements (1–2 minutes)

If this system were running in production:

1. What would you improve?

2. How would you scale it?

3. What remaining risks exist?

4. How would you support millions of inventory transactions?

🧰 Tech Stack

1. PHP 8+

2. Laravel (preferred) or CodeIgniter

3. MySQL

4. JavaScript

5. Bootstrap

6. jQuery

7. Git

Optional:

1. React.js

2. Docker

3. PHPUnit or Pest

📝 What You Should Submit

Repository

GitHub or GitLab containing:

1. Source code

2. Database migrations

3. Seeders

4. Factories

5. Tests

Documentation

README.md

Include:

1. Setup instructions

2. How to run the project

3. How to run tests

4. Assumptions

5. Known limitations

/docs/ARCHITECTURE.md

Include:

1. Domain model

2. Reservation lifecycle

3. Inventory movement strategy

4. Concurrency handling

5. Database design decisions

6. Security considerations

7. Scaling strategy

8. Trade-offs

9. Future improvements

/docs/AI_USAGE.md

Include the AI usage explanation described above.

Evidence

Include:

• Screenshot of passing test cases

• Video walkthrough link

📊 Evaluation Criteria

Area

Weight

1. Inventory Correctness & Business Logic 25%

2. Concurrency Handling & Data Integrity 20%

3. System Design & Architecture 20%

4. Laravel/PHP Implementation Quality 15%

5. Security Best Practices 10%

6. Testing Strategy & Coverage 5%

7. Documentation, AI Transparency & Engineering Reasoning 5%

👉 Final hiring decisions will be made within 3–5 business days after the technical review.