How to Prepare For a PHP Technical Interview

Iain Cambridge | October 27, 2021

This blog article will provide you with a guide on how to prepare for a PHP Technical Interview. Whether you’re a junior developer looking for your first job, you’ve been working at an agency going to FinTech, or you’ve been out of the interview game for a few years – this article will help you get ready for your interview.

As knowledge on every subject area will not be required for every technical interview, this post will be split into sections. Each section will give you details about a topic area and give you an overview of what you’re expected to know at your job entry level and for the particular PHP job you’re interviewing for. There’s no point learning Magento if you’re planning to work at FinTech, but if you’re hoping to work at a digital agency then you’ll need to know about some of these things.

This post won’t cover everything in lots of detail, but it will give you a brief description of each area with links to resources that might help you. In some sections, there will be example questions with more information about an area; in other sections, there will just be descriptions, as these are core areas which you should look into and learn more about using the resources. Not all companies ask about all things, so some areas may not be necessary for you; but hopefully you can take something away from this article when preparing for a PHP technical interview.


Unsurprisingly, as it’s a PHP technical interview, PHP will be talked about no matter what level of development you are doing; but the level of the questions will be different based on the position you’re interviewing for. The more junior you are, the more you’ll be asked about the OOP features in PHP.

What are the new features in the latest release?

This question will test whether you’re up-to-date with the latest PHP.

What version of PHP are you using?

This question will show them which PHP features you’re used to and which ones you’re not used to.


Basic Design/Architecture

For juniors, one of the things they’ll want to know is whether you understand basic design principles and architecture. Here are some questions that you might get:

  • Do you know why globals are bad?
  • What is the difference between object-oriented and procedural code?
  • Have you built your own framework?
  • What is dependency injection?
  • What is the difference between an interface and an abstract class?



Git is the most popular version control software. It’s used to keep track of any changes you or others have made and it allows a team of developers to work on the same code at the same time. Here are some questions both juniors and senior developers may get:

Basic Git Questions

  • What does Git do?
  • How do you merge a branch?
  • How do you revert a commit?
  • How do you set up a GitHub account?
  • When would you use Git?

More Advanced Git Questions

  • How do you cherry-pick a commit?
  • How do you rebase a branch?
  • How do you squash a branch?



When it comes to databases, most of the time they’ll focus on SQL. Especially if you’re applying for a junior or agency role.

Basic SQL Questions

  • How would you start to fix performance issues with a SQL Query? (Explain query)
  • What is a JOIN?
  • What is the difference between the different types of JOINs?

More Advanced SQL Questions

  • What is the difference between GROUP BY and DISTINCT?
  • What are indexes?
  • How would you check if indexes are being used?
  • How do foreign keys work?
  • How does partitioning work?

Other Database Questions

  • What is MongoDB?
  • What is a document-based database?
  • What is the CAP theorem?


Design Patterns

In a PHP interview you’ll often be asked about design patterns, so here are some basic questions you might get asked:

  • What is the factory pattern and when should you use it?
  • What is the strategy pattern and when should you use it?
  • What is the decorator pattern and when should you use it?



Virtualisation is normally based around Vagrant and Docker for both the development environments and for deploying code to production. Here are some questions:

  • Do you have experience in Vagrant?
  • Do you have experience with Docker?



You will typically get asked about SOLID when you’re interviewing for in-house roles at more established companies. Here are some questions you may be asked with some details about each SOLID principle:

What is S.O.L.I.D?

SOLID is a group of principles which are commonly used as ideas when designing decoupled and clean code. The name SOLID is an acronym of those principles.

What is the SRP?

The first principle is the Single-Responsibility Principle, which is basically a class or module which should only have one responsibility. This principle also means that everything which changes together should be grouped together. A responsibility should only be in one place and shouldn’t be split up.

What is the Open-Closed Principle?

The Open-Closed Principle is that code should be open to extension, but closed to modification. Originally, it was that a class should only have final methods, but that the class itself should be open to being extended. These days the principle means that you should use interfaces to allow for extension and extend using design patterns.

What is Liskov’s Object Replacement Principle?

Liskov’s Object Replacement Principle is that an object should be replaceable with another object without it fundamentally changing the way the application works. For example, you should be able to change objects that write to a database as this won’t change how the application works; but if you replace an object and it goes from being banking software to appointment booking software, then that would be a problem.

What is the Interface Segregation Principle?

