💼 Hiring Quest – Full Stack Laravel Engineer @ Career 180

👋 We are Career 180, a comprehensive and interactive Career Knowledge Network where all career-related services are centralized in one place.

We’re now hiring a Full Stack Laravel Engineer (3–5 YOE) to design and build our next-generation Learning Management System (LMS) that powers interactive online learning experiences for thousands of young learners.

🕓 Start Date: Immediate
🌍 Location: Hybrid (Nasr City – 3 days onsite, 10 AM–6 PM)
💰 Salary: EGP 40K – 70K

🛠️ How the Hiring Quest Works

1. Register for the quest

2. Receive full instructions via email 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 — others may be considered for freelance or future roles

🔍 Who We’re Looking For

1. ✅ 3–5 years of professional Laravel development experience

2. ✅ Strong in OOP, HTTP, REST/JSON, queues, caching, and validation

3. ✅ Solid grasp of Livewire v3 and Alpine.js patterns

4. ✅ Proficient in automated testing (Pest or PHPUnit)

5. ✅ Comfortable with Service/Action classes pattern, Composer, NPM, Vite, Tailwind, and Git

6. ✅ Bonus: experience with Filament

🧩 The Challenge — "Instructor Revenue Ledger"

The Story

An online courses platform (an LMS):

1. Students pay for a subscription to access the platform.

2. Instructors earn a revenue share of subscription income — the rest is the platform's cut.

3. Students choose one of three plans — monthly, 3-month, or annual — and pay for the whole term up front, on day one.

4. A single subscription gives access to courses from many instructors, so each payment has to be divided among the instructors involved.

5. On a schedule, the platform pays each instructor what they're owed, through an external payment provider (which you'll mock — see below).

This is the part of the system that moves real money.

Getting it wrong means an instructor is paid twice, paid the wrong amount, or paid money that later has to be recovered.

"It runs on my machine" isn't the standard here — it has to be correct, and stay correct when things go wrong.

What the system has to do

Build the money core: take subscription payments in, and pay instructors their share out — accurately, at scale, even when parts of the system fail or run more than once.

Your system should be able to answer, at any point in time:

1. How much each instructor is owed

2. How much has already been paid

3. How much is still outstanding

And to do so for a platform with:

1. 500,000 active subscriptions

2. Tens of millions of underlying records

It must also hold up under real-world conditions:

1. The payout process may run more than once — overlapping schedules, a manual re-trigger, or two servers at the same time. No instructor should ever be paid twice for the same thing.

2. The external payment provider is unreliable. It can succeed, fail outright, or stop responding after it has already moved the money — leaving you unsure whether a payment went through. Your design has to cope with that uncertainty.

3. Background workers can crash mid-way and have their jobs retried.

4. Refunds happen — including partway through a subscription term. Your design should handle a student leaving mid-term sensibly, given that they paid for the whole term up front.

How money is stored and divided is up to you — including how you handle amounts that don't split evenly between instructors.

Tell us what you chose and why.

We left some rules unspecified — on purpose

We have not spelled out every rule.

There are real questions in here about:

1. When money counts as earned

2. How a single payment should be divided between instructors

3. What should happen at the messy edges

Spotting those questions, making a sensible call, and explaining the trade-off is part of what we're evaluating.

If something is ambiguous, decide, write down your reasoning, and move on — don't email us to ask.

📦 What to Hand In

You do not need a full application.

Build the core, prove it works, and write down your thinking.

Required

1. Database schema + migrations

For subscriptions, instructor earnings/balances, and payouts.

2. Revenue allocation logic

