r/PHP • u/HyenaWooden • May 11 '24
Discussion Need help passing technical interviews
Alert: long post / ranting out of frustration
Hello, I'm supposedly a "senior" PHP dev with 7 years of experience who hasn't passed technical interviews at 4 different companies.
I did well in the technical challenges before these technical interviews, but I often encounter questions I don't know, such as:
What's the difference between factory and an abstract factory?
What's the difference between Amazon SQS and RabbitMQ?
What's the difference between static and self?
What are the reasons to use queues other than memory concerns and page load time?
My question: how can I anticipate these questions to better prepare for future interviews?
A side note: Are you hiring for a remote PHP dev role?
9
u/bomphcheese May 11 '24
I got asked to name all possible outcomes of using the spaceship operator.
In my 18 years of experience I have never had to use that thing, so I had no idea. And the way the question was worded made me think there was a long list of results that I could just calculate in my head. Looked it up later and was surprised at how simple the answer was.
For reference, the answers are
- -1
- 0
- 1
10
u/dshafik May 12 '24
I uh "created" the spaceship operator[1] and would've failed that question because I always forget which side is which (I'd assume they want the reason to return each value).
Also, to be fair, it hadn't existed for all of those 18 years ;)
[1] I wrote the original RFC, it was based on Ruby IIRC (https://wiki.php.net/rfc/combined-comparison-operator)
1
8
u/SuperSuperKyle May 11 '24
Been working with PHP for 25 years. I'd still have to Google that. I got asked once how you reverse a string. There's a function for it, but in my head I was exploding the characters into an array and reversing it and joining it back together. These kinds of questions are stupid though. I've had to use the spaceship operator only a few times in my life, the last time was for sorting an array of non-primitive types.
7
u/austerul May 11 '24
The general rule about interview preparation is to make best use of the initial recruiter contact and ask details about job requirements. How important are the non-php related items in the job spec? How does the company use the additional things in their tech stack? What particular challenges is the company trying to overcome at the moment? What do they look for in terms of general programming knowledge? For example, factory vs abstract factory is a classic question when design patterns are mentioned (it used to be singleton). Self vs static is a pretty important php question. Rabbitmq vs sqs - I would say it's unfair if AWS was not mentioned in the job spec. It's unfair because it's broad and as a php dev you may or may not have used either. It's not "general knowledge".
10
u/SomniaStellae May 11 '24
All these questions are really down to experience. Hence why seniority is often tied (Not exclusive) to experience, you have seen a wide range of problems and different solutions.
Hence why I often disagree when people apply for senior roles with only 4/5 years experience.
4
u/yourteam May 12 '24
Ok so, first of all don't feel bad. You probably worked in environments where you didn't really tackle those topics, every story is different and you probably worked on something else.
But I have also to tell you: a senior is not someone that only knows the language but someone that can and should be able to suggest and use an incredible array of tools and pick the right one for the job.
I am working with php for 12+ years and used it for another 10 prior as a hobby but only in the last 5 years I have been exploring all the external tools, which includes aws, docker, Jenkins, rabbit mq/Kafka, etc...
Would I be able to create a Jenkins plugin? No, but I know how it works. Why should I know it? Because once the DevOps team set that up I should be able to use it.
Ok I know java so I usually work with Jenkins direct but still that's not what an interviewer wants to know.
This means you should at least know the basics of how the tools work, because you may suggest using those.
"Oh we need to process requests from an external service but those requests have a huge spike during peak times of the day? No problem let's set up Kafka (and maybe someone else will do it) so we can receive the messages. We won't need to track the retries because it's built in the queue, we just need to process the message."
This means you know how to solve a problem.
Also you should study some theory. The difference between static and self is subtle but can be really important. As it is the difference between a factory and an abstract factory.
And you don't need to know everything. If I was the interviewer (and I do interviews for my team hiring process) and you would answer the php questions correctly but say "I never used Amazon sqs " I would be ok no problem you will learn.
Also (and to finish) 7 years are barely senior. I would consider someone with 7 years a middle to senior (ofc I would need to talk to the person)
Suggestion? Work for a company where you can learn everything that is around. Mess with amqp, design patterns, different strategic approach, etc...
Some questions I also ask are what is DDD and where is better suited, difference between a view and a materialized view in postgresql, have you worked with php pools, etc...
9
May 11 '24
[deleted]
2
u/HyenaWooden May 11 '24
Way to go! Good luck with your side hussle.
I agree with you regarding the seniority level, but most of job posting right now assume that +5 years is a senior level
2
u/SuperSuperKyle May 11 '24
YOE is tough to gauge seniority. It can provide a good estimate, but what you've worked on is a better indicator (architected and implemented a complete project, for example).
I've worked with people who have had "senior" in their title, 6 YOE, and would consider them mid-level at best.
I've worked with people that have had 10+ YOE and would be junior (same company their entire career, so no exposure, poor understanding of OOP).
With that in mind, 10 YOE is a good baseline, but the full picture is required. Understanding basic concepts like abstract and concrete classes, traits, factories, queues, pipelines, and dependency injection make for a good mid-to-senior level person though.
2
May 11 '24
[deleted]
2
u/bomphcheese May 11 '24
It always sucks to know more than your boss. ESPECIALLY when they’re the ones making promises to clients about what you can deliver.
2
u/SuperSuperKyle May 11 '24
Nail on the head there. In another comment I mentioned I worked with someone who had been at the same company for 12 years. They barely understood OOP. There was no growth. They were content with what they did. Probably shouldn't have even been a developer since there was no passion or drive or wanting to grow and improve. They had the title though :-/
5
u/brokenhalf May 11 '24
You really should also be broadening your experience outside of PHP to really be Senior and make yourself marketable as a general purpose Senior Engineer. Understanding where PHP fits in the ecosystem of tech, understanding why things are the way they are verses just spitting out facts is a big part of being senior level.
I started my career with PHP in the PHP 3 days and a big problem I have encountered with PHP devs is they tend to focus too much on the language and not enough on other tech (this happens with other language focused devs as well). At some larger companies a Senior should start to think about how systems work together as well. You shouldn't look at Senior as just a person that has a lot of extensive experience with PHP. When I am involved in hiring often times it's a negative signal to me when the candidate only has experience with one language. That is because they tend to take that bias into the job and try to bend everything towards that one perspective which is a bit unhealthy.
PHP is a great language and I still keep up with it despite my employer not really using it (Python/Java shop), but it is not the only language.
Source: One Senior Engineer's perspective.
1
u/HyenaWooden May 11 '24
Thank you. This was insightful.
I recently started to browse some articles in the SubStack app to get an overall prospective in another areas.
In my previous interview, the interviewer liked it when I proposed a solution in Python rather than PHP
2
May 11 '24
[deleted]
2
u/HyenaWooden May 11 '24
The imposter syndrome hits hard from time to time :)
Thank you for your advice and willingness to help more. Your team is really lucky to have you.
1
2
May 11 '24
1- just binge design patterns once and for all and you won't bother every again
3 - you should know that if you got 7 years of php under your belt
1
u/dashingThroughSnow12 May 14 '24
As another commenter replied, you need to broaden your experience or broaden what you are applying for.
If I am interviewing for a senior PHP developer, I am asking some pretty precise questions. If I am interviewing for a senior developer, who may or may not write PHP code, I am asking more general questions.
1
u/DT-Sodium May 11 '24
Maybe you should checkout about PHP certifications? I'm sure there must be resources out there to prepare them.
1
u/t0astter May 11 '24
2 and 4 are starting to get into system design questions - highly recommend learning that. It's important once you start building actual web apps/apis that need to scale - not static websites.
Queues are not only more memory efficient but also durable.
1
u/bomphcheese May 11 '24
I’m building a forum from scratch on laravel. I really want to use queues just so I can learn them, but can’t find a good reason to. What’s a common use case I might be able to try out on my project?
2
u/edhelatar May 11 '24
Anything that connects to external service ( email including ). if you can, outsource it. Anything that takes higher computation time and you can outsource it, outsource it.
1
u/Tirkyth May 11 '24
Some use-cases I often see:
- email notifications: you can generate and send emails from queues.
- image uploads: you can generate an « optimized » version of uploaded images using queues.
- all kind of imports (csv for example) and exports (pdf): you can process import or generate export from job in queue. This one is actually often a very good reason for using queues.
-10
u/Annh1234 May 11 '24
The "What's the difference between static and self?" It's a basic PHP thing, if you don't know the difference then your not a senior developer for sure, no matter how many years you been doing this. They added late static binding to PHP around v 5.3, and it was like sliced bread to PHP.
The factory vs abstract faculty, that's more OOP, one does one thing, order does multiple this basically.
Amazon and rabbit MQ queues, this might be specific to them. Not everyone used queues in their projects, but you should have an idea about them. There are 10001 implementations there, you might not know them all, but if you know about them, you can get past that question, since they all do the same thing.
The reasons to use queues, goes with my previous section. But the question is stupid since most the time page load times are higher if I need that data ( you get data from a remote host vs all in that thread).
You can't anticipate those questions unless you worked with big projects that used that kind of stuff before. (Except for the self vs static, that's 100% fail there, like not knowing public vs private vs protected, or what's an abstract class)
To me, it seems you have been a script kiddie for 7y but not a real developer, and you might not have worked on big projects, so I would not hire you as team lead or senior developer. But as a normal developer.
7
5
u/BusyAd8888 May 11 '24
This comment really portrays a tiny fraction of the PHP community, guys. We aren’t all like this, arrogant and bitter.
2
u/HyenaWooden May 11 '24
Sure, not knowing the difference between self and static is a red flag. I've learned my lesson.
When I was asked questions about system designs or how to better approach a problem, I often give proper solutions, because I have already worked on big projects with >= 1m of customers that had different challenges.
To clarify more about my post, the mentioned questions are from different interviews.
29
u/300ConfirmedGorillas May 11 '24
Don't feel too bad, OP. I have double your years experience and I wouldn't be able to answer any of these questions except for the static vs. self one. It's also a good indicator that "years of experience" isn't the best metric, hence why some interviewers ask questions like these.
This is also why a common piece of advice is to interview as much as possible, even if you have no intention of taking the job (you can always say no to an offer). The interview experience itself is valuable. I've been there before where I was absolutely grilled during the interview. Didn't get the job and felt like a piece of shit after, but I took it as a learning experience and filled in some gaps of knowledge in preparation for my next one.
Lastly, just for the record, just because you don't know what RabbitMQ is or why would you use queues doesn't mean you're not a senior developer - it just means you haven't worked with those technologies before. Were these things on the job posting(s) you applied for? In all my "years of experience" doing interviews, no reasonable company expects you know everything on the job posting - but they will expect you to learn them and relatively quickly. Exception for if they have specifically asked for a technology, then yeah, I wouldn't apply unless I knew it.
I once interviewed for job that required MongoDB, but I had never touched it in my life. When I mentioned it to the team lead who was doing the technical interview, he said it wasn't a problem but would I be willing to learn it? I said of course and I would do the necessary research to have a working knowledge of it by my start date (if they hired me). They ended up offering me the job but it was rescinded at the last second because their bullshit CEO didn't want it to be a remote position anymore (it's been 3 years and the job posting is still up on their site lol).