4th January 2024
Every so often I get asked to sit in on interviews for new engineers. As an inexperienced interviewer the questions I ask aren’t very good. In an effort to improve, I’m going to look at why I think the questions I ask aren’t very good and how we could improve them. Hopefully by the end we’ll have more ideas for better questions.
Poor questions are “closed”. They allow for short, even one-word, answers. They may be unanswerable for junior engineers and they won’t give senior engineers the opportunity to demonstrate the depth of their knowledge. Poor questions may seem like they demonstrate the knowledge of an engineer, but they are superficial. Unfortunately, they’re mostly what you’ll find if you look for help by Googling “Laravel interview questions”. For example;
What are the arguments for PHP’s preg_replace() method?
Is it $needle first, or $haystack? How many other arguments are there? What does it return? These things are easy to forget. Knowing methods or forgetting methods is a poor indicator of knowledge and experience. These are the things we check Google or Stack Overflow for. They are better remembered by auto-complete, or tools like Copilot. These are the type of questions you got at school, ones that tested your ability to remember things rather than your ability to solve problems.
What does your local development environment look like?
There are great engineers on MacOS, Linux and Windows. They may be using Docker, Valet, Herd, Homestead, Sail or one of many other local development tools. They might work in Visual Studio Code, PhpStorm or Sublime Text. Knowing which of these they use isn’t going to give you any idea of their knowledge or experience. At best it might tell you they’re familiar with some of the tools your team is using. A question like this might get the conversation started, but don’t rely on it to give you any great insight.
PHP is a dynamically typed language. Recently there’s been a lot of support added and movement in the community to stricter typing. What do you think of this?
It’s not quite a one-word answer, but it’s not much better than that. It’s also fairly obvious, from the wording of the question, what’s expected as the “right” answer. I have no doubt there are people out there writing PHP that think the move to stricter typing is a bad thing, but I expect they’re few and far between and would need to have a fairly strong opinion to raise that in an interview. Some additional knowledge could be demonstrated by talking about static analysis, but there’s not much scope here for an in-depth conversation.
These are the sorts of questions I’ve been asking so far. Let’s see if we can do better.
Good questions offer more scope for detail and longer answers. They might give the interviewee an opportunity to talk about some work experience they have, or why they do (or don’t) like a particular piece of technology.
Explain the Repository/Adapter/Factory/etc pattern, what it does and where it might be used.
Most engineers will know at least one or two patterns. Many books have been written about them and anybody trying to improve is likely to have tried to learn some. To appeal to the widest audience it would be good to pick one of the more common patterns. You could have a few options and pick one based on the level of the person you’re talking to. A good engineer could use this question as a jumping-off point to talk about coding to an interface rather than an implementation. Even better, they may have counter-examples where using a particular pattern may turn out to be a bad idea.
Describe the N+1 problem and how we can avoid it.
It doesn't take long working with Eloquent relationships before you hear about the N+1 problem. Most engineers have probably introduced it somewhere without noticing. The interviewee can talk about eager-loading as well as preventLazyLoading(). More senior engineers might talk about some of the trade-offs between doing this work at the database layer vs the application layer, as well as some edge-cases of eager loading.
You’ve received a feature request from the product team. Describe how you go about tackling the work and the order in which you build things.
This is a very broad question that should offer insight into how the engineer thinks and the processes they like to follow. Maybe they’ll start out describing defining the data and building migrations. Maybe they use TDD and will describe writing a failing test as their first step. If they’re used to building APIs, then maybe they’ll talk about OpenAPI and agreeing a contract with the front-end engineer they are working with.
These questions are better than our first group, but can we go a step further?
Better interview questions are open. A junior engineer will be able to answer them, but a senior engineer will be able to discuss them at length. They will cover broad areas, giving opportunities to branch off onto other subjects. They will also offer the possibility to talk about things beyond the Laravel application layer.
Can you describe the request cycle and how a request passes through our application before returning a response to the user?
One of the first acronyms you encounter when working with Laravel is “MVC”. Even someone who has just started on their journey will be able to tell you about the Model, the View, the Controller, and a little bit about how they fit together. Someone who has been working with Laravel for longer will be able to tell you about the Service Container, Form Requests and Middleware. A DevOps engineer might describe things outside the application, like how the client’s browser and our server negotiate a connection using SSL, what roles Nginx and Apache perform, or what PHP-FPM is.
Can you describe what a database index is?
Although it’s not Laravel specific, it’s a topic that somebody working on a large-scale application will have likely considered at some point. It’s also another question that gives more senior engineers scope to go into greater depth, while still giving junior engineers something they can talk about. If necessary, you could give some additional guidance, such as; how do you know which columns should be indexed? Can you describe some trade-offs with indexes, such as the impact on read and write speeds? Junior engineers might describe indexes like a phone book, where you use one ordered piece of information to find other related information. Senior engineers might talk about topics like clustering or b-trees.
Describe how we can protect our application against malicious users.
Laravel offers user registration and authentication out of the box. That gives us something even a beginner can talk about. Hopefully they’ll also understand what it means to hash a password. Beyond that they may start talking about rate-limiting or CSRF middleware, what guards are, CORS, or what XSS means and how we can prevent it. DevOps engineers might talk about web-application firewalls or third-party services like Cloudflare. We always aim for “security in depth” and there’s the potential for plenty of depth to this question.
If our application receives web-hooks from an external service, how can we ensure these are processed reliably, while potentially performing complicated logic, but still give a timely response to the service sending the web-hook?
Alright, so this one may be difficult for a junior, but it’s another question that offers a lot of scope. We could talk a little about the request cycle and what it means to return a successful response. We might then move on to discussing queued jobs and asynchronous processing with queue workers. There’s scope to talk about rate-limiting and exponential back-off. Maybe they’ll mention FIFO queues and consider whether it might be necessary to process jobs in the order they are received. We could discuss what idempotency is. There’s also more scope here for talking about security and how we can ensure we only process legitimate web-hooks, using a combination of authentication and IP white-listing.
For a junior engineer, the answers they give to these may be shorter, so you’ll need to have a few more to keep the conversation going. For more senior engineers though, these questions offer plenty of depth and allow them to demonstrate their understanding and problem solving skills.
Closed questions may not help you get a great read on someone’s experience, but they could be useful for breaking the ice and getting the conversation started.
It’s hard to generalise questions, making them suitable for both junior and senior engineers. If you’re hiring for a junior engineer then there’s no point hitting them with difficult questions about database indexes. Having a list of questions that cover a range of difficulties allows you to select those appropriate to the level of the interviewee.
Having regular questions that you ask in most (or even all) interviews will help when it comes time to compare candidates. It’s easier to see who has more experience when reviewing answers to the same question rather than asking different questions every time. Building and curating a list of awesome questions that you can use time and time again will really help.
Tailor your questions to the technology your team uses. If you’re big on Elasticsearch, Terraform or NoSQL then have some questions ready in-case the interviewee has experience with them, but be prepared that they may not know much if they’re less commonly used.
The questions you ask should reflect the type of role you’re hiring for. If you’re looking for a new engineer to join your team permanently, then “team fit” could be more important than technical knowledge. Junior engineers will pick up technical knowledge quickly, especially if they’re keen to learn, but if they don’t get on with other members of the team then that will hinder their learning. If you’re hiring for a short-term contract position then team fit is less important than technical knowledge. You want to be able to hand-off as much work for the project to the contractor as possible, reducing potential impact on the team and minimising situations where you may need to step in and help.
We all Google stuff. Rather than trying to find out what they know, the questions you ask should help you understand how they think. Knowledge can be taught, but a problem-solving mindset and a desire to learn are inherent.
Engineers on a smaller team need to be more adaptable, you want them to be comfortable diving into issues with the database, or any of the infrastructure. On larger teams their area of responsibility may be much smaller and a lack of knowledge about deploying servers wouldn't hinder their ability to write good application code.
It feels like we have an idea now of what better interview questions look like. The topics may vary from team to team, but the style of the question should lean towards being answerable to the widest audience, while giving plenty of scope for lengthy answers.
One last thing; “do you have any questions for us”? Getting questions thrown at you from left, right and centre is exhausting. Giving the interviewee a chance to ask you questions can help them get a feel if the role is right for them. If they’ve only ever worked in an office and you’re a remote team then they’re bound to have questions about how that works. They may be interested to know how big your team is and where they may fit into to. Don’t make it all one-way traffic.
Do you have any other great interview questions you like to ask? Let me know via the contact form! You can also let me know there if you want to be notified whenever I post something new. You won't get added to any fancy mailing lists, I'll just send you an e-mail.
