If you're PHP developer of any experience and you were at least at one job interview, then you've been asked to describe your knowledge in a specific framework. This question becomes so common that we considered it standard for job interviews for PHP positions. Why companies and recruiters insist so much on knowing how you're skilled in the specific framework? Why might you not pass the interview round if your experience in the specific framework is not sufficient?
A framework is a tool, not a skill
Everybody should consider framework as a tool, but never as a skill. Separating programming skills from knowledge of a specific framework is particularly important during the recruitment process. Many good candidates were rejected since they do not have experience into a specific framework. That could mean two things:
- Companies bind themselves to framework too much
- A person who is doing the recruitment process has no or little knowledge of other frameworks.
I already covered the first topic and dedicate whole blog post. For the second one, there is no simple solution except educating people to understand the framework purpose better.
Tools
Tools are the framework, libraries, IDE, computer, version control systems, virtualization software, etc. Tools are something we use to build a product. We can build our product with the various combination of tools. In most of the cases, tooling does not determinate is something is possible or not. Companies sometimes bind themselves way too much to the framework, to the level that they need skilled people who can only think inside the framework playground.
Skills
Skills are clean code, documentation, solving problems, testing strategies, architectural skills, etc. Skills are something developer may have or don't. Well skilled developer, or the one eager to learn, absolutely can handle any tool (framework in this case) and build a good product.
Conclusion
Tools are a screwdriver, power drill, and spirit level.
Skill is to use these tools to create something.
Common question
I already got this question a couple of time, here and at my presentations, so I will answer it here shortly.
If a company have [Symfony|Zend|Laraver] application, then they need [Symfony|Zend|Laraver] developer, right?
If your business is for example "music streaming service", and your application is "Laravel" application then that's so wrong. Your application must be "music streaming application", not "Laravel" application at any cost!
The reasons why is:
- If you unbind from your framework, then you can upgrade without fear, to the next version.
- You'll be able to reuse your code in/with other environments, libraries, and frameworks.
- You don't have to adapt your app every time framework deprecates some of their libraries.
Once again, a framework is a tool, not a skill.
Here are the other resources from this series directly connected to this one
Top comments (25)
I get your idea, but don't agree 100%.
The level of control you have in a framework is a skill as well. The same way you can learn and improve in coding, you can learn and improve in using the specific framework. And i think that you can't take framework for granted.
You can be great in pure javascript or typescript, but when you come to angular framework - you dive into an intirely different thinking, different structure. It's a bit like learning another language. So a developer who is great in javascript but has no idea of angular - probably not easy for the company to hire. Learning angular takes time.
I think you underastimate the time learning a framework consumes and that's why you think it's not a skill, but a tool.
Maybe the framework itself is a tool (as is a programming language) , but when you learn it you gain a separate skill
I'm a junior dev. I used to be mechanical engineer. When we used to hire my boss was thinking there is no difference betwean 3d software like solid edge and solidworks. So candidates who knew solidworks came in and supposedely were able to work instantly in solid edge. In fact, they were very much struggling, not knowing what buttons to press. Also each tool had it's own consept of handling asseblies... So if fact those candidates needed to be sent to a dedicated course for the framework! Just think of it. Both tools can build identical mecanical structures in 3d, but you can't easily switch from one tool to another. So again, a framework is a skill as well.
In general i think any knowledge we gain in life is a skill
Hi Michael, thank you very much for your feedback, I see you brought a couple of very true examples. I agree what you wrote about JavaScript frameworks, it is true that they bind so much your code into their structure, and it is impossible to separate that. At least it was like that a couple of years ago, I don't know if anything changed recently.
On the other hand with PHP is not like that. Php already has defined syntax and your backend logic should be highly separated from framework components. I already wrote about this in this article how to avoid shape your app with framework. If you accomplish that, then you do not depend at any level from the framework (at least not hard).
I also studied mechanical engineering in parallel with electronic engineering, and I'm very much familiar with the example you used with 3D software. But I have to add just a disclaimer here, that difference between Zend, Laravel, and Symfony, for example, is way less than between different 3D software.
And I must agree with you that every knowledge you can apply is a skill :)
Thank you for you reply, Damnjan! Nice to meet some people with similar background. Would be awesome to here about the way you managed to switch to software because i find this process a bit challenging, when you don't have real world experience even to start/apply for jobs...Anyway, it's interesting to know that PHP frameworks are more separated from the language than js frameworks. It's a good think i suppose.
I learned some PHP but was very disappointed that the course i took on Udemy skipped completely on any PHP framework, while a framework was a must requirement in most of the jobs on the market.
I can tell you, though, that recently i had a junior dev interview, that had an exam that specifically asked NOT to use any PHP framework. So probably, at least some of the employers probably agree with your thinking/philosophy on this matter.
Hi Michael,
Thank you again for your comment, I'm glad to share with you my experience with my transition to software development :)
To answer your question about switching to programming, back then after finishing studying I discover that I want to progress in software because of an unlimited playground, which was not the case with electronic or mechanical engineering. I had a problem with the limited amount of local companies doing something cool and innovative with hardware, but software opens a whole new world to me.
But, because it was impossible to jump into software, I found my shortcut. I started working as a Windows and MS office teacher in computer school. There I was surrounded with other colleagues who teched other students programming languages and databases. So basically I was in the middle of a big pile of knowledge :D Mine job was only to ask and practice, everybody was eager to help.
Anyway took two years at least to be able to apply confidentially as a software developer at my first dev job.
Frameworks are "must requirement" because they make life so simpler and more comfortable. I could quite understand companies ask generally do you used any framework. I never advocate for not using frameworks at all, but I see so much bad practices while folks using it, that I feel obliged to point it out. Someone doesn't like that because they get used to bind themselves to frameworks (it is usually the fastest and dirtiest path), but it comes with the costs. My mission with this posts will be that one who read it, thinks about that next time and maybe improve her/his code next time.
Another problem you mentioned is exactly that developers are unable to think "outside of frameworks". That does not scare them now, but it could be dangerous in the future when that framework dies or something else become cool.
What programing language you choose at the end if you didn't pick PHP? :)
How it was your path of transition from mechanical eng. to dev?
I like your comparison with 3D applications. There are certainly similarities between 3D apps, and on an abstract level they all do the same. And isn't it ultimately all about the artistic skill of the user and not the application itself? I guess not 100% if a lack of experience with the tool at hand hampers your artistic skills. Blender 3D for example is notorious for having a steep learning curve.
I would not expect a Maya user to be productive in Blender within just a couple of weeks (or vice versa).
It also wouldn't cross my mind to blame the employer for having only Maya (or Lightwave or whatever) workstations available and not the one application I am trained in.
Experience with a tool is also a skill and depending on the situation I don't see why it shouldn't be a requirement for a position.
"I guess not 100% if a lack of experience with the tool at hand hampers your artistic skills" - exactly the way you've put it into words. Coding is like artistic skill and the framework is the tool, but ultimately both are time consuming and therefore are both skills.
The company has a plan: they decided that they are going to do this project with Laravel, so they need a developer who is familiar with it. They cannot waste time waiting for you to learn this or that framework.
The market is competitive, things move fast. As much as I agree with your logic, you gotta look at this from their POV.
Hi, thank you for your opinion. I have to disagree profoundly with you on this statement. Regarding the fact, that company decided they go with Laravel, what's that mean? Does every class has to derive from Laravel? What specific things from Laravel have to interfere with your business logic?
I already wrote about shaping your app in the shape of framework., and started to write about how to avoid businesses logic in the framework components. Please take a look on these, if you have a time, and let me know your opinion.
My advice is: stays away from companies which bind themselves to the framework.
This is probably the reason why I find it hard looking for php jobs. I can't learn a framework for the sense of finding a job where its required. With frameworks, I started with Flightphp and now I'm enjoying Slimframework and I don't see myself learning lavarel, symphony or anything else for that matter without a compelling reason, like joining a team that uses these.
This evidently, in my opinion, is the reason for the slow growth in php communities. The workspace isn't versatile enough for devs to explore and learn more about the language.
That moment when they ask, how many years of experience do you have with Zend or Symfony! I would rather ask, how well can you code in PHP and how much do you know about performance within the language.
This is so true. It is difficult to get that PHP interview with a company without knowing the framework they use which is so unfortunate. My first 2 jobs used no framework and if it wasn't for my current boss believing that a "framework is a tool, not a skill" I wouldn't be working with Symfony now. It really wasn't that hard to pick up and I doubt any other framework would be difficult to pick up.
You are correct. What's the difference between a philips and flat head screwdriver? They do the same thing in slightly different ways. Frameworks are the same way.
Hi Pankaj, you don't need to be sorry for your opinion, I love to have discussions on this topic. I can agree that there must be a time investment into understanding some framework specifics or how to set up, what to avoid. But, your code, should be your business logic, not frameworks, so your code lines, for your application, will be 99,9% of your work — the framework specifics, you can learn in a matter of week or two, how to set up, what are general concepts, etc. But writing good DDD code, testable code, clean code, understanding and apply SOLID principles should be your desired skills.
I already wrote here about the problem of shaping your app with the shape of the framework. If you have time, please take a look, and tell me what you think.
I've always hated this "years of experience" rigid cretarea. It really matters if you have 10 years of building staff or 10 years of ruining staff, isn't it. But most recruters won't know the difference
Hi Ankush, thank you for your positive feedback.
I'll also add that this problem not only appears with a recruiter during the recruitment process, but these two questions you mentioned may come from team leads or CTO's as well.
That's particularly sad for me because that means that most of the company shaped their product with the framework, inseparable.
Then what, build a PHP from scratch ? Building on a framework requires skills. How to build something fast , MVP. On top of that if Laravel developer get hit by bus. I can find another whom will be able to pick up the project compared to some , custom skilled professionally well documented PHP Frameworks that dead developer made ?
Hi Jonathan,
As I already gave a talk on this topic two times, I remember every time I got this question as well :)
If your business is for example "music streaming service", and your application is "Laravel" application then that's so wrong. Your application must be "music streaming application", not "Laravel" application at any cost!
The reasons why is:
We all think it, but you said it :)
To add more to your valid points:
I use Laravel very often, but I use it for what Taylor intended it to be; an Application Framework. In this context "Application" is not the system nor the solution, it is the application of the system or the solution.
Application is where or how something is applied. In this case, how the system is used to the web. The framework (in this case) provides access control to the system via Auth, ACL. In the case of Laravel, it also helps with bootstrapping, dependency injection, environment variables, etc.. You know things your application needs but not things that your business logic needs.
A common mistake and a terrible one for that matter are devs either placing logic in "HTTP" Controllers (I mean HTTP Controllers. The name says it all) or in database abstraction layers (Again, DBAL/Eloquents purpose is very well documented). It is so simple to notice that having logic tied to a database or even if it is an abstraction such as Eloquent, you will be reading from the persistent storage every time you need to check a condition.
There's no need for that, and that is not why we have functions and variables -> processors and RAM.
I also wrote about this topic here: keith-mifsud.me/blog/start-a-new-p....
Also, Laravel (for example) is built with this in mind. Why does Laravel offer Interface to Concrete binding out of the box if we are depending on concrete classes?
Eloquent's job is to abstract SQL and not to create some sort of fluent query language for business rules. I can go on forever..another example I see very often...
Users are not Members, nor they are Clients. Users are merely people (or systems) with access to the application. A Member cannot suddenly update their name. It is sporadic for someone to change their name in the real world and I'm sure that most systems need to have real people's names. Same for address. Update address does not mean the Member moved house but that the House suddenly changed its name or location. This hardly ever occurs in real life!
This is a serious matter. This year (2019), I have worked with a client who because of these mistakes by their Engineering team, completely screwed the whole SaaS. The damage to their reputation was so bad that they ended starting from scratch, new name, new brand, new marketing. They've lost 2 years of hard work because the system could not grow, the team did grow but made it all worst because the CTO was only looking for Laravel and VueJS devs and not enterprise devs or engineers.