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
Latest comments (25)
Good developer decouple his code from the framework and good frameworks support this very much. Bad developers using bad frameworks create a lock in, they shape their application to fulfill the framework needs instead of their needs. Absolutely agree on that recruiters and companies should put much less emphasize on framework knowledge and concetrate on fundamental programming knowledges and skills. Good developers with sufficient fundamentals and experience can use any framework, as it is more of a tool then a skill. Of course it can take time to master a new tool, but it is better to hire a developer with good fundamentals and wait until they master a new tool then hire a person who can only think in terms of one specific framework. I even disagree that one should know and focus on knowing one particular framework in and out, as good framework should have very good documentation to llook up anything that is needed, so it is pointless to fill up our brain with framework specific knowledge, beside they are always changing so what is the point to have our mind filled up with constantly outdating knowledge? When recruiters and companies focus on framework knowledge then this is nothing else than because their incompetence and inpatience. Unfortunately it is a trend nowadays, hopefully will change in the future. Also as a clsing thought, I do not think I am taking on the basis of 20 years experience in the field of software engineering, good developers can master any too including frmeworks in no time provided they are good enough.
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.
Your framework or language is not special, everyone has a favorite language or framework, (in my case php, but that doesn't blind me to others). Programming languages or frameworks are not philosophy but mere tools.
Tools were made to serve their masters and not the other way around. Languages or frameworks not deserve loyalty and are not religions, nor football teams to have fan clubs. I am not defined by my language and you are not your programming language.
Show who's boss!!! The best way to demystify something is to dissect it, to see what is made of, to see who did it, where it came from, what purpose it was created for, stop putting things on the pedestal just because you don't understand anything deserves to stay on a pedestal let alone your language / framework.
Quality series, good job Damnjan thx! 👍👍
Lol :) Hope you are not serious :) It's funny though...
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.
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.
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:
I think understanding on how to use your tool in certain situations is considered a skill as well.
Knowing when and where to apply the framework allows you to have a much lesser time to get started to contribute your skills.
Then again for a company HR side, it's sort of a filter for them to choose a candidate as well due to the number of job applications they receive.
Hi Max,
I agree that learning how to set up a ramework and what is specific for this particular one consume time. But in my experience not rmore than one week. I was able to switch between frameworks in a matter of Day or two.
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