12 Laravel Interview Questions: Employer and Candidate

There are many articles with "Laravel interview questions" but they mostly sound like a pub quiz knowledge test.

• What is the latest Laravel version?
• What is Composer?
• What route files are included in Laravel?

Answering such questions doesn't help to determine candidate fit in real projects.

So we decided to write our own list of questions.

We will look at both sides:

• As an interviewer: what would I ask if I hired a Laravel developer?
• As a candidate: what would I prepare for?

What Would I Ask as an Interviewer?

Of course, our goal is to find out if the candidate is a fit for our company and projects, so technical questions may vary a lot, and we will not cover them here.

However, a more important goal is to evaluate the thinking process of the candidate. Often, there won't be one correct answer.

For that, I suggest asking these 8 questions.

Q1. How do You Typically Structure Laravel Projects?

Expected answer:

There is no correct answer!

But wait, why? Surely, there has to be one, right...?

No! The whole idea of this question is to learn about you and your experiences. An expected outcome here can be one or more of the following:

• It depends on ... - Give a few reasons for how different things affect your structure choice. Different projects have different needs. Some might benefit from the DDD structure, while others might not.
• I've worked on ... where I did ... - This answer discusses your experience in different fields. It can be different languages, frameworks, or project types. Let them know what you did!

This gives the company a good indication that you can think logically and navigate the complex maze of project requirements. It also could show that you have experience in multiple structures and can pick the best one as soon as you understand the requirements.

Q2. What Are the Typical Performance Problems in Laravel, and What are the Solutions?

Expected answer:

The leading cause of performance issues is the Database and database structure. Poorly optimized queries can ruin even the best structure, so that's the first thing we should consider.

But why do we talk about Databases? Databases are often considered non-Laravel things, but complex database queries can make or break your application.

Of course, this question is more philosophical, and you should give examples of possible issues. From loading too much data to using collection methods instead of database functions, Databases themselves, anything can go here.

If you are unsure how to write Eloquent in a performant way, we have a Course on Performant Eloquent

Q3. Share your Proudest Solution

Expected answer:

Sharing the most significant challenge you conquered.

Of course, this one is challenging if you are starting. But these can be pretty simple:

• I've built ... with support for ... - Tell them the cool and passionate thing you built!
• I've faced limitation ... and conquered it with ... - Talk about your issues and what you did to solve them.
• I was building ..., but it didn't work out. So I had to switch multiple ... to solve it - Tell them about your problems, what you tried, and the final solution.
• I experimented with ... and built ... - Emphasize the experimentation and lead to your final solution.

Once again, this is not a direct question but rather a way for you to share your most significant solution. Include what you tried, what the result was, and why you were searching for a better option.

Q4. What is the Thing You Hate in Laravel?

Expected answer:

Your own friction point

One more to think about for yourself. Share what you personally dislike and give arguments why:

• I wouldn't say I like ... because ... - Tell about what you hate and all your reasons.
• I hate ... as it caused me issues with ... - Or broadly tell what you disliked and where it created friction for you.

In general - think about the experience you had while working. There has to be something, even the most minor thing, you did not like. It doesn't have to be something big. It could be a simple placement of a specific thing.

Note: Make sure that your arguments are easy to understand. Give a good example of a pain point. And remember to mention how you solved it!

Q5. What is the Thing You Love in Laravel?

Expected answer:

Your own loved feature

Each of us has different preferences. Talk about the best feature you saw in the framework:

• I love ... because it allows me to ... - Make an argument, with a visual end result, of the thing you really like.

Of course, this assumes that you know that thing well. Anything can be included here; ensure your examples are clear and show the advantages.

Note: You can name multiple things - big or small. The idea here is to share what makes your experience better!

Q6. What are Your Go-To Tools and Packages?

Expected answer:

A list of tools/packages you use daily

Each project has different requirements. But some tools make your job easier no matter what. So talk about them:

• I use ... tool as it allows me to ... - Give a reason for your tool choice.
• I install ... package as it is ... - Make a good argument on how that package helps you.

Overall, look at your applications and workflows. Maybe you use spatie permissions in every single project? Then talk about it!

Note: Tools/Packages are often personal preference matters, even if they disagree—that's okay! Your workflow can have custom things that theirs doesn't!