The penultimate principle is the Interface Segregation Principle, which is basically SRP for interfaces. An interface should only have one responsibility. You shouldn’t have empty methods that exist only because implementation of another interface requires them. If you have classes that implement an interface and it has empty methods, then you’re breaching this principle.

What is the Dependency Inversion Principle?

The Dependency Inversion Principle is to ensure that the code doesn’t depend on the code it’s using, but on an interface or abstract class. The idea is that you should be able to change out dependencies and everything should still work, as the code doesn’t depend on any implementation.


Domain-Driven Design (DDD)

DDD questions are typically asked when you’re interviewing for in-house roles at more established companies and will normally mention DDD in their job advert. Here are some questions you may be asked with some details about each aspect of DDD:

What is DDD?

DDD is the concept that the language of the domain experts, those with deeper knowledge about the business domain, and the language of how the code and business domain works match. Essentially, by following this concept you need to use the same language everywhere, so that it’s the same for something in the code, in the technical discussions, and in the discussions with the domain experts. The goal is to truly understand the business domain and create code that represents it. This way you reduce logic bugs and decrease complexity, making it easier to work with the code and provide value to the company.

How would you implement DDD?

Fundamentally, you would want to be talking to the domain experts on a regular basis and then define the bounded contexts.

What is the difference between a Value Object and an Entity?

A Value Object is something that when changed is no longer the same thing. For example, an email address. If you change a letter in an email address – it is a different email address. When doing logical checks to see if they’re the same, they will be classed as different email addresses.

An Entity is something that when changed is fundamentally the same thing. So if a person changes their name – they are still the same person. If they change their hair colour – they are still the same person. No matter what they change, that individual is still the same person.

What is Tactical DDD?

Tactical DDD is the name given to the patterns and techniques within the code and the technical side of the DDD. These are normally the hard skills of the DDD.


Behaviour-Driven Development (BDD)

Similarly to DDD, BDD questions are typically asked when you’re interviewing for in-house roles at more established companies and will normally mention BDD in their job advert. Here are some questions you may be asked with some details about each aspect of BDD:

What is BDD?

BDD is the act of finding out which behaviour you need for your application and using that to drive the development of the application. This involves talking to stakeholders to find out what they need to do and why. This will help you figure out what the core value of the company is, so that you can deliver the maximum business value to that company.

How would you find out what business value is needed?

Talk to the business stakeholders and ask them what they need to do, and what they care about and why. The key to the BDD process is understanding why they need it.


Unit Testing/Test-Driven Development (TDD)


CQRS & Event Sourcing

CQRS and Event Sourcing are heavily used in FinTech. If they mention either of these terms or DDD on their job advert, then having a brief understanding of this is a good idea.

CQRS stands for Command Query Responsibility Segregation, which is where you separate out the responsibilities of reading and writing. With written actions being commands and readable actions being queries.

Event Sourcing is essentially logging and storing every state change of an application. This allows you to recreate a previous state that the application was in and therefore provides you with an easy way to roll back to a previous state, to understand how the current state was created.

These are commonly used together as you can use commands to handle your written actions and then have an easy place to create and store these events. Events are at the core of CQRS.


Hexagonal Architecture

Hexagonal architecture is a pattern used to isolate your domain from implementation details. If the company mentions this architecture or DDD in their job advert, then having a brief understanding of this is a good idea.

This architectural pattern is the idea that you should be able to take your application and use it for various things to solve the same problems. For instance, like changing an app from being a web-based app to being a command-line app. To do this there are three layers: the domain layer, the adapter layer, and the application layer.

The domain layer is where you have your DDD-based code which is the core business logic.

The adapter layer is where you have the code for the implementation details.

The application layer is where you connect the domain and the adapter layer.



Microservices are a hot topic and seem to be considered the best practice everywhere. In reality, every team seems to create and think of microservices differently. The core concept of microservices is that they allow you to split parts of your application down into maintainable and separate applications. This helps you keep concepts separate and scale each one separately, while reducing your overall dependence on the microservice. Keeping these concepts separate means that replacing one thing doesn’t take too long, compared to having to rewrite a monolith application which can take a very long time.


Author Details
Iain Cambridge

October 27, 2021


Founder and Creator of the Parthenon Symfony bootstrap. With over 10-years of experience building PHP applications using techniques such as BDD, DDD, SOLID, and TDD just to name a few.

He currently spends his time working on Parthenon to help developers build their Symfony applications without having to deal with the generic functionality that all sites need.