The logic that takes subscription payments and turns them into what each instructor is owed (after the platform's cut).

3. Payout process

An Artisan command + queued jobs that pays instructors what they're owed.

4. Mock payment provider

A class that randomly:

1. Succeeds

2. Fails permanently

3. Times out after already succeeding

(The real result can be discovered later through a status check.)

Show how your code handles this safely.

5. Tests

Unit tests are required. Your submission should include a meaningful suite of unit tests covering core business logic and financial calculations, 

And tests for the behaviour that matters most.At minimum we expect coverage proving:

1. Running the payout process twice never double-pays

2. Retried jobs never double-pay

3. Unreliable provider responses never cause duplicate payments

6. One simple Filament screen

View:

1. Instructor balance

2. Payout history

Read-only is completely fine.

Senior Bonus (Discussion Only)

Do not build this.

Simply explain in your notes:

How would your design cope with a student changing plans mid-term (for example upgrading partway through an annual subscription with a fair price adjustment)?

We'll explore this during the review session.

🤖 AI Usage Policy

AI tools are allowed.

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

Please include a short document:

/docs/AI_USAGE.md

Cover the following points:

1. How you used AI during the task

2. The main prompts or workflows you relied on

3. Which parts were fully generated vs manually designed or modified by you

4. The engineering decisions you personally made

5. What differentiates your solution from other submissions

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

You do not need to share every prompt.

However, you should provide enough information for us to understand your workflow and level of ownership.

During the review session, we may ask you to:

1. Explain any part of your solution

2. Modify parts of the implementation live

3. Justify architectural decisions

4. Discuss alternative approaches and trade-offs

Submissions that demonstrate strong understanding will be valued more highly than submissions that are merely complete.

🎥 Video Submission (Required)

Submit a 15–20 minute video.

We are evaluating your thinking process as much as your code.

Your video should include:

1. Introduction (2–3 minutes)

1. Brief introduction

2. Previous projects involving payments, subscriptions, ledgers, financial flows, or large-scale systems

3. Why you chose your approach

2. Architecture Walkthrough (5 minutes)

Explain:

1. Domain model

2. Database design

3. Revenue allocation strategy

4. Instructor balance calculation approach

5. Payout architecture

6. Key trade-offs

3. Failure Scenario Demonstration (5–7 minutes)

Demonstrate at least three scenarios:

1. Running payouts twice

2. Duplicate job execution

3. Worker retry after failure

4. Payment provider timeout

5. Payment provider success followed by delayed confirmation

6. Refund after payout allocation

7. Rounding edge cases

Show how your system behaves and why money remains correct.

4. Testing Strategy (2–3 minutes)

Explain:

1. What you tested

2. Why you chose those tests

3. What risks they protect against

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

Explain:

1. Where AI helped

2. What AI suggestions you rejected

3. The most important engineering decisions you made yourself

4. What makes your solution different from a typical AI-generated implementation

6. Future Improvements (1–2 minutes)

If this were production:

1. What would you improve next?

2. What scalability concerns remain?

3. What risks still exist?

🧰 Tech Stack

1. Laravel 11

2. Livewire v3

3. Alpine.js

4. Filament v3

5. Pest for testing

6. MySQL

7. Docker (optional)

📝 What You Should Submit

GitHub/GitLab repository containing:

Code

1. Source code

2. Migrations

3. Factories

4. Seeders

Documentation

README.md

Include:

1. Setup instructions

2. How to run tests

3. Assumptions made

/docs/ARCHITECTURE.md

Include:

1. Key architectural decisions

2. Revenue allocation strategy

3. Idempotency approach

4. Provider timeout handling

5. Scaling considerations

6. Known limitations

/docs/AI_USAGE.md

Include the AI explanation described above.

Evidence

• Screenshot of passing test cases

• Video submission link

📊 Evaluation Criteria

Area Weight

1. Correctness of Money Flows 25%

2. Failure Handling & Idempotency 20%

3. System Design & Architecture 20%

4. Laravel Implementation & Data Integrity 15%

5. Testing Strategy & Coverage 10%

6. Documentation & Engineering Reasoning 5%

7. Video Explanation & AI Transparency 5%

✅ What We Value

We are intentionally more interested in:

1. Correctness with money

2. Failure handling

3. Engineering judgment

4. Trade-off analysis

5. System design thinking

6. Clarity of reasoning

than in the number of features implemented.

A smaller solution with strong engineering judgment will score higher than a larger solution with weak reasoning.

We're genuinely more interested in how you think than whether every box is ticked.

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