Q7. Do You Have any Experience in Other Languages or Tools?

Expected answer:

An experience story of what you used and learned.

Everyone has some side project (and yes, even the ones we did not finish - count!). These projects are not always meant for public use but rather - experiments. So talk about them:

• I've used ... language and built ... while learning ... - Talk about your experiments with different languages and what you built/learned with them. Each language can advance your knowledge and deepen your understanding.
• I used ... framework and learned ... - Different tools/frameworks have different concepts. If you ever touched one - talk about it.
• I have built ... and then understood ... - If you built something to understand the concepts - let them know. This can show that you are interested in understanding the topic as much as you can.

Overall, this question shows your personality and professional skill set. Some people like to touch various tools and constantly learn new skills. Others want to focus on one tool they have and use it to its fullest potential.

Note: Some companies are looking for dedicated people, and others are looking at "Jack of All Trades" candidates. Try to sell your strengths and how you deepen your knowledge.

Q8. What is Your Experience with Bug Tracking?

Expected answer:

Tell them about the tools that you use for bug tracking.

Every application needs Bug Tracking in Production. So tell them about the tool you use for it:

• I use ... in my applications - Tell them what you personally use and why.
• I have experience with ... in my previous jobs - Talk about what your previous company used and what you liked/disliked.
• I'm learning ... as it ... - Sometimes you are just in the process of learning. So talk about it and tell them your findings.

This question is meant to determine which tools you have used and your experience with them. So feel free to discuss what you used and how deep you went with it.

What to Prepare For as a Candidate

A typical approach by many developers is to re-read the docs of Laravel or other framework you're interviewed for.

But, let's admit: you won't learn in a day what you haven't learned in years previously.

Instead, these are 4 questions I suggest you to think about before entering the Interview room.

Q1. Remember Projects You Worked On

When preparing for an interview - start with a list of projects you worked on. Combine this with short descriptions and then pick the most important ones:

• "Project 1" - Worked on the API system implementing versioning.
• "Project 2" - Implemented localization
• "Project 3" - Created a self-service reservation system
• And so on...

When the list is completed, pick the ones that are most relevant to the company you are applying to.

Q2. Research the Company You Are Interviewing With

Of course, when joining a new company, you have a huge homework task ahead of you. Learn what the company does.

Search everywhere. Look for various things, such as:

• Their technology stack
• Their social media posts
• Look for public employees and learn what they are saying publicly.
• Look at their webpage and see what they say.

This can benefit you in multiple ways:

• You will know their tech stack - This is great as it will give you an idea of what to expect in an interview.
• You can understand the product - This helps you pick your previous projects closest to their current one.
• You can understand their work culture - If employees share blog posts or findings - that's a great indication of company vibe.

Overall, our strong recommendation is to look at whatever the company makes publicly available. This can paint a picture of the company and help you pick your answers tailored to it.

Note: Not every company will publicly have a lot of information.

Q3. Remember the Different Structures You Worked With

Think about your previous projects and identify the patterns you have seen. It's pretty common to get questions about pattern/structure usage and opinions around it.

For example, if you have projects that used one of these:

• Modular approach
• Custom packages
• Domain Driven Design
• Event sourcing
• Or anything else that's not the standard system

It would benefit you to think about the lessons you learned and what they are called. Just to give you an example, a lot of people use patterns without even knowing their names. So think about it and try to see what you have used.

This helps the company know how experienced you are and will help you understand what they expect.

If you are unsure what structures are called - we have a Course on Design Patterns

Q4. Think About the Most Insane Challenge You Had

Think about the challenges you had in your career. Look for something that is a huge success story with a challenge:

• Maybe you just won a huge customer, and you didn't have great onboarding
• Maybe your project quickly grew from 100 to 10 000 users in the middle of the night!
• Maybe you had a payment provider fail and had to quickly install backups.
• Maybe a downtime happened in one of your service providers.

Talk about the challenge that came out of nowhere. It can be the middle of the night or a random ad/marketing message that worked. Just make sure that the story has the following:

• An unexpected event happening
• How you handled it
• What lessons you have learned
• What safety checks have you put in place

This short challenge sharing can quickly show the future employees that you are determined to find a solution and still remember the life lessons shown.

Do you have any other suggestions/ideas? Let us know, and we'll update the article to help others in their job interviews!