A few months ago I started doing technical interviews for a developer platform that primarily accepts senior web developers.
Since then I’ve interviewed a large number of candidates and, for consistency, I’ve mostly used the same practical coding exercise that I wrote from scratch.
The task itself is intentionally simple.
You receive three API clients. All of them implement the same interface, but each returns product data in a slightly different format. The goal is to normalize the data, filter invalid products, deduplicate entries, and return a clean sorted result.
There are no frameworks involved. No Laravel. No Symfony. No React.
Just PHP.
The purpose of the exercise is not to test framework knowledge.
It’s designed to answer a much more important question:
How does a developer behave when faced with an unfamiliar problem?
After dozens of interviews, I’ve noticed some recurring patterns that separate stronger candidates from weaker ones.
Iterate Fast
One of the biggest differences between senior and non-senior developers is speed of iteration.
Many candidates spend ten minutes reading every file before writing a single line of code.
In a real project, that approach rarely scales.
Senior developers usually build a rough mental model, make an assumption, test it, and adjust based on what they learn.
The goal isn’t to be right immediately.
The goal is to make progress.
When I join a new codebase, I don’t expect to understand everything before writing code. I expect to understand enough to start moving.
Don’t Be Afraid To Fail
One thing I notice often is candidates refusing to run the code until they believe their implementation is complete.
This is backwards.
The fastest way to understand a system is usually to break it.
Run the code.
Inspect the output.
See what the APIs return.
Read the errors.
Adjust.
Many candidates spend several minutes implementing logic before they’ve even verified what the payload looks like.
Senior developers usually do the opposite.
They gather information first and let the code guide them.
Read The Requirements Twice
This sounds obvious, but it’s one of the most common reasons candidates struggle.
Many developers immediately jump into coding after reading the first few lines of a task. Then, 30 minutes later, they discover they forgot a requirement.
In my exercise, common misses include:
- Keep the cheapest product when duplicate IDs exist.
- Ignore invalid products.
- Sort by price.
- Continue processing if one API client fails.
The strongest candidates usually spend an extra minute reading the requirements and save themselves ten minutes of rework later.
Pay Attention To Details
The coding task deliberately contains small differences between API responses.
One client returns products directly.
Another returns them under one key.
A third returns them under a completely different key.
The most common mistake is immediately assuming all payloads have the same structure.
foreach ($payload as $product)Then candidates spend ten minutes debugging the wrong problem.
The issue wasn’t the loop.
The issue was misunderstanding the data structure.
Senior developers tend to verify assumptions before building on top of them.
Use The Tools You’re Given
The exercise contains helper methods.
I put them there intentionally.
One helper even hints at how to differentiate API clients by their concrete class type.
Surprisingly, almost nobody uses it.
A good engineer should always ask:
What tools already exist that make this easier?
That’s true in interviews and in production systems.
Know The Basics Of Your Language
Frameworks are wonderful.
Laravel, Symfony, React, and Next.js make us dramatically more productive.
But senior developers should still understand the underlying language.
If you’ve worked with PHP for many years, I expect you to be comfortable with:
- Arrays
- Associative arrays
- Loops
- Sorting
- Basic string manipulation
- Common standard library functions
I don’t expect perfect memory.
I do expect familiarity.
The exercise isn’t designed to trick anyone. It’s designed to see whether fundamental language skills are present beneath the framework knowledge.
Documentation Is Part Of The Job
One thing I always tell candidates:
You are allowed to search the PHP documentation.
Many still don’t.
This surprises me because modern software development is not a memory competition.
Professional developers solve problems.
Part of problem solving is:
- Identifying what you don’t know
- Searching for relevant information
- Applying it correctly
If you forget how usort() works, that’s completely fine.
If you don’t know how to search for it, that’s a bigger concern.
The strongest candidates are usually not the ones who remember everything.
They’re the ones who can find answers quickly.
Learn To Debug
One of the most underrated engineering skills is debugging.
Some candidates seem almost afraid to use:
var_dump($payload);
die();I actively encourage it.
You cannot solve a problem you don’t understand.
Senior developers are usually comfortable inspecting variables, validating assumptions, and narrowing down possibilities until the issue becomes obvious.
Debugging is not a sign of weakness.
It’s one of the core skills of software engineering.
Think Out Loud
One thing candidates often forget is that interviews are collaborative exercises.
When a candidate spends five minutes silently staring at the screen, I have no idea whether they are making progress or completely stuck.
Talking through your reasoning helps tremendously.
Even something as simple as:
“I’m not sure what this payload contains yet, so I’m going to inspect it first.”
gives the interviewer confidence that you’re approaching the problem methodically.
Many candidates accidentally hide good thinking behind silence.
Work With Reality, Not With The Ideal Solution
Occasionally candidates complain that an API response is inconsistent or doesn’t follow best practices.
They’re often right.
But that’s not the point.
Real-world software rarely exists in ideal conditions.
- Government APIs are weird.
- Third-party integrations are weird.
- Legacy systems are weird.
Your job as an engineer is not to complain about reality.
Your job is to make reality work.
The exercise intentionally simulates that situation.
Avoid Creating Complexity
Another pattern I see is candidates accidentally creating complexity because they misunderstood the data structure.
I’ve seen solutions with multiple nested loops that could have been solved with a simple associative array indexed by product ID.
I’ve seen deduplication implemented using several passes over the same data.
In one interview, a candidate used three nested foreach loops to deduplicate products.
Technically it worked.
But it was a symptom of a deeper issue: the candidate was fighting the data structure instead of using it.
Senior developers usually look for simpler solutions.
Before writing more code, ask yourself:
Can I make the data structure work for me?
The answer is often yes.
Be Comfortable Outside Your IDE
Modern IDEs are incredible.
They autocomplete code, highlight mistakes, suggest fixes, and generate boilerplate.
But interviews sometimes happen in simpler environments.
A basic editor won’t automatically close your brackets.
It won’t warn you about every syntax error.
That’s okay.
A senior developer should still be able to write basic PHP without relying entirely on tooling.
The IDE should make you faster.
It shouldn’t be the only reason the code works.
How To Pass This Type Of Coding Exercise
- Run the code immediately.
- Inspect every payload before writing logic.
- Solve one requirement at a time.
- Don’t optimize too early.
- Use helper methods if they’re provided.
- Search the documentation when you forget something.
- Use debugging output aggressively.
- Prefer simple working solutions over clever unfinished ones.
- Keep talking through your thought process.
- Read the requirements twice before coding.
Final Thoughts
When I evaluate senior developers, I care far less about memorized knowledge than most people think.
I don’t care whether someone remembers every PHP function.
I don’t care whether they can recite framework documentation from memory.
What I care about is whether they can take an unfamiliar problem, understand it quickly, make progress, adapt when they’re wrong, and eventually arrive at a working solution.
That’s what senior engineers do every day.
Not because they know everything.
But because they know how to figure things out.
Leave a Reply