Magento is a leading eCommerce platform. Being open-source, it provides full control over an eCommerce website and allows unlimited space for growth. One can build an empire on Magento.
The Magento community is full of developers working hard to provide updates and new integrations for business growth. But when it comes to customizations, a company needs to make sure that it has dedicated Magento developers who are professional and have the company’s best interests in mind. It is easy to leave back doors open or otherwise botch a Magento project with poorly written code.
Those trying to cut costs too much will end up paying twice—this is especially true in the context of Magento development services.
Pre-project Check: Is Magento Itself a Good Fit?
There are a number of good reasons Magento is so popular:
- Magento has a large community.
- Magento is highly scalable and customizable.
- Magento’s paid (commerce) version has additional features.
- Magento allows multiple eCommerce websites on a single installation.
- Magento is PCI-compliant.
- Magento can work for any business.
- Magento allows full control over the resulting eCommerce website.
- Magento is open-source, which allows for the development of custom integrations (e.g., synchronization with ERP systems).
- Magento is suitable for international shopping by meeting country-specific needs.
- Magento allows an online business to sell high-risk or controversial items.
- Magento can integrate with Amazon, eBay, Walmart, and Rakuten.
That said, Magento does require competent administration and development—something that may be out of reach for small businesses, depending on their needs and resources.
For those already confident in their choice of Magento, the next step is knowing how to land a great Magento developer.
Magento 2 Technology Stack
Like Magento 1, Magento 2 is not a language, but a platform. It’s built on the following web technologies:
- PHP
- MySQL
- HTML5
- CSS3 (and the Less CSS preprocessor)
- JavaScript (and jQuery, its primary JavaScript library)
- RequireJS (the library that helps load JavaScript resources on demand)
- Knockout.js (which simplifies JavaScript UIs with the model-view-viewmodel pattern)
- Third-party core libraries (Zend Framework 1, Zend Framework 2, Laminas, and Symfony)
However, hiring a developer that knows them is not enough to be successful. Like in any other field, experience matters. Even a simple project’s local setup can be challenging without experience. (Hence the importance of Magento certifications, which are covered below.)
Being a popular eCommerce solution, Magento is huge and very powerful. It has its own rules and best practices. But so do the technologies it’s built upon. For example, the best Magento developers will be in the habit of conforming to PHP coding standards like PSR-0 (autoloading standard), PSR-1 (basic coding standards), PSR-2 (coding style guide), PSR-3 (logger interface), PSR-4 (autoloader).
Magento Versions: Magento 1 and Magento 2 Are Significantly Different
It’s worth highlighting that there are two completely different Magento versions. This means that when choosing a developer, both developer and client will need to be clear about the Magento version to be used. Magento programmers with knowledge only about Magento 1 will need quite a lot of time to get familiar with Magento 2.
Greenfield projects should definitely use Magento 2. Magento 1 is now considered a legacy technology, despite still having a significant installation base. Many companies have projects underway to migrate their version 1–based eCommerce sites to Magento 2.
Migration from Magento 1 to Magento 2
Magento 1 officially reached its “end of life” date, which means that the core Magento team no longer provides any updates to it. Developers have focused on Magento 2 for some time now, leaving Magento 1 behind.
If you are looking for a developer to migrate to Magento 2, the key is that Magento 2 migration requires both knowledge and strong experience with both Magento 1 and Magento 2.
When it comes to Magento migration, there are three main topics to discuss.
Magento 2 Migrations: Theme
A theme would need to be migrated manually. This means full theming development from scratch, unless the Magento theme in question is available for Magento 2 as well. In this case, it’s as simple as getting the new theme version and installing it on the Magento instance.
Magento 2 Migrations: Modules
Modules purchased from third-party vendors most likely already have Magento 2 versions, so this should also be as simple as getting the new version and installing it on the new Magento 2 platform. Custom-developed modules would need to be migrated manually.
Magento 2 Migrations: Database
Magento already has scripts to migrate a database. A developer would need to configure and execute them.
There are also scripts for a delta update, which means that after the main database migration, Magento programmers can run separate commands to synchronize only products, orders, and customers (the data that is constantly growing/changing). These allow a site to run both versions simultaneously and perform a delta update during the go-live process and actual Magento website switch.
The Hiring Process: Candidate Requirements
To find a great Magento developer, there are quite a few things worth considering. Besides the technology stack mentioned earlier, one of the first things to look at is Magento certifications. Let’s have a quick look at the main certifications, which are easy enough to verify.
Update: The certifications listed below are still useful, but interviewers might see some candidates with Adobe’s even newer certifications. Many of them don’t have a direct equivalent to each of the below specializations, but are describe in detail on Adobe’s site.
Magento 2 Solution Specialist
Note: There is also an equivalent Magento 1 Solution Specialist certification.
This certificate is oriented on admin panel knowledge and understanding business processes. It’s not oriented toward Magento code customization; developers usually pass it to get a better understanding about the business processes and Magento built-in features, not development itself.
Such certification is always a great addition to developer competencies, especially if you are looking for a developer that would be capable of advising you and guiding you in eCommerce decision-making.
Magento 2 Professional Front End Developer
The front-end developer exam is meant to validate theming and UI skills. Recommended for companies looking for a person to work with the user-facing parts of Magento.
Magento 2 Associate Developer
The associate developer exam is for Magento developers that are just starting their Magento 2 journey. It touches the very basics of common Magento customizations and best practices. This certification covers all main areas like the front end, back end, and database. The candidate with this certificate will have basic Magento customization understanding.
Magento 2 Professional Developer
Note: There is also an equivalent Magento 1 Professional Developer certification.
Having “Professional” in the title already says quite a bit. It’s not easy to find many Magento developers with this certification. Companies can give very complex tasks to such a developer and rely on them as a Magento 2 expert who will deliver quality results.
Magento 2 Professional Developer Plus
Note: There is also an equivalent Magento 1 Professional Developer Plus certification.
This one is quite similar to a professional developer, but this exam includes Magento Commerce (which can be thought of as EE, or enterprise edition) customization questions. If you see a developer with a professional plus certificate, they can pretty much be taken without any doubt. Professional Developer Plus certificate holders are Magento senior developers who can lead your project and engineer solutions to problems of any complexity.
Magento 2 Professional JavaScript Developer
Not the most popular certification, but still good to have. JavaScript is heavily used in the Magento checkout process. For companies looking for a developer to greatly customize their checkout, the fact that a candidate has this certification should inspire more confidence.
The Hiring Process: Interviewing
When it comes to Magento, there is a fine line between front- and back-end developers. Developing a Magento-based front end also means dealing with the back end to develop blocks, templates, and layouts. Hiring a front-end developer who is only an expert in stylesheets and JavaScript will result in struggle. Make sure that the candidate has a basic knowledge of the Magento back end.
When lining up requirements for a developer role, it’s best to separate Magento development from support. Magento support developers should definitely be Magento experts; candidates with at least a professional developer certificate are recommended. Magento has quite a complex structure and tons of dependencies the developer should be aware of; support requires a perfect understanding of ongoing and interdependent processes to make sure that fixing one bug won’t create another. Troubleshooting starts in the mind, and with Magento, it’s very easy to go the wrong debugging direction if you do not fully understand how it works.
The support developer should also be a DevOps engineer. This means that they should have basic knowledge about server setup and administration. There might be cases when your live eCommerce site can go down, and they should be capable of dealing with it. For unplanned Magento jobs, where they need to act fast, you definitely want to have highly experienced professionals.
In contrast, feature development requires a bit less overall Magento architecture knowledge. Building a module, Magento developers already know what parts of the Magento core it will modify or extend. Having this information in mind, it will be easier to decide which candidate fits better based on their previous experience and skillset. But you never know what the cause of a Magento eCommerce site being down or extremely slow could be.
In selecting a developer, it’s a good idea to see candidates in action. With a senior developer on board, a small pair-programming session is a good way to review and see if the candidate will fit the development team. Usually, some minor Magento module development works to review the developer’s local setup and development techniques.
Alternatively, companies can ask for already developed modules the candidate is proud of, to review them, see the code, and walk through it on a call with an in-house senior developer.
Interview Questions
These questions will help make sure candidates have the right kind of Magento experience. They’re specific to Magento, and every worthwhile Magento developer should be capable of answering them. Please note that this set of questions is mainly oriented toward Magento 2.
Q: Describe the key architectural differences between Magento 1 and Magento 2.
A question if your candidate is familiar with Magento 1 as well.
-
Folder structure changed: Everything is placed under the
app folder.
- Dependency injections added
- Composer package management added
- Support for the latest PHP versions (7.*)
- CSS preprocessor (Less)
- Full page caching
- RequireJS and Knockout.js added
- HTML5 and CSS3
- Command line interfaces added for clearing the cache, reindexing, etc.
- Symfony, which was a third-party library in Magento 1, became part of the core of Magento 2.
Note: Differences between Magento 1 and Magento 2 that every developer should be able to list are highlighted in bold.
Q: List the Magento 2 technology stack.
- PHP
- MySQL
- HTML5
- CSS3 (and the Less CSS preprocessor)
- JavaScript (and jQuery, its primary JavaScript library)
-
RequireJS (the library that helps load JavaScript resources on demand)
-
Knockout.js (which simplifies JavaScript UIs with the model-view-viewmodel pattern)
- Third-party core libraries (Zend Framework 1, Zend Framework 2, Laminas, and Symfony)
Note: Parts of the Magento 2 tech stack that every developer should be able to list are highlighted in bold.
Q: List Magento 2.3 server requirements.
- Linux
-
PHP >= 7.1
- Database: MySQL, MariaDB, or Percona
- Web server: Nginx or Apache
- Redis (optional)
- Varnish (optional)
- Elasticsearch (optional)
- RabbitMQ (optional)
Note: Server requirements that every developer should be able to list are highlighted in bold.
Q: How would you extend a public method from a third-party module in Magento 2?
Magento 2 has introduced a new way of extending public methods, called plugins, which come in three types: before, after, and around. This is very specific to Magento, and if interviewers don’t hear the word “plugin” in a candidate’s answer, it should be considered a red flag.
Q: How would you overwrite a JavaScript component method in Magento?
The common bad practice here is that some developers simply copy over (override) JS files and then change them. Magento 2 best practices instead entail that developers should modify the core as little as possible.
When developers copy over a whole file, there is a bigger chance that Magento will make some adjustment in a future release, but the copied file will override it (lacking the new changes) or otherwise become incompatible with changes in the new release.
When overwriting a Magento component method, the best practice is to create a mixin, which would overwrite only one specific method. That said, it’s most important to hear that the developer is familiar with a customization technique that doesn’t involve overriding the whole file when they need to modify only one method.
Q: What problem could be caused on a Magento 2 front end by defining the attribute cacheable="false" in an XML
Adding this tag to any
Q: What is the important part about templates and multi-store development when it comes to multi-language compatibility?
Hearing about multi-store and multi-language compatibility, the only concern would be to make sure that strings are translatable. A very common problem is Magento developers adding custom strings into templates without making them translatable for other online store views.
Q: How do you make sure your code fits Magento 2 coding standards?
Expected answers would be reading documentation, following best practices (the Magento Coding Standard), and configuring their code editor to make automated code checks. The key words here would be Magento-prescribed PSR code compliance and usage of PHP_CodeSniffer. If a developer doesn’t mention PHP_CodeSniffer, it means that their back-end code most likely won’t match Magento standards.
Q: How do you debug PHP code in a Magento 2 app?
The most popular tool is Xdebug. If a candidate answers using the PHP function var_dump, it means that they will greatly overspend time on your project—especially on support tasks where proper debugging is a must.
It is not necessary to use Xdebug only (there are other debugging tools as well), and sometimes, it can be combined with PHP debugging functions.
The main point would be to understand if the candidate is familiar with Xdebug and is actively using it.
Q: List invalid use cases for a Magento 2 plugin.
Magento 2 plugin usage is limited. It can’t be used for:
- Final methods and classes
- Non-public methods
- Class
__construct methods
- Virtual types
It would be acceptable to hear that plugins can be used only for public methods, since that is the most popular phrasing of this rule—a developer should definitely know it, since they’ll need it very frequently when customizing Magento. Other points are very rare to face daily.
Q: How would you override a Magento 2 core class’ public or protected method when plugins and observers are not an option?
When observers and plugin are not an option, Magento developers can use preferences. Preferences are declared in di.xml files and can be scoped to the front end and/or back end.
Preferences are mainly used with protected or private access methods, since plugins can be created only for public methods.
Sometimes, developers have to use preferences, like when they necessarily need to inject some functionality in the middle of the method in question. This is because plugins are mainly used to modify method parameters and returned values.
Preferences are considered a last resort, since they completely override a method and reduce system upgradability.
Q: Describe the purpose of (and sole use case for) view models.
This is all about injecting custom functionality into templates. Since Magento 2.2, developers can use view models for this. Before that, the main way was creating helpers.
The recommended (best practice) is to use view models instead of creating new block types.
Q: What problem could you face by running setup:upgrade in Magento production mode, and how can you avoid it?
This command would clear out Magento compiled code, and in Magento production mode, it needs to be manually recompiled using other commands. Cleaning generated content without immediate recompiling would completely break the front-end experience, as well as the back end.
In cases when Magento developers need to execute this while making sure that generated content stays put, they need to add the flag --keep-generated, i.e., setup:upgrade --keep-generated.
Q: What has changed since Magento 2.3 regarding database update scripts?
Magento 2.3 introduced declarative schema and data/schema patches.
Declarative schema allows you to simply create a db_schema.xml and define table parameters there, instead of writing long database CREATE methods in InstallSchema.php.
Data/schema patches introduced a structured way of applying database changes, since every logical part of the change is handled in its own patch. Previously, developers created lengthy, mixed UpgradeData.php scripts.
Q: What is a service contract, and what is its purpose?
Service contracts are module-defined PHP interfaces. The main purpose is to define strict communication rules to ensure that other modules can implement them. They also make it easier to configure a service as a web API.
The answer here could be quite complicated for a less technical interviewer, but hearing key mentions of “PHP interfaces” and “web APIs” is a good sign already.
Defining a company’s eCommerce needs is the first step in understanding what they are looking for in a candidate and which Magento areas this person should be experienced at.
Magento has very broad functionality, and it is easy to bungle an eCommerce store. Magento development does not succeed with a “cheaper is better” mentality. Bad code will lead to performance issues and a poor customer experience—which themselves will cost companies in lost sales—and will guarantee future Magento upgrade and compatibility problems.
Screen well, and expert Magento developers will be a lot easier to connect with.
