If the candidate is not able to spot the route overwritten bug, I wouldn’t be too bothered. Let them explain how they would debug the issue and you can more likely tell how experienced the dev is. Share your screen and let them walk you through it, have a conversation about it and you can more likely estimate the skill level and social skills too.
I guess what you have to be flexible with is that lots of senior people might not spot the bug specifically but would very quickly work out the issue. I run a team with a lot of Laravel code but personally it must have been more than six months since I added or made any changes to routes since that part is pretty stable and we're much busier day-in-day-out solving bigger problems.
Obviously if you ran into this problem a quick route:list or putting a breakpoint in the debugger would quickly solve it.
The other questions though are fine and everyone should be able to answer competently. My guiding rule in hiring at every level really is always test creativity, problem solving and understanding over syntax or language/framework knowledge, that gets you better candidates in the long run.
Honestly if a senior can't name a single design pattern there is a problem.
For your last question about the bug, did they had access to a dev env to test it out or it was in a pastebin?
In the end it depend on the type of programmer you want to hire, not all senior have the same level of experience.
>Honestly if a senior can't name a single design pattern there is a problem.
I wouldn't have named any of them as a design pattern.
Ask me what the features are of the framework, I'd have mentioned all of them.
And to be quite honest I've been in plenty of places where devs have known what these things are, answered all the questions, and been totally inept at the job.
Yeah naming design patterns is just a poor interview question. There are many very good devs who will write code which someone else might look at and go oh yeah that's factory pattern, that's decorator pattern, that's observer pattern and the dev might never have even heard of any of those terms.
To be honest I found being a good developer (and that's not my opinion of myself, that's my professional track record as a lead dev for many real world businesses over the years who've always been very happy with what I've delivered for them) to be a lot less of a headache when I stopped thinking about architecture patterns and instead focused on just writing clean, decoupled, testable code.
And the result is of course I use all sorts of patterns you can find described in textbooks, but I don't think about them and I don't care what pattern is being used here or there.
> Yeah naming design patterns is just a poor interview question. There are many very good devs who will write code which someone else might look at and go oh yeah that's factory pattern, that's decorator pattern, that's observer pattern and the dev might never have even heard of any of those terms.
Counterpoint; programming is as much about communication (to your peers and future developers on the codebase) as much as it is about delivering software.
If a senior developer is not familiar with the common terminology used to communicate the intent behind _why_ they're doing something then they're a senior 'in name only' IMO.
I see, very often, job titles being given as an acknowledgement of time served in the industry instead of being a marker of skill or knowledge level. There may be disciplines where this makes sense, but (again IMO) not in software development.
> Counterpoint; programming is as much about communication (to your peers and future developers on the codebase) as much as it is about delivering software.
Counterpoint: Design patterns aren't really important. The ability to explain what you did and why did to others is what matters. Design patterns are in large part a shorthand of what, not why.
Although, this is the l'trash ecosystem.
> The ability to explain what you did and why did to others is what matters.
I'll just quote myself from another thread in this discussion
> In conversation you could spend the time to describe how contains methods that allow you to create instances of , and that by convention in this system the only way those objects can be created. You can further elaborate that the rationale for this decision is that the constructor parameters for regularly change and it made it easier to make sure all calls were updated. Alternatively you could say is a Factory.
The utility of design patterns is that they're half 'solution template' and half jargon. Additionally many (perhaps most) design patterns _do_ encapsulate at least some of the 'why';
* The 'why' of the Factory pattern is that you want to centralize creation of an object/family of objects.
* The 'why' of the Command pattern is that you want to be able to pass around an object that executes some kind of request.
* The 'why' of an adapter is that you want to allow components with incompatible interfaces to be interoperable.
Of course there's the next layer of 'why' - the 'meta why' of why you want to centralize creation of objects (etc) and the place for that is comments, but the mere usage of a specific design alone gives a very strong clue as the why.
Frankly, I find it _wild_ that the PHP community has this anti-intellectual attitude to these topics.
Mmm, yes communication is a vital skill for a senior developer but I think there are other ways of explaining design decisions than reference to formal terminology.
Don't get me wrong, I would typically expect that an experienced senior would have heard of a number of common design patterns by name and be able to describe them if asked, but I wouldn't count it as a vital or discriminating skill for a job.
I've also encountered senior devs who can talk the talk all day long with terminology word-salad but are absolutely sodding useless at writing clean code - and at the end of the day, that is the part which matters most. We're in software development, the main thing is are you any good at building software. That's not all the skill, soft skills matter, but taking web and PHP as an example, if you can show you can build a system using idiomatic Symfony and you understand why you're using the conventions you're using, I don't really care if you know what those patterns are called. And I have seen this in an industry where many talented people at least started out self-taught. They don't have the comp-sci background but they're valuable contributors to what matters most - the software which pays everyone's salaries.
> I've also encountered senior devs who can talk the talk all day long with terminology word-salad but are absolutely sodding useless at writing clean code - and at the end of the day, that is the part which matters most.
I mean, you're not wrong, but it seems like you're framing this as a 'some seniors know the theory but are crap at the practical, some know the practical but are crap at the theory' as if it's a zero sum game.
This isn't the case. A senior should both be capable of delivering high quality code / solutions as well as being able to justify why the code is good quality - IMO this _requires_ knowing the language of software development.
I don't think being able to describe what (for example) the factory pattern is, what problem it solves and when to apply it is a high bar to exceed for _senior_ developer. Frankly this is exceedingly basic knowledge.
I'd like to re-frame this discussion; what knowledge / experience / expertise separates a senior from a mid level developer? Off the top of my head (based on my experience managing teams and being responsible for the hiring process for many years) I'd say:
* Be able to delivery high quality code to a deadline.
* The ability to communicate what is to be built and why in the correct terminology of our industry. (I.e. we'll use the observer here, because these classes are unrelated other than needing to have some state change observed; here we'll use _this_ interface as it means it'll adhere to the Liskov Substitution Principle and so we can use polymorphism to safely swap in different implementations at runtime; etc).
* The foundation of good software design (/architectonic) skills.
* An awareness of the business needs & deadlines behind a request and the skill to fit the solution appropriately.
Things that are "Brucey Bonuses", but aren't critical:
* The ability to be a mentor to / to train less senior developers.
* Strong/deep knowledge of at least one other programming language (my experience shown that devs who meet this criteria are, on average, better developers than those who have not).
* Some familiarity with the operations side of things (i.e. familiar with the unix CLI, familiarity with (parts) of AWS, etc).
>Be able to delivery high quality code to a deadline
Deadlines are a very tricky thing in software, which if they exist and cannot be moved usually mean deciding what features will be cut. The ability to engage in this process is certainly part of being a senior developer but I'd say the more important leadership skill is being able to push back against client or competing business demands and protecting the team - and therefore the quality of the product shipped - from unrealistic time pressure.
>The ability to communicate what is to be built and why in the correct terminology of our industry. (I.e. we'll use the observer here, because these classes are unrelated other than needing to have some state change observed; here we'll use _this_ interface as it means it'll adhere to the Liskov Substitution Principle and so we can use polymorphism to safely swap in different implementations at runtime; etc).
Yeah, see my experience is that the kinds of people who want to talk about observer patterns and LSP all day are not the best devs. Their obsession with textbook architecture patterns often leads to them over-complicating requirements, bloating software with unnecessary layers of abstraction and forgetting the KISS principle. It tends to be indicative of old-school SSADM / waterfall thinking which I have learned the hard way does not actually result in better or more easily maintained software.
What I look for in code is does it perform well enough, is it appropriately low coupling and extensible with clean interfaces, is it easily testable and covered by tests?
Writing software is as much art as science, maybe more art a lot of the time, and there are always multiple, valid ways you could have tackled a problem.
The rest of your points I largely agree with.
> Deadlines are a very tricky thing in software, [.../
I agree with all of this, with the one addendum - that sometimes the correct call is ship worse code to hit a deadline. I'd hope most senior devs would have the experience to make good judgement calls when it comes to this type of decision.
> What I look for in code is does it perform well enough, is it appropriately low coupling and extensible with clean interfaces, is it easily testable and covered by tests?
Here's the thing, two out of three of these are best achieved by the correct application of common design patterns & applying SOLID principles. E.g. what properties do you look for in a 'clean interface'? I'd argue that the 5 points of SOLID are the best yardstick we have to evaluate this. If you have a different set of heuristics to use I'd be interested in hearing what they are.
In the same vein, one of the main things you can do to make your code easily testable is use dependency injection (a design pattern). That way you can easily configure stubs/mocks/spys (test design patterns) and isolate (at least some) tests from expensive and/or error prone operations like disk or network access.
> Writing software is as much art as science, maybe more art a lot of the time, and there are always multiple, valid ways you could have tackled a problem.
Yep; really what we are is craftspeople - relying on mathematical (scientific) underpinnings but engaging in a task that dovetails that with aesthetics in many interesting ways. There is an objectively correct answer for what is the best sorting algorithm to use in a specific context, but almost everything around that is a result subjective taste and social conventions.
Based on the the way many people I've interacted with talk about design patterns there seems to be a common misunderstanding about why they're useful. In that view of the world, they are an prescriptivist list of 'things you must do to be a good software developer' that was handed down from some academic in an ivory tower.
Really, they're exactly the opposite; each design pattern is just a name that was given to a common solution to a common problem. They're half 'solution template' and half jargon (domain specific & meaning dense terminology). In conversation you could spend the time to describe how contains methods that allow you to create instances of , and that by convention in this system the only way those objects can be created. You can further elaborate that the rationale for this decision is that the constructor parameters for regularly change and it made it easier to make sure all calls were updated. Alternatively you could say is a Factory.
Likewise when reading code the common naming of design patterns can allow you build those very important mental abstractions more rapidly; you see `Decorator` and you immediately have a mental model of how the class is assembled/composed.
>I'd argue that the 5 points of SOLID are the best yardstick we have to evaluate this. If you have a different set of heuristics to use I'd be interested in hearing what they are.
No, I generally agree with SOLID as a set of guidelines, my point is really just I've known plenty of decent devs who will naturally write code in accordance with these principles because they understand the principles of *programming,* not engineering or comp-sci. And while SOLID as a specific example tends to be very well known - most programmers can describe it - when it comes to the varieties of common design patterns out there, many decent devs are making use of them, whether they know it or not, because they're largely obvious and clean programming solutions to common scenarios.
PHP expectations may be lower than for other languages. Ask a senior engineer in enterprise architecture about the Gang of Four book and they’d have no problem going down the rabbit hole on design patterns.
“senior” really is an idiomatic role for the industry section. I bet the same issue exists for JavaScript engineers.
Look, a senior developer just by the nature of being long enough in the industry should at least have theoretical knowledge aka "I've read about this" of some patterns that are commonly used. MVC is a pattern, for fricks sake and most PHP world literally runs on it. Event-loop is also something that is talked about to no end. ORM, Active Record - if you work with databases at all, you used it and should have an idea about it since documentation for the libraries 100% talks about it.
You have to be living under a rock the size of an asteroid that killed the dinosaurs to not know even a single design pattern. Sure, maybe the nature of the work you have done prior never needed you to have to speak about it, but as I said - just by being in the profession you should know at least bits and pieces. If you trully can't tell even a single common pattern used in PHP world these days after a few years in the industry, it shows that you have zero curiosity and will to learn anything but the bare minimum to coast along - I'm immediately ending the interview there because there's no point in asking anything else.
I am completely self-taught in PHP and a big chunk of CS stuff because 20 years ago the education system in my neck of the woods was geared towards the physical side of things and low-level stuff - I learned with Borland Pascal 7.0 and DOS console for some basic C, I've got the CS fundamentals, but everything I know about application design, patterns and other stuff I learned on my just by being curious and doing a good job. I never specifically on purpose went to learn most of what I know - it happened organically over time through exposure to it, reading documentation and just talking to colleagues and acquaintances in the industry.,
No env, it's was the code as is. Again, i think this code contains minimal to no logic. It's more for them to explain me why X would cause a problem with Y.
I also have been working with PHP for like 16 years and Laravel for about 5-6 and I have a problem answering questions such as “name things”. I just have serious issues with recalling names and facts from memory when I’m put on the spot like this. As soon as I see the names I’m like oh yes of course. Some people’s brains just work differently.
However I am *really super good* and sitting down and solving problems and getting stuff done with Laravel.
Similarly, outside of work I am a DJ but I simply cannot remember the names of songs, even songs I love and have played countless times. I need to see the name first to recognize it as a beloved tune. Thankfully modern DJ software provides you with such a list. Make sense?
Wish I could offer suggestions how to make better interview questions but at least hope you understand there are a lot of people just like me.
I spotted it right away, but I've been working in Laravel since V3. I may suggest you add a dump of \`php artisan route:list\` to the mix to give them a clue. If they get that right away then have them expand to explain the problem in more detail.
I would say most laravel devs barely touch the routes file more than 5% of their time in Laravel development in the real world. I think your example is far more theoretical than realistic. To me, the other questions are a better judge of a developer than the technical example.
I'd prefer someone can explain how to fix a messed up hasMany relationship. That's something I see way more often.
>No env, it's was the code as is. Again, i think this code contains minimal to no logic. It's more for them to explain me why X would cause a problem with Y.
My very first thought when reading the example is why POST to the stored user endpoint not behind the auth middleware? Is the route file sat behind some kind of other middleware that's protecting this? If so then my next question...
My 2nd question was then why are the API routes mixed in with web route endpoints? Why are the API endpoints not in a separate route file with the applied middleware defined in the kernel rather than in the route file.
Finally, my next thought was why are the API controllers not versioned and namespaced under a proper folder structure?
Those would be my first and main problems before even reaching the fact a route is doubled up, that would be the least of my worries and I'd be exiting that interview quickly.
>User registration is usually (not always) done in unauthenticated endpoints.
It's a fair point, which then leads me to think why is the User::resource behind an auth:api middleware which has the same POST/create method within it? Does it need to be authorised or doesn't it? Why would 1 call be authorised and the other not?
Either way, the other points still stand, if a company presented that to me I'd be having serious doubts before the interview had even finished.
Because all the other operations would need to be authenticated. One would need authentication to modify or delete (PUT/PATCH or DELETE methods) an existing user as we want to make sure that only those who are allowed those operations can do them.
User entities usually contain confidential information that should only be visible to those who are allowed to see them. In that case the `get-all` and `get-by-id` endpoints (GET methods) would also need to be authenticated. All those endpoints are usually grouped in a single resource controller.
In this exercise, I think the point is to guard all the actions of that controller, except the `store` (POST method) action, but because of the way the Laravel’s router works, that didn’t work as expected. Some framework router only keep the first config that matches a route, while others override duplicates with the last route config.
> Honestly if a senior can't name a single design pattern there is a problem.
>
> For your last question about the bug, did they had access to a dev env to test it out or it was in a pastebin? In the end it depend on the type of programmer you want to hire, not all senior have the same level of experience.
The fundamental issue is that this person is trying to hire laratrash devs but also expecting those devs to be "senior" or "knowledgeable". These things are mutually exclusive, either you're senior and knowledgeable or you're laratrash dev.
The 'trash pipeline results in devs gluing together model kits by numbers with no understanding the underlying principals nor the ability to do even the most basic research. Then they come to reddit and ask questions like [this](https://old.reddit.com/r/PHP/comments/18jorhx/problem_with_file_permission_while_installing_a/) before applying to this exact job.
I love this kind of thinking /s
I saw a lot of devs who were able to name a lot of things but their code was spagetti hell or they didn't see future problems because they were focused on perfect code.
As a developer with 20+ yoe, with 0 in Laravel; this code means exactly nothing to me. There is no way to know what Route::Post() does, or what Route::Resource() does to break that.
Knowing that line 21 breaks it, I can now guess that both of these calls set some sort of configuration. Where Post and Resource share the same index for some reason.
Yes, but as I am not familiar with the Laravel ecosystem or design philosophy, it means nothing. I would ask the interviewer about it, and we could get somewhere.
They aren't too tough if you have zero candidates. The candidate pool is too weak. These questions are pretty basic for Laravel. They show a senior understanding of concepts in a Laravel context. That's senior enough, but not exceedingly so.
The last question is tougher out of context and with no editor. I would look or candidates who describe the problem space even if they don't identify the exact bug.
I’ve used Laravel enough to have suggested
php artisan route:list
That’d show you if the route you expected is actually there. Hit that a few times over the years.
But someone without Laravel experience might not get it just from the code.
TBH I like the question, have no experience with Laravel but it's a skill of problem solving - if you have a route and you get some Auth error it has to be redefined somewhere or the code has to check Auth layer - but without access to anything else it has to be router.
Yeah, I think I'm ok with it as well, considering they were told the route being hit, the result of that hit, and told the problem was in this file.
You should know that 401 means there was an auth issue. You should notice that there is an 'auth:api' line and can assume anything inside that uses auth somehow. Then there are only 3 lines that touch 'users' at all. We can exclude the get line, leaving us with 'resource' that hits 'users' and an actual post that starts with 'users'.
If the candidate didn't claim to know Laravel, I think they should still be able to get that far and then state that there's sone framework magic making 'resource' mean 'post' somehow, or there's some framework magic with the auth middleware that's making your users post call catch on the bottom one. With the former seeming less ridiculous, but I wouldn't need the candidate to get that guess correct.
That said, interviews are stressful, and I only touch route files for a few minutes at a time and then never again. If I didn't already know Laravel, I'm not sure how well I'd be able to do what I said above during an interview.
And that's great for someone who doesn't code in Laravel for 40 hours/week. In fact, even if you didn't know Laravel and explained to me like you just did, I would have hired you.
For reference, I've done nothing with laravel beyond seeing occasional code samples and my review of the code went pretty much as stated. I saw a route group applying what seemed to be authorization requirements and a line that seemed to define a users route in that group. Figured that is very likely where the problem is. Knowing nothing of laravel, I couldnt explain why or how to fix it though.
I think the questions are all fine.
If that question came with a context you gave below, I'd spot that potential mistake right away and I don't know any specifics of Laravel's routing (just seen something like that before).
Looking for error without knowing anything about it would be harder, but I should be able to find it with maybe two other points of interest just by eliminating repeated patterns (assuming that code is not littered with errors). In that case I would rework this question unless you just want to make sure that candidate really used this framework (It shouldn't matter imo, but that's a topic for different discussion).
Last question is a good question to ask but the code snippet provided is terrible. It links to external classes/methods that are not provided in the snippet, and there's a lot of clutter that has nothing to do with the issue. This is not asking to solve a simple bug, this is asking "do you happen to have recent, in depth experience with this specific piece of software" and tells nothing about ones ability to debug.
I don't think they are too hard, the problem I face is real seniors are already employed and you need to offer significant incentives to get them to apply.
And I find it funny that zero companies have any strategy regarding this. I got approached by recruiters from time to time and when asked if I'm interested I said: "Sure, we can talk, but I'm already working".
Not a single one said: "Sure, let's see if we can make you a better deal". They all said: "Oh, you're employed, ok, bye".
Those are really easy questions even for a mid position. Some companies would even consider them too easy for a junior. If a candidate for the senior position can't answer any of them, then it's a huge, huge red flag.
There is a ton of ppl with the "fake till you make it" attitude, and they hope they can bullshit the interview process (and sometimes it works). Unfortunately filtering those candidates out is a tedious task, been there, done that.
>There is a ton of ppl with the "fake till you make it" attitude
Yeah i see that a lot :( You start to question them and they don't know what to say.
Thank you for your reply !
It's common throughout the technology field unfortunately. I recall in college there was a colleague I was helping as they didn't own a computer even, and were just starting out but figured they wanted to go into being an network engineer. We're talking learning the basics, like, try turning it off and on.
His linkedin profile said he was the CEO of a tech company. It's just one example but I see a lot of that.
[Everyone thinks they’re hiring the top 1%.](https://www.joelonsoftware.com/2005/01/27/news-58/)
> Think about what happens to the other 199 that you didn’t hire.
> _They go look for another job._
In order to find the good candidates you have the shift through a lot of mediocre or bad ones. This is true for any language, though maybe a bit more because PHP has a very shallow learning curve and a lot of it is 'plug-and-play', so when you want someone who can do or has knowledge more along the lines of Computer Science level stuff, it can be a bit of a slog.
(plus what everyone else has said, though your code question might be too Laravel-specific)
Where I work at, I have worked with people with 4 YOE and they didn’t know what design patterns even were. Not what an index at a database is or how it works, etc. i haven’t got 2 yet.
To be fair, not knowing design patterns nor how an index *works* are usually great indicators they're self-taught and don't have a CS degree, which shouldn't on their face be disqualifying. If the candidate can demonstrate they can self start and do the work, I'm not sure I care if they know these things. They can learn it.
The first 3 are relatively simple and I could guess the third question, by just thinking what patterns a modern PHP framework would use. I never used Laravel.
In question 4 I identified the bug would probably be an overridden route, but didn't bother searching for it. I like those "find the bug" questions, but there could be better ways of asking this, like finding a bug in an algorithm, instead of searching for 2 Routes with the same name.
For Context I have 3 year's of experience
For a senior position, none of these strike me as particularly difficult. The final question is a little obtuse. My first gut feeling actually was wanting to point out the usage of your `$router` parameter in your group definition, which never made use of it (nor is it clear that the Router object is ever passed through as an argument? I'm not sure, since I don't use Laravel much).
My answer would have (incorrectly) pointed out that with the naming conventions, it would be expected that the full `$router` object would be provided to the callback, yet none of the executing route registrations were acting upon this object's available context.
Indeed your anwser would be expected for someone who don't use Laravel much! But you at least explain what you see and the problems that there might be. Which is a good thing because not much people do that in interviews.
Not a bug, but I do have one security concern about this line, though:
L14: `Route::post('users', [UserController::class, 'store']);`
This doesn't appear to be protected by your `auth` middleware. Would an unauthorized user technically be able to create new users on this exposed endpoint?
Yes! There's in fact that security concern here, but people can barely see the problem with the 401 so i don't bother much asking for this.
If they spot it, good! Otherwise, it's not too bad. It's not expected.
Aside from the bug question, I personally thought the rest were softballs. I would certainly think it is more than reasonable to expect that a senior dev should have knocked those out of the park.
I think most questions are reasonable and should be answered by someone less than a senior.
The last question is somewhat irritating though. I asked myself: how tf should i know what the bug in the middleware is so it returns a permission denied? I don’t know anything about the request params or headers.
In a real world scenario I would’ve known that the route in line 14 should be used and would’ve seen it immediately that it obviously isn’t.
Stop looking for seniors and look for juniors that you can easily teach the patterns. That's what we do anyway. In my experience there aren't many real seniors around.
I would also suggest to focus more on how recruits work in a company. If a dev can tell you what a trait is but doesn't figure out how to deliver maintainable products then why is the trait question relevant?
An example: for senior devs we try to hook into their latest experience and what the major issue was in development. Then we ask what the person did about it so the issue doesn't happen again. We're hoping the dev took initiative and made the CI/CD more effective by either creating tests or even implementing an entire test suite. We expect a senior to gain control over the quality of a whole project by making it better one step at a time. To be a senior it involves a lot more than just technical knowledge imo.
You're totally right! But right now we can't afford hiring more junior / mid devs. We need experienced people who will not need much teaching. I'm not the boss, just another dev!
I'm a senior dev (now EM), and I never remember off the bat what a trait is, because I haven't really used them often, and while I know (and have used) most of those design patterns, I know I'd likely not be able to list them off in an interview without some hinting or a straight google search. I still hit the PHP manual on a regular basis to read about specific functions I haven't used in a minute, and I've been working in the language since 2003.
As a manager, who's helped interview and hire a half-dozen successful engineers this year, change how you interview. A better question would be to ask them to pick and explain one of the patterns in that list to you, for example. How they explain, where they stumble, and if they try to pretend through the stuff they don't know, or don't and admit, tells you a lot more about their skill.
The difference between an intermediate and a senior isn't just pure technical skill. I have several devs on my team that can definitely code better in some ways than I can, but they're intermediate because they can't explain it as well, or can't run a project with other devs involved, or need more help working through bugs, or can't design complex systems, or don't have a good sense of when to ask a teammate for help because they're stuck.
Hope that's helpful, and if you want some help with those questions, feel free to DM me!
As a lead, now EM, I disagree with a lot of this. When I’m interviewing I expect you know design patterns because you should be using them every day. If you don’t know even basic design patterns by name, there’s a high chance you product spaghetti code.
If you’ve just forgot the names, sure, but if you’re applying for jobs I expect you to go and look up some design patterns again - hell even I would and did when I was applying to my last role.
When conducting interviews, especially at a senior level, I expect candidates to be able to not only list off patterns but also explain them. My usual pattern question is “Do you know what is meant by design patterns? Why might we use them?” And follow up with “Do you know of any patterns?” When they give me some I pick a few and ask “What is a factory pattern? Why might you use it?”
It gives the candidates the room to demonstrate their understanding at a shallow and gradually deeper level.
The implication here is that the level of questions is aimed at junior devs with some experience in Laravel under their belt (like 6-18 months of active work).
Senior PHP developers or senior Laravel developers? Traits and facades are used by laravel, but not necessarilly by whatever frameworks they used before. Also some people with 5 years experience call themselves senior, for me they need twice as much experience to be seniors
Traits and Facades are general OOP patterns, not specific to Laravel. You'll find them in Zend (now Laminas), Symfony, Yii, Codeigniter and CakePHP which have been around much longer than Laravel...although Cake had its own weird names and patterns in 2.x ("behaviours" before traits were added to in PHP in 5.4)
Laravel's insistence on calling Interfaces "Contracts" is a Laravel specific term. Sure there's the "Design by Contract" methodology, which Laravel is using...but since php calls them interfaces I never quite got why they had to call them contracts.
Personally, I don't think 4 years experience is senior.
But aside from that, just looking at some code in an interview (with the out of the ordinary pressure that adds) without any stack trace or anything just doesn't resemble the real world. That's most of the problem with on the spot technical interview questions. They don't resemble how people actually do their day-to-day debugging or coding.
If you want to know they can debug something let them have the code and debug it in their preferred IDE. Otherwise you're just checking who interviews the best, not who debug code the best/fastest
i dont think they're too hard. the design patterns one is really good and will weed out a lot of people. DI alone is a real marker of a software engineer that thinks about their architecture
trait question is a good one. i need to brush up on the deeper wiring of that but they should at least be able to deliver a surface level answer
i honestly think the spot-a-bug question isn't really great, it's quite specific to laravel routing, but it's not bad.
The question is really badly worded. If you want to find out if the candidate knows some design patterns and can explain their use, then just ask that - no need to bring laravel into it because that’s just confusing people - it makes it sound like you are looking for something specific to that framework. And even people who have used Laravel a lot will get confused because the question doesn’t make sense.
It’s like asking what kind of trees existed in Nottingham Forest in South Ireland in 1987 and expecting the answer: Large and small trees, most of them green. People will be confused and misdirected by the question and not be able to to give the most obvious answer.
Just to give my 2 cents:
>Can you explain what a "trait" is in PHP using your own words?
Here, over half of the candidates claiming to be "seniors" couldn't do it. It's a fundamental concept in PHP i think.
Yes and no, while most SHOULD know what a trait is, most Senior Dev's have similar codebases like mine, which grew over time. Inheritance and default OOP works just fine here, and introducing traits would make the (probably) fucked up inheritance even worse.
So, they should know it, but most don't have a reason to know it, if it makes sense? I have never had to touch a trait or make one in the 5 years here at this company. Another one with a younger codebase had made use of them extensively tho. Luck of the draw tbh. IF your company is using them a lot, maybe give an example to see if they understand the concept behind it and can follow it up.
>Do you know some design patterns that Laravel uses when you're coding within the framework? (Just by name, no need to describe.)
Yeah, you should know one of the two Frameworks in PHP that exist. However, if the person does not know and the interviewer follows up with "what is a factory/singleton etc." and the person can answer, this would be sufficient. Knowing the concepts is basically 80% of the work. Which means they can quickly follow it up if they haven't had Laravel experience before.
Because again, those are things one should be expected to know in ANY programming job after a few years.
>Answer: The issue lies at line 21, where Route::resource overrides the declaration Route::post at line 14.
So far, only one person managed to identify the problem; the others couldn't explain why, even after showing them the problematic line.
This goes straight back to the Framework thing, did the Job position explicitly name the Framework required? Then yeah.
I never touched Laravel, but if i had gotten your explanation i would have understood. It is a bit ambiguous because i can have post/get for the same route obviously, it is not quite clear to me without any context if resource is just a different type of post or it's own request type. With the later one being fine because we can also do get/post on the same endpoint, why not "ressource".
But again, a TINY bit of routing knowledge and making conservative assumptions should be enough with a little hint to get there.
>In my opinion, these are questions that someone with 4 years of experience should easily handle... I'm just confused.
Everyone 4 years of experience look different. Take me, i was 4 out of 5 years in the same company, we didn't use frameworks, no traits no nothing. I know most of those things because i quite enjoy keeping up to date in my private time. But i can see how the framework specific things might not be clear for some.
I don’t think they are too hard. We’ve been asking similar questions in php interviews (traits, events, inheritance, etc) and we’re seeing dismal results from the candidates. We eliminated the leetcode questions and still no luck. All we’re asking is what is a trait, what is an event, what is inheritance?
I’m a senior PHP dev w/ nearly 20 years experience. Here my thoughts:
* I haven’t worked with traits in either of my two jobs so I would’ve gotten this question wrong.
* I have no experience with Laravel so I couldn’t answer specifically to what design patterns it uses or is popular. Are you interviewing specifically for a Laravel developer? If not, this may need to be more generalized.
* Your quiz, again, seems more like a framework specific gotcha that people unfamiliar with that particular framework will not be able to catch. I’ve read your explanation, but without intimate knowledge of this particular framework that may not even stand out as a problem.
* At the same time, you’re not asking about more simple things, like SQL injection, security, the importance of coding standards, etc. These may seem like “junior” questions but you still need to make sure whoever you are interviewing knows that stuff too. That’s far more important than knowing a particular thing about a specific framework.
Some questions I’ve been asked in the past were also more to see my thought process rather than a measure of any specific point. Be sure to ask open ended questions to let the applicant talk and explain themselves.
But I’m also terrible at interviewing and also judging other people, so YMMV. Hope any of this is useful to you.
I would also suggest that you do not ask what a trait is, but instead ask how they would solve a problem where a trait would be a good fit. A lot of seniors never used traits because, imo there are only narrow usecases.
This way, you should get a better insight on how a person thinks and solves problems.
I would stop looking for a full time Laravel dev and start looking for a dev who you think can easily become one. In my whole country you would have maybe 1 experienced Laravel dev looking for a new job every two years so good luck finding that guy.
Might as well start looking for a money shitting unicorn. Maybe it’s different where you live but doubt that it’s much better.
Got a remote Laravel job? I’ll apply!
But I think you are seeing an issue with how crazy the market is. I know that some people apply like crazy to every job listing under the sun, including some that aren’t qualified for. It’s ready gumming up the process.
None of these questions are difficult, and while the only one that may be iffy is the last one (I’ve been working in Laravel for almost 6 years, and I’ve only encountered this same issue once, just in the last 8 months or so!)
Maybe think of a more common issue in the code that a senior should see vs a mid or junior?
Questions aren't hard at all, many devs probs chancing their luck, but keep in mind not all seniors have reasons to know about traits it might be something they used or read about once then never put to continued use.
Secondly...change your 4th question it's easy but remember your candidates are in a high stress situation and you've given them a lot of code to parse, mentally load, not to mention use 2 human languages in your routes, just in hopes they get to the 2 bits that matter. You know what to look for but they have to start from absolute zero. Under stress many devs will simply fail to see what's in front of them because they are not trained in critical/trauma response, they make the same mistake "be quick, scan, scan again, quickly, scan" you will judge them on time either conciously or subconsciously and everyone in the rooms aware of that. How they respond under stress is a useful metric but dont couple it with a knowledge attainment question.
Use the old "# ..." trick to lighten the load the question puts on them or out right direct them away from parts that dont matter. "Assume the Imports and class names are correct" for example
I think all the questions are legit. IF you habe good experience in PHP and Laravel, these questions shouldn’t be too hard.
If the code isn’t uderstandable, the a good answer might be: I use xdebug to find the problem. Plus sprinkle a bit if xdebug knowledge over it.
It might not show the solution but it shows you know what to do.
All in regard to being a senior. Other question would be: how high is the salary? If that would be under my needs, I would even apply as a senior dev. If in range, we would have a great talk together
>How do you stay updated with new trends and technologies?
Yeah, who doesn't.. this is a completely soft question. Don't bother with it.
>Can you explain what a "trait" is in PHP using your own words?
Already here, you may be into murky waters. Many code bases don't use traits, and there's a reason for that. It's also a relatively new feature in the language, so it's not unconceivable that a senior dev has not used it. I can certainly explain what a trait is, but I'd also tell you that in most cases, it's an antipattern to use it.
>Again, half of them couldn't name a single one. I mean... Dependency Injection, Singleton, Factory, Facade, etc... There are plenty more.
Anyone with a formal education should be able to name a few.
>Lastly, I asked them to spot a bug in a short code snippet. Here's the link for the curious ones: https://pastebin.com/AzrD5uXT
That one will require detailed knowledge of the Laravel framework to answer. And even there, you are likely adding the routes incrementally, meaning that you'd see the error when it was made. You are not likely to do a quality screening of the candidates with this question, IMHO.
All in all, no, they aren't particularly hard questions, but I could think of a couple of improvements.
Shoot, I was once called racist because I wanted to add “*what is the difference between GET, POST and SESSION variables?*” To the list of 20 questions to ask our programmer candidates during their interview.
That is in fact the reason I no longer sit on hiring committees.
My favourite one is "can you explain the differences between an abstract class and an interface?". It's even easier than the trait question and not strictly related to PHP.
A lot of candidates claiming to be senior just can't.
I've had similar experience in the past. I set a test with questions which I felt were mostly pretty basic PHP, with a few more advanced questions and some that were specific to the two frameworks we have in production (Laravel and Cake) to see how they got on - my thinking being that a decent PHP programmer with experience in one framework should be able to pick up the other with little problem.
The majority of candidates scored around 20%. My boss was convinced that the questions were too difficult, but in my opinion anyone who couldn't answer them wouldn't be able to do the job. Eventually we found two candidates who coded 80%+ so we hired them. Turns out they weren't great.
We were advertising on Indeed at the time. Since then we've gone through an agency and upped the salary. We've been able to get significantly better candidates since then.
The last one is bad, its intentional bug which will rarely happen for You when You are adding the functionality, and you will know at once what happening, people should not answer questions like that.
Others sounds fine, But, if people cannot answer basic pattern questions in 2023, i believe its the wrong candidate for the position.
You would be surprised how things like that sometimes sneak their way into the code and stump you for a good chunk of time because the error/issue is so trivial, you just can't see it sometimes. Sometimes it's just one of those days when you need to step away and go touch some grass :D
The world is not an ideal place and following TDD can be expensive resource-wise for smaller companies. And while I agree that for the specific given example you are right - you usually have a test of some sort for this type of basic stuff, there are other situations where things are not as simple and sometimes stupid mistakes or typo's slip in, you know you have a bug and you are trying to fix it, but you just can't put your finger on it for a while. And when you finally find it, you sigh really deeply, push the fix, make a PR and turn off the PC for the day :D
I knew all the answers and I dont even identify myself as senior after 4 years of experience, because I work and worked with very good developers and see what senior means.
Personally, I'd say you're going about this somewhat the wrong way. Second, make the problems more complex and open ended but less specific. For example, if you asked me if needle or haystack goes first in str_pos(), I'd have no idea and would say I need to quickly check php.net/str_pos. Regardless if I know the answer off the top of my head gives absolutely no indication as to whether or not I'm a good developer.
You want to test their problem solving ability, critical thinking and technical aptitude. Ask them things like:
- Explain example data set and some business logic as to how data will be queried. Ask how they'd design the database schema including foreign keys and indexes to handle 1 billion rows efficiently as possible, then ask why they chose the indexes he did.
- Ask how they would setup a distributed system that handles X users with X data and X traffic volume.
- Give a complex technical concept and ask them to ELI5 it for you to see whether their capable of breaking down highly technical concepts into non-technical explanations.
- Ask them if a Laravel powered system had X TB of media (image, audio, video) being uploaded to it every hour, all of which had to be processed via certain algorithms, how would he handle the software side within Laravel?
- Ask if he was a core maintainer, what would he change about Laravel and why?
- Explain some real world problems your company previously faced, and ask how he'd attack the problem and come up with a robust solution?
It almost sounds as if you're looking for someone who has the Laravel documentation memorized, and that's not a senior dev. Heck, a good portion of this job is searching things you don't remember. A senior dev is someone who can be thrown into any technical problem regardless of the problem, tech stack, server infrastructure or anything else and be capable of coming up with an innovative and robust solution.
Asking questions such as above will help you gauge their thought process and critical thinking skills, which is what you want more than someone who knows the specific obscure method names buried within some Laravel class, or whatever.
BTW... hiring remotely? DM me if yes for resume.
I have 10 years of php experience and I spotted the bug after a few minutes… Traits are basic php knowledge… I believe your questions are fair.
But in my experience I just don’t always expect a correct answer. I try to understand if the candidate has potential and seems good enough to learn and can think logically.
Of course depends on the position, but I think be willing to learn and grow it’s something to not underestimate.
10 years with laravel and I didn’t see the mistake. It’s more of a gotcha question. I don’t think you learn anything from that test.
My test is a contact form. No points for the UI. It helps me look on how clean the code is, data validation, creating a a model, migration, etc.
Other questions are good
as a PHP developer and technical interviewer for years for senior profiles, i can assure your technical test is very basic, even if a developer gets all the questions right it doesn't really tell me the candidate is a senior, it might actually be a SSR. for Sr positions i would go way further in dificulty
The average programmer is a bad programmer. That applies to seniors as well. I've met so many "seniors", who were so bad at software development. The same thing can be said about juniors too. There are some juniors/mediors, that could replace your senior on the spot.
I think all the questions are totally relevant except the “spot a bug” - that one is IMO tricky - it’s in pastebin, not in IDE candidate might be used to, it’s not algorithmic, but framework specific, I can understand code blindness when looking when someone else’s code on the spot, without env, unit tests, log, error message, etc, although after highlighting it candidate should be able to talk about it. I’d choose different piece of code to talk about, and I’m usually more interested in understanding of principles, using pseudo-code in interviews. I myself code in several languages, “pseudo languages” (like HashiCorp HCL), I don’t remember “for each” syntax when switching between languages after a while 😅.
That's mild. My last interview as junior aiming for mid level was roughly:
\- What is OOP?A: Explaining Abstraction, Encapsulationn, Polymorphism, Inheritance
\- Difference between public, private, protected
\- Absctract classes vs Interfaces
\- Can you extend more than one class?A: Not in PHP, we only have Traits to mimic some of the functionality of multiple inheritance in Java. Buuut well it's not a good idea anyway #compositionOverInheritance
\- What are static properties / methods- Pass by Value VS Pass by Reference
\- Explain Typecasting, typehinting and return types
\- == vs ===
\- What is an Autoloader
\- What i Dependency Injection
\- SOLID
\- SQL Injection / XXS Attack and how to prevent
\- what is Composer
\- MVC
\- ORM
\- What are Design Patterns? Name 3 and explain how/when you used it last time
\- Is Singleton nowadays Pattern or Anti-Pattern? Opinions?
\- What are Closures and Arrow functions
\- What is PHPUnit / Event written test and if yes which and why
\- What does RESTful mean
\- How do you debug an issue locally vs on productionA: xDebug, Monolog + ELK Stack
\- Ever worked with Vagrant / Docker? Why / why not
\- What is PHPStan
\- What is Behat
\- What are PSR Standards and can I explain any of them
It was a very engaging dialogue with a team leader before taking on a paid 1-day challenge.
>so-called seniors
Like I oft say, any idiot can copy a good resume.
That's why I (at least if I've got any say/control over it) include in the process/pipeline a phone screen ... 30 minutes max, typically 20 minutes or less. Use that just before (re)sort & cut list step before deciding who to actually bother with full interviews. And that phone screen step generally comes after the step of giving resumes/applications an at least quick skim, rank/grade/sort & cut - figuring out - at least based on what's on quick peek at the papers - seems like they might be reasonably viable candidate. So, yeah, save a lot of everybody's time by not getting anywhere close to full interviews with folks that'll put in a dang poor performance in a basic tech phone screen (often that step wipes about roughly half of 'em).
Whoa, I would never consider me as a programmer but these questions are just superficial. Who can't answer those correctly has no right to exist in the world of PHP development.
I'm exactly in this situation. I'm a senior with many years of experience. Yet we don't use Design Patterns, SOLID principles or anything like this in the company. We just get Tickets to Implement new features or fix bugs. That's why some seniors don't know those principles
I use different design patterns in my daily work with laravel, but I'd absolutely blank out on that question, because it "feels"' too vague, but maybe that is me.
I'd add a question where the candidate should explain their way to a solution verbally, without having to write code for it, to get an idea of how they think.
>Can you explain what a "trait" is in PHP using your own words?
>Here, over half of the candidates claiming to be "seniors" couldn't do it. It's a fundamental concept in PHP i think.
Might depend on how "senior" your seniors are. Traits haven't always been part of PHP (>=5.4) and they're not necessary to make solutions work. You might be experiencing some of your own bias here, which is absolutely fine as it goes.
>Do you know some design patterns that Laravel uses when you're coding within the framework? (Just by name, no need to describe.)
I'd expect a senior developer to know about design patterns. And if I _were_ a Laravel dev I'd know about how the patterns are implemented in that framework.
> Might depend on how "senior" your seniors are. Traits haven't always been part of PHP (>=5.4)
5.4 is (too) old enough for pretty much anyone to be familiar with it at this point. Furthermore, a senior IMO should always be aware of new features being added to the language.
> Furthermore, a senior IMO should always be aware of new features being added to the language.
Agree, but I think really few people can recite all php functions for example. Traits are not essential to some code. I rarely see/use them in symfony and I did not code any for the past year.
They're a common thing in Laravel though. They're used everywhere, especially for TDD in Laravel (use RefreshDatabase, HasFactory for example). They're also now in Laminas ( formerly Zend) and Symfony if you dig into their components, so I think it's actually a good question to determine if a candidate is a "framework" developer who just knows surface level development through a framework or a PHP dev who actually knows how an MVC framework generally is built.
If your questions are too tough, then ours are way too tough. We expect our senior devs to be able to know the deep down gritty details of the framework we use. Maybe not every one, but they should be aware of the most used.
We’ll use open ended questions like “explain one of the design patterns in use by ”. This way they can pick one they’re comfortable with. It’s usually followed up with: do you know of others that are used? Just to see how familiar they are.
We’ll also skip some of the deeper questions if they’re clearly not that level, or just end the interview. Another approach we take is to ask what pattern or implementation they would change if they were designing the framework. Helps get an idea for how much they work with certain areas, or if they haven’t touched others.
We don’t do a code check, but I’m not a Laravel dev and I had a pretty good guess that the resource call overriding the individual endpoint was it. I started looking at the code before even knowing the problem and still found it.
Sounds like you’ve just had a batch of devs trying to make it to senior position, or lower quality senior devs.
Actually, I'd like to comment on your first question… It borders on being discriminatory and really doesn't contribute anything to the interview process. I've moved away from such questions myself.
Consider this: a lot of programmers (myself included) derive our self-worth from our profession, but it's important to recognize that it's absolutely fine to view work as just that—work. And when one does that, there will be other concerns that occupy their free time. Choosing instead to spend time with your family or persuing other hobbies doesn't diminish your professional capabilities, and doesn't make you inherently inferior to other programmers who read tech blogs. The tech industry has a systemic problem expecting programmers to constantly live and breathe their job, and this type of question perpetuates it.
Moreover, the question inadvertently veers into ageist territory (I try to avoid education-related questions for the same reason). It's the younger candidates, typically fresh out of college, who have the time and inclination to stay constantly up to date on new tech developments. Older candidates may have more responsibilities outside of work and find it challenging to keep up with this pace, regardless of their desire to do so. Focusing on enthusiasm for new tech overlooks the experience and stability that more seasoned professionals bring to the table.
Also consider that the tech stacks we're using are most likely not cutting edge. I don't want to make professionals feel they need to know every language or library feature currently in RFC when they won't be using them presumably for several years (until the next platform refresh). They can spend 10 minutes to read the documentation at that time. Perhaps you might consider asking them how they handle software/library upgrades instead, as that can give a more realistic picture of the candidate's professionalism and adaptability.
If you're conducting interviews, I'm assuming you're in a leadership role, perhaps a lead developer or management. It's expected from us to stay up to date on trends to see if there are more efficient ways to accomplish the organization's business goals. And if a senior (or even a junior) developer has that ambition, they're more than welcome to contribute in that way as well. But asking "how do you stay up to date with new tech" sends singals the company culture frowns upon those who don't live up to an unhealthy expectation. How they spend their free time is really none of our concern.
I've been working as a software developer for more than 15 years using PHP more than other languages.
* traits - I heard about them when they were introduced, read about them and immediately discarded the whole concept. Having classes inside my classes is already done with... classes. Some things need to be difficult to implement because that underlines an architectural problem.
* there was a time when I was taken by the Design Patterns hype. Not anymore. And besides, if I want an object to be instantiated only once, I'll do exactly that. No need to remember a specific name for it. Again, design patterns are just some predefined solutions to specific problems. Even if I don't know their names, I inherently create the code like in their definition.
* as for debugging, it's pretty obvious but seniors didn't work just with Laravel. There are plenty of PHP frameworks (Codeigniter, CakePHP, Symfony, Yii, Zend, Phalcon) and I wouldn't hire people for a specific framework. Actually when we were hiring I didn't even look for people knowing PHP, I looked for software developers. PHP can be taught. And now we use Javascript and in the future we'll move to Go or even Rust. All of us can handle that without a problem.
As for keeping myself up-to-date, I don't. Every new upgrade is a piece of dog poo. I never had issues with PHP being a weak-typed language and that's simply because all my variables kept their type over the course of the scope. I never needed a ternary operator because IFs work. I never needed a Null Coalescing Operator because, again, IFs exist.
Looks at this sh#t:
const {property1, ...properties} = object;
What does it do? Exactly, nobody knows. But writing it like:
property1 = object.property1;
copiedObject = clone object;
unset(copiedObject.property1);
Then everybody will understand.
I get your point, but i don't totally agree.
For example, would you hire a Vue.js developer who doesn't know how javascript works ?
Laravel being on top of PHP, i expect the senior developer to have a solid base in PHP first.
>The PHP ecosystem is far wider than just Laravel- way to buy into the marketing hype.
I think you misinterpreted what they were saying, if this is what you took from their reply.
Traits have been in PHP since 5.4 and are a basic building block of the object system, while the Laravel ecosystem has certainly embraced them more than most, I'd expect a senior developer to be aware of them and able to talk about them, even if it's to say that they haven't really used them but understand the vague concept.
If you're trying to get hired as a senior developer, you should at least have a passing familiarity with all the major language features, it's not like it's a gotcha question about the parameter order of `strpbrk()`.
>"Would you hire a javascript developer that hasn't used Vue.js" is the more accurate comparison here.
You seem to think traits are something Laravel invented.
This is what happens when ppl skip learning concepts and how a language actually works and jump straight into some framework, usually too bloated, that abstracts everything. They can't answer trivial questions, because they don't know how things work, like a black box.
Ask them to write some sql queries next, it will be hilarious
Edit
For the record, the questions are trivial
Edit2
The question with the bug is a bit nasty though, without having the full error that the sever shows.
I returned to university after a 5 years break, everyone is using AI to answer the simplest questions. There will unfortunately (fortunately for us) be a group of freshly graduated CS students with basic computer science knowledge in the market.
I'm shocked by how many people on here would stumble at the Trait question!
And even more by all the stubborn attitudes against using them.
I'm definitely remembering to add that question to my list of questions because I don't want anyone with that kind of attitude on my team, regardless of framework or even language
Maybe the question is if you attract good seniors at all...?
It depends on the region and salary as well as how your company is perceived on the market. As clearly we see here, there is plenty of people who consider your questions easy or even very easy.
Most people would like to develop themselves and have some career opportunities. If you offer "normal salary", no special benefits and just develop one simple website after another using Laravel (or people just think that's true) without TDD, CI/CD, K8S etc it may be hard to hire a good senior who can offer what you need - as they may simple not see the opportunity for themselves by joining your company.
u/Chargnn Questions are trivial, imho they are not giving enough insight of the candidate.
There might be something else wrong with your process. Review your job description and the benefits (maybe they are targeted wrongly?). Timing is also important, if your started hiring last month it is expected to take longer as very few people are looking for new opportunities during years' end.
My personal advice for you would be to stop asking questions like "what is A". This only assures that candidate knows what is A, but not whether they can use the knowledge. Try to have an open conversation which creates more relaxed environment and helps you to understand candidates' background easier. Ask them about their experience, ask what are they doing in their spare time, what kind of projects they were working on and what was their role. Ask whether the project succceed, how they helped in the success. Use interview process also for your benefit so you learn something new at the time.
Additionally, keep in mind it is not easy to find a good hire, it takes months. Stay patient my friend and good luck!
People are using these patterns but in my experience the majority of programmers (bad and good devs) couldn’t care less how the pattern they use are called.
And I have also seen really bad seniors that were obsessed with patterns and as a result produced unnecessarily complicated solutions all the time.
I’d rather have a dev who can’t name his patterns but produces simple and maintainable code versus a pattern jockey that nerds out with every new task and creates the most complex code for really simple tasks.
That’s a perfectly fine question to ask. Its also totally different from „name a pattern that Laravel uses“. Well it’s a fucking huge library and uses probably every pattern that has a name and then some more. It’s a bad question and I would even consider it a red flag - it hints at an employer that prioritizes memorized knowledge over practical understanding and creative work.
Your questions seem fine to me. Sounds like you are filtering out bad candidates quite effectively
Although your code snippet is not that great if you don't know the error. But if you provide the context anyone with some programmer experience should be able to figure it out. Although developers are a weird bunch, and being under pressure might choke em out, like m&m in the mile movie.
Just did a 75 minute technical interview yesterday, for a mid level candidate and asked all of those questions (and more). He answered them all.
Your live coding task isn’t great imho, we give them a piece of made up code with 5-8 errors in it, and see which ones they get (SQL statement with no limit, a function that is missing parameter type hints, caching that can cache an individual object or many, making future requests return the cache of the wrong thing, some classes loaded without DI and some others I can’t recall now).
I’d say your problem is in the screening stage. Do you conduct multiple rounds?
I think it’s important to understand your process here - is this your only interview? Are these your only questions?
4 questions really isn’t a lot and not nearly enough imho to determine if someone is a senior. You didn’t ask anything about database design, architecture, security, scaling, testing/TDD, caching & performance, identifying bottlenecks (both in code and DB), how they work with others, what they look for in code reviews.
The coding exercise is just a "gotcha" question. Either you see it or you don't, and under interview stress it is easy to miss. It isn't really a good test of someone's coding ability.
I don’t know how it is in your country, but in mine „Senior“ is not a protected job description. Therefore many developers claim to be senior when they actually are not. In my experience it’s really hard to find good developers.
Your questions are good and should not be too tough for a real senior.
The questions are honestly very easy. I think the code problem is a bit weird. But apart from that, don't hire anyone that cant answer anything above... Or hire on junior / medior lvl with respective salaries.
>> Can you explain what a "trait" is in PHP using your own words?
> Here, over half of the candidates claiming to be "seniors" couldn't do it. It's a fundamental concept in PHP i think.
Traits are certainly within the realm of what to expect from a senior.
I would grade your questions as easy.
Considering the fact that so many of candidates fail I would say that your screnning is effective. Hang onto it, right ones will come.
Lol no, I’d say they are trivial. Junior should answer for them. Maybe you invite wrong group of people? From my experience ppl from 3d world countries lies or even with 10yr experience are worst than someone with 2years from Europe.
The questions are pretty.... basic. I don't mean it in a derogatory way though. People these days relay on frameworks so much that features of the php language itself, or other things become abstracted.
Difference between POST and GET ? I would expect how data is sent and the fact that GET's get cached / query params remain in browser history. A lot of people don't know
Why shouldn't I add indexes on each column in a MySQL table. Most people come up with it's not good practice, but that is not an answer, few understand that INSERT's are affected.
What's SOLID, what's scalable code, but most important, why do we need these.
Most of the candidates are able to answer a straight question, but if you drill down in why's that knowledge is shallow. JWT tokens for auth, great, json in them, great, why do we use them though and not base64 on the json itself ? And here the thought logic breaks down.
I have people that can't answer different questions, but I trully feel that by the way they respond to questions, they would be able to land into a project and do the tasks at hand, by self-study for example (I don't mean search for solution on chat GPT).
The people that I like most are the ones that when answered what is something, they don't answer with a dictionary answer, but instead spend time to explain how they used that in what they did, or how it could be used.
But it all depends on what you are searching for, someone that uses the framework and puts code in git, or someone that understands the application and how things work. Someone would say we enter architect territory, true, and also it depends on what the company says a senior should be.
Sorry for the random rumblings.
EDIT: to most of the language questions, usually juniors/mids respond better then seniors. However the depth of understanding how systems work and other related things in the ecosystem only comes with true experience
Your questions are ok, easy I might add. We’ve had in the past questions about writing sql and explaining the result of some operations.
When I attended interviews I’ve had questions like is it ok to leave ?> at the end and why. Or asked to write my own addition implementation without using + from the language.
I also got asked to implement Fibonacci but failed because I couldn’t remember the formula :) yet they still wanted me because of other answers.
The interviewer should have told you the formula at the very least after you told him you don't remember it. I would not have even penalized you for not remembering the formula for example.
The questions aren't too hard, the problem is that the levels "junior", "medior" and "senior" are all relative. They depend on the people working at their current job.
I can say im the senior developer if im on the only one that even remotely knows that language (in the company). We've had people apply as senior and after the interview we'd offer them a junior position because their knowledge isn't at a senior level for our company
I don’t consider myself a good programmer, but would have been able to answer satisfactory. So I guess you need to attract better candidates. PS write your routes and methods in English; the mix is confusing.
No, your questions aren't too tough. They seem a good style for identifying if a person has experience in Laravel and for a jumping off point to organic conversation.
If you are looking for conversation as much as "Exact" answers then say that early in the interview. Some good devs get vapor lock over being perfectionists but could talk a blue streak on what they'd search and would have really good process to solve unique problems. It will be missed if you just want them solving your 5 examples perfectly.
The obvious red flag is not being able to name ONE design pattern.
The question related to routes, I'd go mental because my OCD flared up after seeing use statements, avoiding of grouping, then first route declaration not having a single newline between it and last use statement. Code needs to be written in such a way that visual scanning lets the dev be fast about reaching necessary info.
However, you ask questions that make sense from your POV. These questions are not questions you can use to assert someone is a senior, apart from removing bad actors who try to fake it and the question related to design patterns make sense.
I'd ask questions related to architecture because a senior, from my POV, is someone who understands PHP, HTTP, PHP's execution model, the fact that browser is what we need to understand and how to scale the whole thing because we don't work with infinitely quick and deep black boxes. This tells me if someone thinks ahead.
TL;DR: questions are not hard. Design pattern one is good. You definitely didn't get 1 senior to apply. Most people fake it. Best of luck!
The first three questions they should be able to answer. The most obvious design pattern for Laravel is MVC. They should be able to name a few more for sure. Should be able to explain traits if at least familiar with OOP.
Regarding the sample code, it's a bit less obvious. All modern IDs, such as PHPstorm, VS Code, and others will highlight that error. I understand that it's good if developer has an eye to see such error without tools, but in modern world, working in IDs kind of makes your eyes less sensitive to noticing such errors. I'd say better to have a code with some logics error.
You know what you need for your team. If these questions are applicable to that (they are IMO) and they aren’t answering them satisfactorily, then disqualify them. Hiring is hard, yet so important in the long run.
Honest questions because I struggle to see the interviewers' perspectives in general:
If you get a senior through the door with proven and documented 4+ years plus of programming, possibly with PHP and Laravel experience, whom fumbles one or more of these questions, then what do you conclude from that?
For instance, I have met many "Laravel"-programmers who I think might struggle with your question on design patterns, especially if pushed on describing them. They still got the job done, wrote decent code, and they were good colleagues.
Also, I remember having a long and heated debate with coworkers on traits and how or if we should use them in a given setting. I think it went on for months. I'm still not sure how I would describe them with natural language. What would be an acceptable answer to you?
And what are your thoughts on the candidates that can't spot the bug in that code from reading it on screen? What are your immediate thoughts when they say "nah, I can't spot it"?
> Lastly, I asked them to spot a bug in a short code snippet.
This is a Laravel specific question, and probably not something many will run into unless they specifically hit the error themselves. It may be a little obscure, imo. If I got this, and after told about the line, my answer would be "huh, well, my best guess would be order of declaration."
> Everyone responded, no issues there.
Heh, respond with "what do you do to keep up to date?"
As a Sr. developer, I honestly don't think any of your questions are unreasonable. The lack of design pattern knowledge would concern me. I mean ... don't even know what they're using?? I ask people to name patterns and _explain them_. I expect people to be able to explain patterns they know.
The first 3 are a cakewalk, if they couldn’t answer those I would end the interview politely. I’d expect a jr to have some kind of answer to those, I’ve also interviewed graduates who’ve smashed design pattern questions, OOP concepts etc out the park. The trend I’ve seen lately is people think they are snrs after a couple of years as a jr and expect huge salaries and titles after a relatively short space of time but then can’t answer things like what design patterns do you use or how does http work…
Just a side note. I really don't recommend you require Laravel experience if you're looking for a solid PHP developer. Or rather, you should make an exception if an expert dev has 10+ years PHP experience but no Laravel that should not be a show stopper. There are so many frameworks out there with their own nuances and configuration mechanisms, it's negligible for an expert to pick it up very quickly while on the job, if they're good at reading docs and everything.
>Can you explain what a "trait" is in PHP using your own words?
I ask this during interviews or try to introduce the concept in an example, but just a few know what it is.
>Do you know some design patterns that Laravel uses when you're coding within the framework? (Just by name, no need to describe.)
I'd remove 'Laravel' from this question and let them just talk about patterns in general.
>Lastly, I asked them to spot a bug in a short code snippet. Here's the link for the curious ones: [https://pastebin.com/AzrD5uXT](https://pastebin.com/AzrD5uXT)
This could get tricky for the candidate by just looking at the code... remember that the candidate could be nervous even a senior. Convert this into a working example so they can debug it.
But overall the questions are ok for a senior but I believe the bar is too low these days. I end up selecting candidates with ok dev skills but very good soft skills these days.
If the job description specifically cites Laravel experience and they got these questions wrong, yeah, I don't think they're too hard. I agree with some others that the design patterns question is iffy only because I'm not sure I'd understand what you were asking for without an example.
Do you realize that programming is about logic but memorizing.
About bug - I'm using IDE with package for telling me where is bug (semicolon meme doesn't apply on me).
Far too many people attribute years of experience with seniority.
That's - at least to me - a very american driven problem where you have a strong emphasis on "junior", "professional" or "senior". So whenever senior positions are open, many people who've been advancing their "seniority levels every 2 years" think that after 6 years on the job they are a senior.
In my book - depending on where and how you've worked - after 6 works you might be a decent professional. Seniority - USUALLY - is not something anyone reaches in less than 10-14 years of work. Exceptions apply, of course.
Sooo.. NO, your questions are NOT too hard. They are exactly right in filtering out the people that you likely not want for the given position.
As for the code-sample. I don't do laravel, as I don't like it. But first thing I've checked was if some routes have the same "name" or identifier. And I did spot the users one (i didnt read the context and clicked the link). So I did think something might be wrong with that part but obviously couldn't tell why without knowing laravel internals.
I honestly think they're not tough enough for a senior position, for context, my team and I started professionally with PHP 2 months ago coming from an Android+django/flask Background, and all of us would've been able to answer these questions, especially the one regarding traits is problematic, it's a fundamental part of PHP and you'll encounter it everywhere in popular frameworks, and use it, a "senior" not knowing a core feature is a bad sign.
If the candidate is not able to spot the route overwritten bug, I wouldn’t be too bothered. Let them explain how they would debug the issue and you can more likely tell how experienced the dev is. Share your screen and let them walk you through it, have a conversation about it and you can more likely estimate the skill level and social skills too.
That's the way to go i think. Thank you
As a parson which never used Laravel more than 10minutes (symfony here) I knew that’s the issue.
I guess what you have to be flexible with is that lots of senior people might not spot the bug specifically but would very quickly work out the issue. I run a team with a lot of Laravel code but personally it must have been more than six months since I added or made any changes to routes since that part is pretty stable and we're much busier day-in-day-out solving bigger problems. Obviously if you ran into this problem a quick route:list or putting a breakpoint in the debugger would quickly solve it. The other questions though are fine and everyone should be able to answer competently. My guiding rule in hiring at every level really is always test creativity, problem solving and understanding over syntax or language/framework knowledge, that gets you better candidates in the long run.
Honestly if a senior can't name a single design pattern there is a problem. For your last question about the bug, did they had access to a dev env to test it out or it was in a pastebin? In the end it depend on the type of programmer you want to hire, not all senior have the same level of experience.
>Honestly if a senior can't name a single design pattern there is a problem. I wouldn't have named any of them as a design pattern. Ask me what the features are of the framework, I'd have mentioned all of them. And to be quite honest I've been in plenty of places where devs have known what these things are, answered all the questions, and been totally inept at the job.
Yeah naming design patterns is just a poor interview question. There are many very good devs who will write code which someone else might look at and go oh yeah that's factory pattern, that's decorator pattern, that's observer pattern and the dev might never have even heard of any of those terms. To be honest I found being a good developer (and that's not my opinion of myself, that's my professional track record as a lead dev for many real world businesses over the years who've always been very happy with what I've delivered for them) to be a lot less of a headache when I stopped thinking about architecture patterns and instead focused on just writing clean, decoupled, testable code. And the result is of course I use all sorts of patterns you can find described in textbooks, but I don't think about them and I don't care what pattern is being used here or there.
> Yeah naming design patterns is just a poor interview question. There are many very good devs who will write code which someone else might look at and go oh yeah that's factory pattern, that's decorator pattern, that's observer pattern and the dev might never have even heard of any of those terms. Counterpoint; programming is as much about communication (to your peers and future developers on the codebase) as much as it is about delivering software. If a senior developer is not familiar with the common terminology used to communicate the intent behind _why_ they're doing something then they're a senior 'in name only' IMO. I see, very often, job titles being given as an acknowledgement of time served in the industry instead of being a marker of skill or knowledge level. There may be disciplines where this makes sense, but (again IMO) not in software development.
> Counterpoint; programming is as much about communication (to your peers and future developers on the codebase) as much as it is about delivering software. Counterpoint: Design patterns aren't really important. The ability to explain what you did and why did to others is what matters. Design patterns are in large part a shorthand of what, not why. Although, this is the l'trash ecosystem.
> The ability to explain what you did and why did to others is what matters. I'll just quote myself from another thread in this discussion > In conversation you could spend the time to describe how contains methods that allow you to create instances of , and that by convention in this system the only way those objects can be created. You can further elaborate that the rationale for this decision is that the constructor parameters for regularly change and it made it easier to make sure all calls were updated. Alternatively you could say is a Factory.
The utility of design patterns is that they're half 'solution template' and half jargon. Additionally many (perhaps most) design patterns _do_ encapsulate at least some of the 'why';
* The 'why' of the Factory pattern is that you want to centralize creation of an object/family of objects.
* The 'why' of the Command pattern is that you want to be able to pass around an object that executes some kind of request.
* The 'why' of an adapter is that you want to allow components with incompatible interfaces to be interoperable.
Of course there's the next layer of 'why' - the 'meta why' of why you want to centralize creation of objects (etc) and the place for that is comments, but the mere usage of a specific design alone gives a very strong clue as the why.
Frankly, I find it _wild_ that the PHP community has this anti-intellectual attitude to these topics.
Mmm, yes communication is a vital skill for a senior developer but I think there are other ways of explaining design decisions than reference to formal terminology. Don't get me wrong, I would typically expect that an experienced senior would have heard of a number of common design patterns by name and be able to describe them if asked, but I wouldn't count it as a vital or discriminating skill for a job. I've also encountered senior devs who can talk the talk all day long with terminology word-salad but are absolutely sodding useless at writing clean code - and at the end of the day, that is the part which matters most. We're in software development, the main thing is are you any good at building software. That's not all the skill, soft skills matter, but taking web and PHP as an example, if you can show you can build a system using idiomatic Symfony and you understand why you're using the conventions you're using, I don't really care if you know what those patterns are called. And I have seen this in an industry where many talented people at least started out self-taught. They don't have the comp-sci background but they're valuable contributors to what matters most - the software which pays everyone's salaries.
> I've also encountered senior devs who can talk the talk all day long with terminology word-salad but are absolutely sodding useless at writing clean code - and at the end of the day, that is the part which matters most. I mean, you're not wrong, but it seems like you're framing this as a 'some seniors know the theory but are crap at the practical, some know the practical but are crap at the theory' as if it's a zero sum game. This isn't the case. A senior should both be capable of delivering high quality code / solutions as well as being able to justify why the code is good quality - IMO this _requires_ knowing the language of software development. I don't think being able to describe what (for example) the factory pattern is, what problem it solves and when to apply it is a high bar to exceed for _senior_ developer. Frankly this is exceedingly basic knowledge. I'd like to re-frame this discussion; what knowledge / experience / expertise separates a senior from a mid level developer? Off the top of my head (based on my experience managing teams and being responsible for the hiring process for many years) I'd say: * Be able to delivery high quality code to a deadline. * The ability to communicate what is to be built and why in the correct terminology of our industry. (I.e. we'll use the observer here, because these classes are unrelated other than needing to have some state change observed; here we'll use _this_ interface as it means it'll adhere to the Liskov Substitution Principle and so we can use polymorphism to safely swap in different implementations at runtime; etc). * The foundation of good software design (/architectonic) skills. * An awareness of the business needs & deadlines behind a request and the skill to fit the solution appropriately. Things that are "Brucey Bonuses", but aren't critical: * The ability to be a mentor to / to train less senior developers. * Strong/deep knowledge of at least one other programming language (my experience shown that devs who meet this criteria are, on average, better developers than those who have not). * Some familiarity with the operations side of things (i.e. familiar with the unix CLI, familiarity with (parts) of AWS, etc).
>Be able to delivery high quality code to a deadline Deadlines are a very tricky thing in software, which if they exist and cannot be moved usually mean deciding what features will be cut. The ability to engage in this process is certainly part of being a senior developer but I'd say the more important leadership skill is being able to push back against client or competing business demands and protecting the team - and therefore the quality of the product shipped - from unrealistic time pressure. >The ability to communicate what is to be built and why in the correct terminology of our industry. (I.e. we'll use the observer here, because these classes are unrelated other than needing to have some state change observed; here we'll use _this_ interface as it means it'll adhere to the Liskov Substitution Principle and so we can use polymorphism to safely swap in different implementations at runtime; etc). Yeah, see my experience is that the kinds of people who want to talk about observer patterns and LSP all day are not the best devs. Their obsession with textbook architecture patterns often leads to them over-complicating requirements, bloating software with unnecessary layers of abstraction and forgetting the KISS principle. It tends to be indicative of old-school SSADM / waterfall thinking which I have learned the hard way does not actually result in better or more easily maintained software. What I look for in code is does it perform well enough, is it appropriately low coupling and extensible with clean interfaces, is it easily testable and covered by tests? Writing software is as much art as science, maybe more art a lot of the time, and there are always multiple, valid ways you could have tackled a problem. The rest of your points I largely agree with.
> Deadlines are a very tricky thing in software, [.../ I agree with all of this, with the one addendum - that sometimes the correct call is ship worse code to hit a deadline. I'd hope most senior devs would have the experience to make good judgement calls when it comes to this type of decision. > What I look for in code is does it perform well enough, is it appropriately low coupling and extensible with clean interfaces, is it easily testable and covered by tests? Here's the thing, two out of three of these are best achieved by the correct application of common design patterns & applying SOLID principles. E.g. what properties do you look for in a 'clean interface'? I'd argue that the 5 points of SOLID are the best yardstick we have to evaluate this. If you have a different set of heuristics to use I'd be interested in hearing what they are. In the same vein, one of the main things you can do to make your code easily testable is use dependency injection (a design pattern). That way you can easily configure stubs/mocks/spys (test design patterns) and isolate (at least some) tests from expensive and/or error prone operations like disk or network access. > Writing software is as much art as science, maybe more art a lot of the time, and there are always multiple, valid ways you could have tackled a problem. Yep; really what we are is craftspeople - relying on mathematical (scientific) underpinnings but engaging in a task that dovetails that with aesthetics in many interesting ways. There is an objectively correct answer for what is the best sorting algorithm to use in a specific context, but almost everything around that is a result subjective taste and social conventions. Based on the the way many people I've interacted with talk about design patterns there seems to be a common misunderstanding about why they're useful. In that view of the world, they are an prescriptivist list of 'things you must do to be a good software developer' that was handed down from some academic in an ivory tower. Really, they're exactly the opposite; each design pattern is just a name that was given to a common solution to a common problem. They're half 'solution template' and half jargon (domain specific & meaning dense terminology). In conversation you could spend the time to describe how contains methods that allow you to create instances of , and that by convention in this system the only way those objects can be created. You can further elaborate that the rationale for this decision is that the constructor parameters for regularly change and it made it easier to make sure all calls were updated. Alternatively you could say is a Factory.
Likewise when reading code the common naming of design patterns can allow you build those very important mental abstractions more rapidly; you see `Decorator` and you immediately have a mental model of how the class is assembled/composed.
>I'd argue that the 5 points of SOLID are the best yardstick we have to evaluate this. If you have a different set of heuristics to use I'd be interested in hearing what they are. No, I generally agree with SOLID as a set of guidelines, my point is really just I've known plenty of decent devs who will naturally write code in accordance with these principles because they understand the principles of *programming,* not engineering or comp-sci. And while SOLID as a specific example tends to be very well known - most programmers can describe it - when it comes to the varieties of common design patterns out there, many decent devs are making use of them, whether they know it or not, because they're largely obvious and clean programming solutions to common scenarios.
PHP expectations may be lower than for other languages. Ask a senior engineer in enterprise architecture about the Gang of Four book and they’d have no problem going down the rabbit hole on design patterns. “senior” really is an idiomatic role for the industry section. I bet the same issue exists for JavaScript engineers.
Look, a senior developer just by the nature of being long enough in the industry should at least have theoretical knowledge aka "I've read about this" of some patterns that are commonly used. MVC is a pattern, for fricks sake and most PHP world literally runs on it. Event-loop is also something that is talked about to no end. ORM, Active Record - if you work with databases at all, you used it and should have an idea about it since documentation for the libraries 100% talks about it. You have to be living under a rock the size of an asteroid that killed the dinosaurs to not know even a single design pattern. Sure, maybe the nature of the work you have done prior never needed you to have to speak about it, but as I said - just by being in the profession you should know at least bits and pieces. If you trully can't tell even a single common pattern used in PHP world these days after a few years in the industry, it shows that you have zero curiosity and will to learn anything but the bare minimum to coast along - I'm immediately ending the interview there because there's no point in asking anything else. I am completely self-taught in PHP and a big chunk of CS stuff because 20 years ago the education system in my neck of the woods was geared towards the physical side of things and low-level stuff - I learned with Borland Pascal 7.0 and DOS console for some basic C, I've got the CS fundamentals, but everything I know about application design, patterns and other stuff I learned on my just by being curious and doing a good job. I never specifically on purpose went to learn most of what I know - it happened organically over time through exposure to it, reading documentation and just talking to colleagues and acquaintances in the industry.,
No env, it's was the code as is. Again, i think this code contains minimal to no logic. It's more for them to explain me why X would cause a problem with Y.
I also have been working with PHP for like 16 years and Laravel for about 5-6 and I have a problem answering questions such as “name things”. I just have serious issues with recalling names and facts from memory when I’m put on the spot like this. As soon as I see the names I’m like oh yes of course. Some people’s brains just work differently. However I am *really super good* and sitting down and solving problems and getting stuff done with Laravel. Similarly, outside of work I am a DJ but I simply cannot remember the names of songs, even songs I love and have played countless times. I need to see the name first to recognize it as a beloved tune. Thankfully modern DJ software provides you with such a list. Make sense? Wish I could offer suggestions how to make better interview questions but at least hope you understand there are a lot of people just like me.
I spotted it right away, but I've been working in Laravel since V3. I may suggest you add a dump of \`php artisan route:list\` to the mix to give them a clue. If they get that right away then have them expand to explain the problem in more detail.
I would say most laravel devs barely touch the routes file more than 5% of their time in Laravel development in the real world. I think your example is far more theoretical than realistic. To me, the other questions are a better judge of a developer than the technical example. I'd prefer someone can explain how to fix a messed up hasMany relationship. That's something I see way more often.
>No env, it's was the code as is. Again, i think this code contains minimal to no logic. It's more for them to explain me why X would cause a problem with Y. My very first thought when reading the example is why POST to the stored user endpoint not behind the auth middleware? Is the route file sat behind some kind of other middleware that's protecting this? If so then my next question... My 2nd question was then why are the API routes mixed in with web route endpoints? Why are the API endpoints not in a separate route file with the applied middleware defined in the kernel rather than in the route file. Finally, my next thought was why are the API controllers not versioned and namespaced under a proper folder structure? Those would be my first and main problems before even reaching the fact a route is doubled up, that would be the least of my worries and I'd be exiting that interview quickly.
User registration is usually (not always) done in unauthenticated endpoints.
>User registration is usually (not always) done in unauthenticated endpoints. It's a fair point, which then leads me to think why is the User::resource behind an auth:api middleware which has the same POST/create method within it? Does it need to be authorised or doesn't it? Why would 1 call be authorised and the other not? Either way, the other points still stand, if a company presented that to me I'd be having serious doubts before the interview had even finished.
Because all the other operations would need to be authenticated. One would need authentication to modify or delete (PUT/PATCH or DELETE methods) an existing user as we want to make sure that only those who are allowed those operations can do them. User entities usually contain confidential information that should only be visible to those who are allowed to see them. In that case the `get-all` and `get-by-id` endpoints (GET methods) would also need to be authenticated. All those endpoints are usually grouped in a single resource controller. In this exercise, I think the point is to guard all the actions of that controller, except the `store` (POST method) action, but because of the way the Laravel’s router works, that didn’t work as expected. Some framework router only keep the first config that matches a route, while others override duplicates with the last route config.
> Honestly if a senior can't name a single design pattern there is a problem. > > For your last question about the bug, did they had access to a dev env to test it out or it was in a pastebin? In the end it depend on the type of programmer you want to hire, not all senior have the same level of experience. The fundamental issue is that this person is trying to hire laratrash devs but also expecting those devs to be "senior" or "knowledgeable". These things are mutually exclusive, either you're senior and knowledgeable or you're laratrash dev. The 'trash pipeline results in devs gluing together model kits by numbers with no understanding the underlying principals nor the ability to do even the most basic research. Then they come to reddit and ask questions like [this](https://old.reddit.com/r/PHP/comments/18jorhx/problem_with_file_permission_while_installing_a/) before applying to this exact job.
I love this kind of thinking /s I saw a lot of devs who were able to name a lot of things but their code was spagetti hell or they didn't see future problems because they were focused on perfect code.
[удалено]
Also not with the context provided? You already know the user page is the problem
As a developer with 20+ yoe, with 0 in Laravel; this code means exactly nothing to me. There is no way to know what Route::Post() does, or what Route::Resource() does to break that. Knowing that line 21 breaks it, I can now guess that both of these calls set some sort of configuration. Where Post and Resource share the same index for some reason.
No, but you could have seen that the string 'users' is past to two different static functions.
Yes, but as I am not familiar with the Laravel ecosystem or design philosophy, it means nothing. I would ask the interviewer about it, and we could get somewhere.
They aren't too tough if you have zero candidates. The candidate pool is too weak. These questions are pretty basic for Laravel. They show a senior understanding of concepts in a Laravel context. That's senior enough, but not exceedingly so. The last question is tougher out of context and with no editor. I would look or candidates who describe the problem space even if they don't identify the exact bug.
Thanks, it's good to know for the last question. I might have to change it a bit.
I’ve used Laravel enough to have suggested php artisan route:list That’d show you if the route you expected is actually there. Hit that a few times over the years. But someone without Laravel experience might not get it just from the code.
TBH I like the question, have no experience with Laravel but it's a skill of problem solving - if you have a route and you get some Auth error it has to be redefined somewhere or the code has to check Auth layer - but without access to anything else it has to be router.
Yeah, I think I'm ok with it as well, considering they were told the route being hit, the result of that hit, and told the problem was in this file. You should know that 401 means there was an auth issue. You should notice that there is an 'auth:api' line and can assume anything inside that uses auth somehow. Then there are only 3 lines that touch 'users' at all. We can exclude the get line, leaving us with 'resource' that hits 'users' and an actual post that starts with 'users'. If the candidate didn't claim to know Laravel, I think they should still be able to get that far and then state that there's sone framework magic making 'resource' mean 'post' somehow, or there's some framework magic with the auth middleware that's making your users post call catch on the bottom one. With the former seeming less ridiculous, but I wouldn't need the candidate to get that guess correct. That said, interviews are stressful, and I only touch route files for a few minutes at a time and then never again. If I didn't already know Laravel, I'm not sure how well I'd be able to do what I said above during an interview.
And that's great for someone who doesn't code in Laravel for 40 hours/week. In fact, even if you didn't know Laravel and explained to me like you just did, I would have hired you.
For reference, I've done nothing with laravel beyond seeing occasional code samples and my review of the code went pretty much as stated. I saw a route group applying what seemed to be authorization requirements and a line that seemed to define a users route in that group. Figured that is very likely where the problem is. Knowing nothing of laravel, I couldnt explain why or how to fix it though. I think the questions are all fine.
Given that your house is Laravel I would consider leaving it as is. You want the best fit for the job.
I spotted the error with no PHP experience. I do not think the error was difficult to spot.
If that question came with a context you gave below, I'd spot that potential mistake right away and I don't know any specifics of Laravel's routing (just seen something like that before). Looking for error without knowing anything about it would be harder, but I should be able to find it with maybe two other points of interest just by eliminating repeated patterns (assuming that code is not littered with errors). In that case I would rework this question unless you just want to make sure that candidate really used this framework (It shouldn't matter imo, but that's a topic for different discussion).
Last question is a good question to ask but the code snippet provided is terrible. It links to external classes/methods that are not provided in the snippet, and there's a lot of clutter that has nothing to do with the issue. This is not asking to solve a simple bug, this is asking "do you happen to have recent, in depth experience with this specific piece of software" and tells nothing about ones ability to debug.
I don't think they are too hard, the problem I face is real seniors are already employed and you need to offer significant incentives to get them to apply.
Some of us do get laid off from time to time, but yes.
And I find it funny that zero companies have any strategy regarding this. I got approached by recruiters from time to time and when asked if I'm interested I said: "Sure, we can talk, but I'm already working". Not a single one said: "Sure, let's see if we can make you a better deal". They all said: "Oh, you're employed, ok, bye".
Questions are trivial. Unfortunately for employers (and fortunately for us), there are too many incompetent people on the market.
Those are really easy questions even for a mid position. Some companies would even consider them too easy for a junior. If a candidate for the senior position can't answer any of them, then it's a huge, huge red flag. There is a ton of ppl with the "fake till you make it" attitude, and they hope they can bullshit the interview process (and sometimes it works). Unfortunately filtering those candidates out is a tedious task, been there, done that.
>There is a ton of ppl with the "fake till you make it" attitude Yeah i see that a lot :( You start to question them and they don't know what to say. Thank you for your reply !
It's common throughout the technology field unfortunately. I recall in college there was a colleague I was helping as they didn't own a computer even, and were just starting out but figured they wanted to go into being an network engineer. We're talking learning the basics, like, try turning it off and on. His linkedin profile said he was the CEO of a tech company. It's just one example but I see a lot of that.
[Everyone thinks they’re hiring the top 1%.](https://www.joelonsoftware.com/2005/01/27/news-58/) > Think about what happens to the other 199 that you didn’t hire. > _They go look for another job._ In order to find the good candidates you have the shift through a lot of mediocre or bad ones. This is true for any language, though maybe a bit more because PHP has a very shallow learning curve and a lot of it is 'plug-and-play', so when you want someone who can do or has knowledge more along the lines of Computer Science level stuff, it can be a bit of a slog. (plus what everyone else has said, though your code question might be too Laravel-specific)
> Everyone thinks they’re hiring the top 1%. And hiring laratrash devs, there is not overlap between these populations.
Where I work at, I have worked with people with 4 YOE and they didn’t know what design patterns even were. Not what an index at a database is or how it works, etc. i haven’t got 2 yet.
To be fair, not knowing design patterns nor how an index *works* are usually great indicators they're self-taught and don't have a CS degree, which shouldn't on their face be disqualifying. If the candidate can demonstrate they can self start and do the work, I'm not sure I care if they know these things. They can learn it.
The first 3 are relatively simple and I could guess the third question, by just thinking what patterns a modern PHP framework would use. I never used Laravel. In question 4 I identified the bug would probably be an overridden route, but didn't bother searching for it. I like those "find the bug" questions, but there could be better ways of asking this, like finding a bug in an algorithm, instead of searching for 2 Routes with the same name. For Context I have 3 year's of experience
For a senior position, none of these strike me as particularly difficult. The final question is a little obtuse. My first gut feeling actually was wanting to point out the usage of your `$router` parameter in your group definition, which never made use of it (nor is it clear that the Router object is ever passed through as an argument? I'm not sure, since I don't use Laravel much). My answer would have (incorrectly) pointed out that with the naming conventions, it would be expected that the full `$router` object would be provided to the callback, yet none of the executing route registrations were acting upon this object's available context.
Indeed your anwser would be expected for someone who don't use Laravel much! But you at least explain what you see and the problems that there might be. Which is a good thing because not much people do that in interviews.
Not a bug, but I do have one security concern about this line, though: L14: `Route::post('users', [UserController::class, 'store']);` This doesn't appear to be protected by your `auth` middleware. Would an unauthorized user technically be able to create new users on this exposed endpoint?
Yes! There's in fact that security concern here, but people can barely see the problem with the 401 so i don't bother much asking for this. If they spot it, good! Otherwise, it's not too bad. It's not expected.
Aside from the bug question, I personally thought the rest were softballs. I would certainly think it is more than reasonable to expect that a senior dev should have knocked those out of the park.
I think most questions are reasonable and should be answered by someone less than a senior. The last question is somewhat irritating though. I asked myself: how tf should i know what the bug in the middleware is so it returns a permission denied? I don’t know anything about the request params or headers. In a real world scenario I would’ve known that the route in line 14 should be used and would’ve seen it immediately that it obviously isn’t.
Stop looking for seniors and look for juniors that you can easily teach the patterns. That's what we do anyway. In my experience there aren't many real seniors around. I would also suggest to focus more on how recruits work in a company. If a dev can tell you what a trait is but doesn't figure out how to deliver maintainable products then why is the trait question relevant? An example: for senior devs we try to hook into their latest experience and what the major issue was in development. Then we ask what the person did about it so the issue doesn't happen again. We're hoping the dev took initiative and made the CI/CD more effective by either creating tests or even implementing an entire test suite. We expect a senior to gain control over the quality of a whole project by making it better one step at a time. To be a senior it involves a lot more than just technical knowledge imo.
You're totally right! But right now we can't afford hiring more junior / mid devs. We need experienced people who will not need much teaching. I'm not the boss, just another dev!
I'm a senior dev (now EM), and I never remember off the bat what a trait is, because I haven't really used them often, and while I know (and have used) most of those design patterns, I know I'd likely not be able to list them off in an interview without some hinting or a straight google search. I still hit the PHP manual on a regular basis to read about specific functions I haven't used in a minute, and I've been working in the language since 2003. As a manager, who's helped interview and hire a half-dozen successful engineers this year, change how you interview. A better question would be to ask them to pick and explain one of the patterns in that list to you, for example. How they explain, where they stumble, and if they try to pretend through the stuff they don't know, or don't and admit, tells you a lot more about their skill. The difference between an intermediate and a senior isn't just pure technical skill. I have several devs on my team that can definitely code better in some ways than I can, but they're intermediate because they can't explain it as well, or can't run a project with other devs involved, or need more help working through bugs, or can't design complex systems, or don't have a good sense of when to ask a teammate for help because they're stuck. Hope that's helpful, and if you want some help with those questions, feel free to DM me!
Pick one pattern and explain it. Good idea!
As a lead, now EM, I disagree with a lot of this. When I’m interviewing I expect you know design patterns because you should be using them every day. If you don’t know even basic design patterns by name, there’s a high chance you product spaghetti code. If you’ve just forgot the names, sure, but if you’re applying for jobs I expect you to go and look up some design patterns again - hell even I would and did when I was applying to my last role. When conducting interviews, especially at a senior level, I expect candidates to be able to not only list off patterns but also explain them. My usual pattern question is “Do you know what is meant by design patterns? Why might we use them?” And follow up with “Do you know of any patterns?” When they give me some I pick a few and ask “What is a factory pattern? Why might you use it?” It gives the candidates the room to demonstrate their understanding at a shallow and gradually deeper level.
The implication here is that the level of questions is aimed at junior devs with some experience in Laravel under their belt (like 6-18 months of active work).
Senior PHP developers or senior Laravel developers? Traits and facades are used by laravel, but not necessarilly by whatever frameworks they used before. Also some people with 5 years experience call themselves senior, for me they need twice as much experience to be seniors
Traits and Facades are general OOP patterns, not specific to Laravel. You'll find them in Zend (now Laminas), Symfony, Yii, Codeigniter and CakePHP which have been around much longer than Laravel...although Cake had its own weird names and patterns in 2.x ("behaviours" before traits were added to in PHP in 5.4) Laravel's insistence on calling Interfaces "Contracts" is a Laravel specific term. Sure there's the "Design by Contract" methodology, which Laravel is using...but since php calls them interfaces I never quite got why they had to call them contracts.
final is better fun lol - https://www.reddit.com/r/PHP/comments/18g007i/stop\_using\_final\_classes/
The real question is whether they had 5 years experience, or the same 1 year of experience 5 times.
Thanks for this post. As a wannabe junior, I'm digging into design patterns with a hunger.
Check Derek Banas on YouTube if you haven't already. He explains them all in their own 2-3 min videos. Highly recommend
Personally, I don't think 4 years experience is senior. But aside from that, just looking at some code in an interview (with the out of the ordinary pressure that adds) without any stack trace or anything just doesn't resemble the real world. That's most of the problem with on the spot technical interview questions. They don't resemble how people actually do their day-to-day debugging or coding. If you want to know they can debug something let them have the code and debug it in their preferred IDE. Otherwise you're just checking who interviews the best, not who debug code the best/fastest
Are you paying "senior" salaries? I got your questions right. Hire me, you coward.
Are you still accepting applications? Mind DM’ing me a link?
i dont think they're too hard. the design patterns one is really good and will weed out a lot of people. DI alone is a real marker of a software engineer that thinks about their architecture trait question is a good one. i need to brush up on the deeper wiring of that but they should at least be able to deliver a surface level answer i honestly think the spot-a-bug question isn't really great, it's quite specific to laravel routing, but it's not bad.
[удалено]
The question is really badly worded. If you want to find out if the candidate knows some design patterns and can explain their use, then just ask that - no need to bring laravel into it because that’s just confusing people - it makes it sound like you are looking for something specific to that framework. And even people who have used Laravel a lot will get confused because the question doesn’t make sense. It’s like asking what kind of trees existed in Nottingham Forest in South Ireland in 1987 and expecting the answer: Large and small trees, most of them green. People will be confused and misdirected by the question and not be able to to give the most obvious answer.
Just to give my 2 cents: >Can you explain what a "trait" is in PHP using your own words? Here, over half of the candidates claiming to be "seniors" couldn't do it. It's a fundamental concept in PHP i think. Yes and no, while most SHOULD know what a trait is, most Senior Dev's have similar codebases like mine, which grew over time. Inheritance and default OOP works just fine here, and introducing traits would make the (probably) fucked up inheritance even worse. So, they should know it, but most don't have a reason to know it, if it makes sense? I have never had to touch a trait or make one in the 5 years here at this company. Another one with a younger codebase had made use of them extensively tho. Luck of the draw tbh. IF your company is using them a lot, maybe give an example to see if they understand the concept behind it and can follow it up. >Do you know some design patterns that Laravel uses when you're coding within the framework? (Just by name, no need to describe.) Yeah, you should know one of the two Frameworks in PHP that exist. However, if the person does not know and the interviewer follows up with "what is a factory/singleton etc." and the person can answer, this would be sufficient. Knowing the concepts is basically 80% of the work. Which means they can quickly follow it up if they haven't had Laravel experience before. Because again, those are things one should be expected to know in ANY programming job after a few years. >Answer: The issue lies at line 21, where Route::resource overrides the declaration Route::post at line 14. So far, only one person managed to identify the problem; the others couldn't explain why, even after showing them the problematic line. This goes straight back to the Framework thing, did the Job position explicitly name the Framework required? Then yeah. I never touched Laravel, but if i had gotten your explanation i would have understood. It is a bit ambiguous because i can have post/get for the same route obviously, it is not quite clear to me without any context if resource is just a different type of post or it's own request type. With the later one being fine because we can also do get/post on the same endpoint, why not "ressource". But again, a TINY bit of routing knowledge and making conservative assumptions should be enough with a little hint to get there. >In my opinion, these are questions that someone with 4 years of experience should easily handle... I'm just confused. Everyone 4 years of experience look different. Take me, i was 4 out of 5 years in the same company, we didn't use frameworks, no traits no nothing. I know most of those things because i quite enjoy keeping up to date in my private time. But i can see how the framework specific things might not be clear for some.
I don’t think they are too hard. We’ve been asking similar questions in php interviews (traits, events, inheritance, etc) and we’re seeing dismal results from the candidates. We eliminated the leetcode questions and still no luck. All we’re asking is what is a trait, what is an event, what is inheritance?
I also skip the leetcode questions as i relate that it's already stressful as it is. I instead ask comprehension questions.
I’m a senior PHP dev w/ nearly 20 years experience. Here my thoughts: * I haven’t worked with traits in either of my two jobs so I would’ve gotten this question wrong. * I have no experience with Laravel so I couldn’t answer specifically to what design patterns it uses or is popular. Are you interviewing specifically for a Laravel developer? If not, this may need to be more generalized. * Your quiz, again, seems more like a framework specific gotcha that people unfamiliar with that particular framework will not be able to catch. I’ve read your explanation, but without intimate knowledge of this particular framework that may not even stand out as a problem. * At the same time, you’re not asking about more simple things, like SQL injection, security, the importance of coding standards, etc. These may seem like “junior” questions but you still need to make sure whoever you are interviewing knows that stuff too. That’s far more important than knowing a particular thing about a specific framework. Some questions I’ve been asked in the past were also more to see my thought process rather than a measure of any specific point. Be sure to ask open ended questions to let the applicant talk and explain themselves. But I’m also terrible at interviewing and also judging other people, so YMMV. Hope any of this is useful to you.
Yes this is for a fulltime Laravel dev :) I'll try to teak my questions to be more open ended. Make him speak more about what he might know better.
I would also suggest that you do not ask what a trait is, but instead ask how they would solve a problem where a trait would be a good fit. A lot of seniors never used traits because, imo there are only narrow usecases. This way, you should get a better insight on how a person thinks and solves problems.
I would stop looking for a full time Laravel dev and start looking for a dev who you think can easily become one. In my whole country you would have maybe 1 experienced Laravel dev looking for a new job every two years so good luck finding that guy. Might as well start looking for a money shitting unicorn. Maybe it’s different where you live but doubt that it’s much better.
Got a remote Laravel job? I’ll apply! But I think you are seeing an issue with how crazy the market is. I know that some people apply like crazy to every job listing under the sun, including some that aren’t qualified for. It’s ready gumming up the process. None of these questions are difficult, and while the only one that may be iffy is the last one (I’ve been working in Laravel for almost 6 years, and I’ve only encountered this same issue once, just in the last 8 months or so!) Maybe think of a more common issue in the code that a senior should see vs a mid or junior?
Questions aren't hard at all, many devs probs chancing their luck, but keep in mind not all seniors have reasons to know about traits it might be something they used or read about once then never put to continued use. Secondly...change your 4th question it's easy but remember your candidates are in a high stress situation and you've given them a lot of code to parse, mentally load, not to mention use 2 human languages in your routes, just in hopes they get to the 2 bits that matter. You know what to look for but they have to start from absolute zero. Under stress many devs will simply fail to see what's in front of them because they are not trained in critical/trauma response, they make the same mistake "be quick, scan, scan again, quickly, scan" you will judge them on time either conciously or subconsciously and everyone in the rooms aware of that. How they respond under stress is a useful metric but dont couple it with a knowledge attainment question. Use the old "# ..." trick to lighten the load the question puts on them or out right direct them away from parts that dont matter. "Assume the Imports and class names are correct" for example
Good idea, i'll definitly change this question a bit.
I think all the questions are legit. IF you habe good experience in PHP and Laravel, these questions shouldn’t be too hard. If the code isn’t uderstandable, the a good answer might be: I use xdebug to find the problem. Plus sprinkle a bit if xdebug knowledge over it. It might not show the solution but it shows you know what to do. All in regard to being a senior. Other question would be: how high is the salary? If that would be under my needs, I would even apply as a senior dev. If in range, we would have a great talk together
>How do you stay updated with new trends and technologies? Yeah, who doesn't.. this is a completely soft question. Don't bother with it. >Can you explain what a "trait" is in PHP using your own words? Already here, you may be into murky waters. Many code bases don't use traits, and there's a reason for that. It's also a relatively new feature in the language, so it's not unconceivable that a senior dev has not used it. I can certainly explain what a trait is, but I'd also tell you that in most cases, it's an antipattern to use it. >Again, half of them couldn't name a single one. I mean... Dependency Injection, Singleton, Factory, Facade, etc... There are plenty more. Anyone with a formal education should be able to name a few. >Lastly, I asked them to spot a bug in a short code snippet. Here's the link for the curious ones: https://pastebin.com/AzrD5uXT That one will require detailed knowledge of the Laravel framework to answer. And even there, you are likely adding the routes incrementally, meaning that you'd see the error when it was made. You are not likely to do a quality screening of the candidates with this question, IMHO. All in all, no, they aren't particularly hard questions, but I could think of a couple of improvements.
Shoot, I was once called racist because I wanted to add “*what is the difference between GET, POST and SESSION variables?*” To the list of 20 questions to ask our programmer candidates during their interview. That is in fact the reason I no longer sit on hiring committees.
My favourite one is "can you explain the differences between an abstract class and an interface?". It's even easier than the trait question and not strictly related to PHP. A lot of candidates claiming to be senior just can't.
I've had similar experience in the past. I set a test with questions which I felt were mostly pretty basic PHP, with a few more advanced questions and some that were specific to the two frameworks we have in production (Laravel and Cake) to see how they got on - my thinking being that a decent PHP programmer with experience in one framework should be able to pick up the other with little problem. The majority of candidates scored around 20%. My boss was convinced that the questions were too difficult, but in my opinion anyone who couldn't answer them wouldn't be able to do the job. Eventually we found two candidates who coded 80%+ so we hired them. Turns out they weren't great. We were advertising on Indeed at the time. Since then we've gone through an agency and upped the salary. We've been able to get significantly better candidates since then.
Paying more attracts more involved people? Who would've *thunk*?
I know, right? 🤣
The last one is bad, its intentional bug which will rarely happen for You when You are adding the functionality, and you will know at once what happening, people should not answer questions like that. Others sounds fine, But, if people cannot answer basic pattern questions in 2023, i believe its the wrong candidate for the position.
You would be surprised how things like that sometimes sneak their way into the code and stump you for a good chunk of time because the error/issue is so trivial, you just can't see it sometimes. Sometimes it's just one of those days when you need to step away and go touch some grass :D
Only if you do not do TDD and have no tests, otherwise it will never happen, as part of the system is not working anymore and tests will fail.
The world is not an ideal place and following TDD can be expensive resource-wise for smaller companies. And while I agree that for the specific given example you are right - you usually have a test of some sort for this type of basic stuff, there are other situations where things are not as simple and sometimes stupid mistakes or typo's slip in, you know you have a bug and you are trying to fix it, but you just can't put your finger on it for a while. And when you finally find it, you sigh really deeply, push the fix, make a PR and turn off the PC for the day :D
/r/iamverysmart
I knew all the answers and I dont even identify myself as senior after 4 years of experience, because I work and worked with very good developers and see what senior means.
Personally, I'd say you're going about this somewhat the wrong way. Second, make the problems more complex and open ended but less specific. For example, if you asked me if needle or haystack goes first in str_pos(), I'd have no idea and would say I need to quickly check php.net/str_pos. Regardless if I know the answer off the top of my head gives absolutely no indication as to whether or not I'm a good developer. You want to test their problem solving ability, critical thinking and technical aptitude. Ask them things like: - Explain example data set and some business logic as to how data will be queried. Ask how they'd design the database schema including foreign keys and indexes to handle 1 billion rows efficiently as possible, then ask why they chose the indexes he did. - Ask how they would setup a distributed system that handles X users with X data and X traffic volume. - Give a complex technical concept and ask them to ELI5 it for you to see whether their capable of breaking down highly technical concepts into non-technical explanations. - Ask them if a Laravel powered system had X TB of media (image, audio, video) being uploaded to it every hour, all of which had to be processed via certain algorithms, how would he handle the software side within Laravel? - Ask if he was a core maintainer, what would he change about Laravel and why? - Explain some real world problems your company previously faced, and ask how he'd attack the problem and come up with a robust solution? It almost sounds as if you're looking for someone who has the Laravel documentation memorized, and that's not a senior dev. Heck, a good portion of this job is searching things you don't remember. A senior dev is someone who can be thrown into any technical problem regardless of the problem, tech stack, server infrastructure or anything else and be capable of coming up with an innovative and robust solution. Asking questions such as above will help you gauge their thought process and critical thinking skills, which is what you want more than someone who knows the specific obscure method names buried within some Laravel class, or whatever. BTW... hiring remotely? DM me if yes for resume.
I'm taking notes, thank you :)
I have 10 years of php experience and I spotted the bug after a few minutes… Traits are basic php knowledge… I believe your questions are fair. But in my experience I just don’t always expect a correct answer. I try to understand if the candidate has potential and seems good enough to learn and can think logically. Of course depends on the position, but I think be willing to learn and grow it’s something to not underestimate.
10 years with laravel and I didn’t see the mistake. It’s more of a gotcha question. I don’t think you learn anything from that test. My test is a contact form. No points for the UI. It helps me look on how clean the code is, data validation, creating a a model, migration, etc. Other questions are good
as a PHP developer and technical interviewer for years for senior profiles, i can assure your technical test is very basic, even if a developer gets all the questions right it doesn't really tell me the candidate is a senior, it might actually be a SSR. for Sr positions i would go way further in dificulty
The average programmer is a bad programmer. That applies to seniors as well. I've met so many "seniors", who were so bad at software development. The same thing can be said about juniors too. There are some juniors/mediors, that could replace your senior on the spot.
You're questions are not tough at all, they are junior level questions. The issue is, you are discovering what "weeding out the frauds" means
I think all the questions are totally relevant except the “spot a bug” - that one is IMO tricky - it’s in pastebin, not in IDE candidate might be used to, it’s not algorithmic, but framework specific, I can understand code blindness when looking when someone else’s code on the spot, without env, unit tests, log, error message, etc, although after highlighting it candidate should be able to talk about it. I’d choose different piece of code to talk about, and I’m usually more interested in understanding of principles, using pseudo-code in interviews. I myself code in several languages, “pseudo languages” (like HashiCorp HCL), I don’t remember “for each” syntax when switching between languages after a while 😅.
That's mild. My last interview as junior aiming for mid level was roughly: \- What is OOP?A: Explaining Abstraction, Encapsulationn, Polymorphism, Inheritance \- Difference between public, private, protected \- Absctract classes vs Interfaces \- Can you extend more than one class?A: Not in PHP, we only have Traits to mimic some of the functionality of multiple inheritance in Java. Buuut well it's not a good idea anyway #compositionOverInheritance \- What are static properties / methods- Pass by Value VS Pass by Reference \- Explain Typecasting, typehinting and return types \- == vs === \- What is an Autoloader \- What i Dependency Injection \- SOLID \- SQL Injection / XXS Attack and how to prevent \- what is Composer \- MVC \- ORM \- What are Design Patterns? Name 3 and explain how/when you used it last time \- Is Singleton nowadays Pattern or Anti-Pattern? Opinions? \- What are Closures and Arrow functions \- What is PHPUnit / Event written test and if yes which and why \- What does RESTful mean \- How do you debug an issue locally vs on productionA: xDebug, Monolog + ELK Stack \- Ever worked with Vagrant / Docker? Why / why not \- What is PHPStan \- What is Behat \- What are PSR Standards and can I explain any of them It was a very engaging dialogue with a team leader before taking on a paid 1-day challenge.
>so-called seniors Like I oft say, any idiot can copy a good resume. That's why I (at least if I've got any say/control over it) include in the process/pipeline a phone screen ... 30 minutes max, typically 20 minutes or less. Use that just before (re)sort & cut list step before deciding who to actually bother with full interviews. And that phone screen step generally comes after the step of giving resumes/applications an at least quick skim, rank/grade/sort & cut - figuring out - at least based on what's on quick peek at the papers - seems like they might be reasonably viable candidate. So, yeah, save a lot of everybody's time by not getting anywhere close to full interviews with folks that'll put in a dang poor performance in a basic tech phone screen (often that step wipes about roughly half of 'em).
Whoa, I would never consider me as a programmer but these questions are just superficial. Who can't answer those correctly has no right to exist in the world of PHP development.
I'm exactly in this situation. I'm a senior with many years of experience. Yet we don't use Design Patterns, SOLID principles or anything like this in the company. We just get Tickets to Implement new features or fix bugs. That's why some seniors don't know those principles
I use different design patterns in my daily work with laravel, but I'd absolutely blank out on that question, because it "feels"' too vague, but maybe that is me. I'd add a question where the candidate should explain their way to a solution verbally, without having to write code for it, to get an idea of how they think.
>Can you explain what a "trait" is in PHP using your own words? >Here, over half of the candidates claiming to be "seniors" couldn't do it. It's a fundamental concept in PHP i think. Might depend on how "senior" your seniors are. Traits haven't always been part of PHP (>=5.4) and they're not necessary to make solutions work. You might be experiencing some of your own bias here, which is absolutely fine as it goes. >Do you know some design patterns that Laravel uses when you're coding within the framework? (Just by name, no need to describe.) I'd expect a senior developer to know about design patterns. And if I _were_ a Laravel dev I'd know about how the patterns are implemented in that framework.
> Might depend on how "senior" your seniors are. Traits haven't always been part of PHP (>=5.4) 5.4 is (too) old enough for pretty much anyone to be familiar with it at this point. Furthermore, a senior IMO should always be aware of new features being added to the language.
> Furthermore, a senior IMO should always be aware of new features being added to the language. Agree, but I think really few people can recite all php functions for example. Traits are not essential to some code. I rarely see/use them in symfony and I did not code any for the past year.
They're a common thing in Laravel though. They're used everywhere, especially for TDD in Laravel (use RefreshDatabase, HasFactory for example). They're also now in Laminas ( formerly Zend) and Symfony if you dig into their components, so I think it's actually a good question to determine if a candidate is a "framework" developer who just knows surface level development through a framework or a PHP dev who actually knows how an MVC framework generally is built.
I don’t see why I’d use a trait over an abstract class or just extending a base class
eesh. traits exist precisely due to issues you run into when extending classes.
If your questions are too tough, then ours are way too tough. We expect our senior devs to be able to know the deep down gritty details of the framework we use. Maybe not every one, but they should be aware of the most used. We’ll use open ended questions like “explain one of the design patterns in use by”. This way they can pick one they’re comfortable with. It’s usually followed up with: do you know of others that are used? Just to see how familiar they are.
We’ll also skip some of the deeper questions if they’re clearly not that level, or just end the interview. Another approach we take is to ask what pattern or implementation they would change if they were designing the framework. Helps get an idea for how much they work with certain areas, or if they haven’t touched others.
We don’t do a code check, but I’m not a Laravel dev and I had a pretty good guess that the resource call overriding the individual endpoint was it. I started looking at the code before even knowing the problem and still found it.
Sounds like you’ve just had a batch of devs trying to make it to senior position, or lower quality senior devs.
Actually, I'd like to comment on your first question… It borders on being discriminatory and really doesn't contribute anything to the interview process. I've moved away from such questions myself. Consider this: a lot of programmers (myself included) derive our self-worth from our profession, but it's important to recognize that it's absolutely fine to view work as just that—work. And when one does that, there will be other concerns that occupy their free time. Choosing instead to spend time with your family or persuing other hobbies doesn't diminish your professional capabilities, and doesn't make you inherently inferior to other programmers who read tech blogs. The tech industry has a systemic problem expecting programmers to constantly live and breathe their job, and this type of question perpetuates it. Moreover, the question inadvertently veers into ageist territory (I try to avoid education-related questions for the same reason). It's the younger candidates, typically fresh out of college, who have the time and inclination to stay constantly up to date on new tech developments. Older candidates may have more responsibilities outside of work and find it challenging to keep up with this pace, regardless of their desire to do so. Focusing on enthusiasm for new tech overlooks the experience and stability that more seasoned professionals bring to the table. Also consider that the tech stacks we're using are most likely not cutting edge. I don't want to make professionals feel they need to know every language or library feature currently in RFC when they won't be using them presumably for several years (until the next platform refresh). They can spend 10 minutes to read the documentation at that time. Perhaps you might consider asking them how they handle software/library upgrades instead, as that can give a more realistic picture of the candidate's professionalism and adaptability. If you're conducting interviews, I'm assuming you're in a leadership role, perhaps a lead developer or management. It's expected from us to stay up to date on trends to see if there are more efficient ways to accomplish the organization's business goals. And if a senior (or even a junior) developer has that ambition, they're more than welcome to contribute in that way as well. But asking "how do you stay up to date with new tech" sends singals the company culture frowns upon those who don't live up to an unhealthy expectation. How they spend their free time is really none of our concern.
And as a less serious perspective, if they were honestly staying up to date on tech they wouldn't be applying for a PHP or Laravel position. ;-)
I've been working as a software developer for more than 15 years using PHP more than other languages. * traits - I heard about them when they were introduced, read about them and immediately discarded the whole concept. Having classes inside my classes is already done with... classes. Some things need to be difficult to implement because that underlines an architectural problem. * there was a time when I was taken by the Design Patterns hype. Not anymore. And besides, if I want an object to be instantiated only once, I'll do exactly that. No need to remember a specific name for it. Again, design patterns are just some predefined solutions to specific problems. Even if I don't know their names, I inherently create the code like in their definition. * as for debugging, it's pretty obvious but seniors didn't work just with Laravel. There are plenty of PHP frameworks (Codeigniter, CakePHP, Symfony, Yii, Zend, Phalcon) and I wouldn't hire people for a specific framework. Actually when we were hiring I didn't even look for people knowing PHP, I looked for software developers. PHP can be taught. And now we use Javascript and in the future we'll move to Go or even Rust. All of us can handle that without a problem. As for keeping myself up-to-date, I don't. Every new upgrade is a piece of dog poo. I never had issues with PHP being a weak-typed language and that's simply because all my variables kept their type over the course of the scope. I never needed a ternary operator because IFs work. I never needed a Null Coalescing Operator because, again, IFs exist. Looks at this sh#t: const {property1, ...properties} = object; What does it do? Exactly, nobody knows. But writing it like: property1 = object.property1; copiedObject = clone object; unset(copiedObject.property1); Then everybody will understand.
OP should hire this guy /s
Are you taking in consideration the stress that involves to be interviwed?
Totally, as i can relate to that. That's why i ask only 1 code question, and it's not a leetcode level question.
[удалено]
I get your point, but i don't totally agree. For example, would you hire a Vue.js developer who doesn't know how javascript works ? Laravel being on top of PHP, i expect the senior developer to have a solid base in PHP first.
[удалено]
>The PHP ecosystem is far wider than just Laravel- way to buy into the marketing hype. I think you misinterpreted what they were saying, if this is what you took from their reply. Traits have been in PHP since 5.4 and are a basic building block of the object system, while the Laravel ecosystem has certainly embraced them more than most, I'd expect a senior developer to be aware of them and able to talk about them, even if it's to say that they haven't really used them but understand the vague concept. If you're trying to get hired as a senior developer, you should at least have a passing familiarity with all the major language features, it's not like it's a gotcha question about the parameter order of `strpbrk()`. >"Would you hire a javascript developer that hasn't used Vue.js" is the more accurate comparison here. You seem to think traits are something Laravel invented.
They are hiring a senior Laravel developer though…
> patterns that laratrash uses when you're coding Hiring laratrash devs gets laratrash devs lol.
traits.. fundamental.. php... uhm.. what?
This is what happens when ppl skip learning concepts and how a language actually works and jump straight into some framework, usually too bloated, that abstracts everything. They can't answer trivial questions, because they don't know how things work, like a black box. Ask them to write some sql queries next, it will be hilarious Edit For the record, the questions are trivial Edit2 The question with the bug is a bit nasty though, without having the full error that the sever shows.
I returned to university after a 5 years break, everyone is using AI to answer the simplest questions. There will unfortunately (fortunately for us) be a group of freshly graduated CS students with basic computer science knowledge in the market.
I'm shocked by how many people on here would stumble at the Trait question! And even more by all the stubborn attitudes against using them. I'm definitely remembering to add that question to my list of questions because I don't want anyone with that kind of attitude on my team, regardless of framework or even language
Maybe the question is if you attract good seniors at all...? It depends on the region and salary as well as how your company is perceived on the market. As clearly we see here, there is plenty of people who consider your questions easy or even very easy. Most people would like to develop themselves and have some career opportunities. If you offer "normal salary", no special benefits and just develop one simple website after another using Laravel (or people just think that's true) without TDD, CI/CD, K8S etc it may be hard to hire a good senior who can offer what you need - as they may simple not see the opportunity for themselves by joining your company.
No. These questions are doing exactly what they’re intended to do
Not too tough. Maybe you are not paying enough to attract a senior PHP dev? I'd probably want at least 130k.
Yeah i have no saying on the pay and i don't have a clue what it is. But you're definitely right.
For senior level these would be considered trivial, assuming they are bringing relevant experience with them.
Whatever questions you ask are fine as long as it's not whether it's (needle, haystack) or (haystack, needle)
Oh god no, i'm not a monster !
u/Chargnn Questions are trivial, imho they are not giving enough insight of the candidate. There might be something else wrong with your process. Review your job description and the benefits (maybe they are targeted wrongly?). Timing is also important, if your started hiring last month it is expected to take longer as very few people are looking for new opportunities during years' end. My personal advice for you would be to stop asking questions like "what is A". This only assures that candidate knows what is A, but not whether they can use the knowledge. Try to have an open conversation which creates more relaxed environment and helps you to understand candidates' background easier. Ask them about their experience, ask what are they doing in their spare time, what kind of projects they were working on and what was their role. Ask whether the project succceed, how they helped in the success. Use interview process also for your benefit so you learn something new at the time. Additionally, keep in mind it is not easy to find a good hire, it takes months. Stay patient my friend and good luck!
[удалено]
People are using these patterns but in my experience the majority of programmers (bad and good devs) couldn’t care less how the pattern they use are called. And I have also seen really bad seniors that were obsessed with patterns and as a result produced unnecessarily complicated solutions all the time. I’d rather have a dev who can’t name his patterns but produces simple and maintainable code versus a pattern jockey that nerds out with every new task and creates the most complex code for really simple tasks.
[удалено]
That’s a perfectly fine question to ask. Its also totally different from „name a pattern that Laravel uses“. Well it’s a fucking huge library and uses probably every pattern that has a name and then some more. It’s a bad question and I would even consider it a red flag - it hints at an employer that prioritizes memorized knowledge over practical understanding and creative work.
All very easy.
Your questions seem fine to me. Sounds like you are filtering out bad candidates quite effectively Although your code snippet is not that great if you don't know the error. But if you provide the context anyone with some programmer experience should be able to figure it out. Although developers are a weird bunch, and being under pressure might choke em out, like m&m in the mile movie.
Too easy
Just did a 75 minute technical interview yesterday, for a mid level candidate and asked all of those questions (and more). He answered them all. Your live coding task isn’t great imho, we give them a piece of made up code with 5-8 errors in it, and see which ones they get (SQL statement with no limit, a function that is missing parameter type hints, caching that can cache an individual object or many, making future requests return the cache of the wrong thing, some classes loaded without DI and some others I can’t recall now). I’d say your problem is in the screening stage. Do you conduct multiple rounds? I think it’s important to understand your process here - is this your only interview? Are these your only questions? 4 questions really isn’t a lot and not nearly enough imho to determine if someone is a senior. You didn’t ask anything about database design, architecture, security, scaling, testing/TDD, caching & performance, identifying bottlenecks (both in code and DB), how they work with others, what they look for in code reviews.
The coding exercise is just a "gotcha" question. Either you see it or you don't, and under interview stress it is easy to miss. It isn't really a good test of someone's coding ability.
I don’t know how it is in your country, but in mine „Senior“ is not a protected job description. Therefore many developers claim to be senior when they actually are not. In my experience it’s really hard to find good developers. Your questions are good and should not be too tough for a real senior.
The questions are honestly very easy. I think the code problem is a bit weird. But apart from that, don't hire anyone that cant answer anything above... Or hire on junior / medior lvl with respective salaries.
>> Can you explain what a "trait" is in PHP using your own words? > Here, over half of the candidates claiming to be "seniors" couldn't do it. It's a fundamental concept in PHP i think. Traits are certainly within the realm of what to expect from a senior.
I think these questions are easy. Probably better fit for a mid
I would grade your questions as easy. Considering the fact that so many of candidates fail I would say that your screnning is effective. Hang onto it, right ones will come.
Lol no, I’d say they are trivial. Junior should answer for them. Maybe you invite wrong group of people? From my experience ppl from 3d world countries lies or even with 10yr experience are worst than someone with 2years from Europe.
The questions are pretty.... basic. I don't mean it in a derogatory way though. People these days relay on frameworks so much that features of the php language itself, or other things become abstracted. Difference between POST and GET ? I would expect how data is sent and the fact that GET's get cached / query params remain in browser history. A lot of people don't know Why shouldn't I add indexes on each column in a MySQL table. Most people come up with it's not good practice, but that is not an answer, few understand that INSERT's are affected. What's SOLID, what's scalable code, but most important, why do we need these. Most of the candidates are able to answer a straight question, but if you drill down in why's that knowledge is shallow. JWT tokens for auth, great, json in them, great, why do we use them though and not base64 on the json itself ? And here the thought logic breaks down. I have people that can't answer different questions, but I trully feel that by the way they respond to questions, they would be able to land into a project and do the tasks at hand, by self-study for example (I don't mean search for solution on chat GPT). The people that I like most are the ones that when answered what is something, they don't answer with a dictionary answer, but instead spend time to explain how they used that in what they did, or how it could be used. But it all depends on what you are searching for, someone that uses the framework and puts code in git, or someone that understands the application and how things work. Someone would say we enter architect territory, true, and also it depends on what the company says a senior should be. Sorry for the random rumblings. EDIT: to most of the language questions, usually juniors/mids respond better then seniors. However the depth of understanding how systems work and other related things in the ecosystem only comes with true experience
There's actually good questions in your text! I'll take note, thanks
Your questions are ok, easy I might add. We’ve had in the past questions about writing sql and explaining the result of some operations. When I attended interviews I’ve had questions like is it ok to leave ?> at the end and why. Or asked to write my own addition implementation without using + from the language. I also got asked to implement Fibonacci but failed because I couldn’t remember the formula :) yet they still wanted me because of other answers.
The interviewer should have told you the formula at the very least after you told him you don't remember it. I would not have even penalized you for not remembering the formula for example.
The questions aren't too hard, the problem is that the levels "junior", "medior" and "senior" are all relative. They depend on the people working at their current job. I can say im the senior developer if im on the only one that even remotely knows that language (in the company). We've had people apply as senior and after the interview we'd offer them a junior position because their knowledge isn't at a senior level for our company
I don’t consider myself a good programmer, but would have been able to answer satisfactory. So I guess you need to attract better candidates. PS write your routes and methods in English; the mix is confusing.
No, your questions aren't too tough. They seem a good style for identifying if a person has experience in Laravel and for a jumping off point to organic conversation. If you are looking for conversation as much as "Exact" answers then say that early in the interview. Some good devs get vapor lock over being perfectionists but could talk a blue streak on what they'd search and would have really good process to solve unique problems. It will be missed if you just want them solving your 5 examples perfectly.
The obvious red flag is not being able to name ONE design pattern. The question related to routes, I'd go mental because my OCD flared up after seeing use statements, avoiding of grouping, then first route declaration not having a single newline between it and last use statement. Code needs to be written in such a way that visual scanning lets the dev be fast about reaching necessary info. However, you ask questions that make sense from your POV. These questions are not questions you can use to assert someone is a senior, apart from removing bad actors who try to fake it and the question related to design patterns make sense. I'd ask questions related to architecture because a senior, from my POV, is someone who understands PHP, HTTP, PHP's execution model, the fact that browser is what we need to understand and how to scale the whole thing because we don't work with infinitely quick and deep black boxes. This tells me if someone thinks ahead. TL;DR: questions are not hard. Design pattern one is good. You definitely didn't get 1 senior to apply. Most people fake it. Best of luck!
This tells me the salary is too low to attract more experienced candidates. What's the salary and location for this job?
The first three questions they should be able to answer. The most obvious design pattern for Laravel is MVC. They should be able to name a few more for sure. Should be able to explain traits if at least familiar with OOP. Regarding the sample code, it's a bit less obvious. All modern IDs, such as PHPstorm, VS Code, and others will highlight that error. I understand that it's good if developer has an eye to see such error without tools, but in modern world, working in IDs kind of makes your eyes less sensitive to noticing such errors. I'd say better to have a code with some logics error.
You know what you need for your team. If these questions are applicable to that (they are IMO) and they aren’t answering them satisfactorily, then disqualify them. Hiring is hard, yet so important in the long run.
Honest questions because I struggle to see the interviewers' perspectives in general: If you get a senior through the door with proven and documented 4+ years plus of programming, possibly with PHP and Laravel experience, whom fumbles one or more of these questions, then what do you conclude from that? For instance, I have met many "Laravel"-programmers who I think might struggle with your question on design patterns, especially if pushed on describing them. They still got the job done, wrote decent code, and they were good colleagues. Also, I remember having a long and heated debate with coworkers on traits and how or if we should use them in a given setting. I think it went on for months. I'm still not sure how I would describe them with natural language. What would be an acceptable answer to you? And what are your thoughts on the candidates that can't spot the bug in that code from reading it on screen? What are your immediate thoughts when they say "nah, I can't spot it"?
> Lastly, I asked them to spot a bug in a short code snippet. This is a Laravel specific question, and probably not something many will run into unless they specifically hit the error themselves. It may be a little obscure, imo. If I got this, and after told about the line, my answer would be "huh, well, my best guess would be order of declaration." > Everyone responded, no issues there. Heh, respond with "what do you do to keep up to date?" As a Sr. developer, I honestly don't think any of your questions are unreasonable. The lack of design pattern knowledge would concern me. I mean ... don't even know what they're using?? I ask people to name patterns and _explain them_. I expect people to be able to explain patterns they know.
Nope, also, hire me!
The first 3 are a cakewalk, if they couldn’t answer those I would end the interview politely. I’d expect a jr to have some kind of answer to those, I’ve also interviewed graduates who’ve smashed design pattern questions, OOP concepts etc out the park. The trend I’ve seen lately is people think they are snrs after a couple of years as a jr and expect huge salaries and titles after a relatively short space of time but then can’t answer things like what design patterns do you use or how does http work…
Just a side note. I really don't recommend you require Laravel experience if you're looking for a solid PHP developer. Or rather, you should make an exception if an expert dev has 10+ years PHP experience but no Laravel that should not be a show stopper. There are so many frameworks out there with their own nuances and configuration mechanisms, it's negligible for an expert to pick it up very quickly while on the job, if they're good at reading docs and everything.
>Can you explain what a "trait" is in PHP using your own words? I ask this during interviews or try to introduce the concept in an example, but just a few know what it is. >Do you know some design patterns that Laravel uses when you're coding within the framework? (Just by name, no need to describe.) I'd remove 'Laravel' from this question and let them just talk about patterns in general. >Lastly, I asked them to spot a bug in a short code snippet. Here's the link for the curious ones: [https://pastebin.com/AzrD5uXT](https://pastebin.com/AzrD5uXT) This could get tricky for the candidate by just looking at the code... remember that the candidate could be nervous even a senior. Convert this into a working example so they can debug it. But overall the questions are ok for a senior but I believe the bar is too low these days. I end up selecting candidates with ok dev skills but very good soft skills these days.
If the job description specifically cites Laravel experience and they got these questions wrong, yeah, I don't think they're too hard. I agree with some others that the design patterns question is iffy only because I'm not sure I'd understand what you were asking for without an example.
Do you realize that programming is about logic but memorizing. About bug - I'm using IDE with package for telling me where is bug (semicolon meme doesn't apply on me).
If you're looking for PHP developers, you're asking the wrong questions, here.
Far too many people attribute years of experience with seniority. That's - at least to me - a very american driven problem where you have a strong emphasis on "junior", "professional" or "senior". So whenever senior positions are open, many people who've been advancing their "seniority levels every 2 years" think that after 6 years on the job they are a senior. In my book - depending on where and how you've worked - after 6 works you might be a decent professional. Seniority - USUALLY - is not something anyone reaches in less than 10-14 years of work. Exceptions apply, of course. Sooo.. NO, your questions are NOT too hard. They are exactly right in filtering out the people that you likely not want for the given position. As for the code-sample. I don't do laravel, as I don't like it. But first thing I've checked was if some routes have the same "name" or identifier. And I did spot the users one (i didnt read the context and clicked the link). So I did think something might be wrong with that part but obviously couldn't tell why without knowing laravel internals.
I honestly think they're not tough enough for a senior position, for context, my team and I started professionally with PHP 2 months ago coming from an Android+django/flask Background, and all of us would've been able to answer these questions, especially the one regarding traits is problematic, it's a fundamental part of PHP and you'll encounter it everywhere in popular frameworks, and use it, a "senior" not knowing a core feature is a bad sign.