Nahuel Sanchez

A place to write down what I discover and learn everyday at my workplace. Front-end may be the main topic, but who knows, probably I'll be publishing something else.

You're looking at all the posts published under the tag Work experience.
← Go back to the front page

About how hard it is to find a front end developer capable of work with Magento

Is it hard to find someone willing (and able?) to work with Magento. And I'm not talking about finding an already "senior" Magento front end developer with n years of experience with that eCommerce platform and/or working in that specific field.

No. What I mean is that it is difficult to find someone who is already a front end developer but never worked with Magento. Will he be able to? Will he understand and like the platform? Is he willing to despite what he says during the interview?

I already write a post about how to interview a front end developer, and I'm not sure if I strengthened enough the idea of it being a kind of a bet. In this scenario we're betting twice as we not only need to discover if the person being interviewed possesses the skills to be a good developer but also if he or she can perform with a specific platform.

That fuzzy line between back end and front end within Magento

I encountered a lot of different "profiles" while interviewing. While the spectrum is really broad let me summarize this into two groups (nevertheless, not sure about the names I'm giving to them, but bear with me):

  • Web designers, or people focused only on the HTML and CSS (maybe jQuery?) part of the coding process. People whose main task is to convert a given PSD file into "a web".
  • Developers using the "hard tools" for coding complex logical solutions with, and not limited to, JavaScript and all its modern flavours.

The first group is excellent in that PSD to xHTML conversion process but they sort of depend on somebody to add the functionality to their creations, and the later group fails when the QA team compares what they delivered with the original design files.

So, someone in between, right? Right. But why?, because of that fuzzy line between back end and front end within Magento. :)

It depends on how the company you work for is structurated, and how the roles for back end and front end are implemented there, but under my experience I can tell that none of these groups that represents the two extremes of the wide range of developers I interview can work with Magento, or at least they can't on their own as they will always lack what the other groups knows... and we need both on the front end side of a Magento project for it to go live.

Again, under my experience, while working with people that falls into this two categories I either faced the problem of things looking good but not working as expected, or things that do what they're are supposed to do but with so many differences when I open the designs (and if you are thinking "it's only colors", think responsive web design).

How we find that "in between"?

Spoiler alert: I don't know for sure, but I can tell you what I'm doing right now and hopefully it will help you achieve the same as I'm looking for if you're conduction interviews.

I recently had a meeting with somebody from the recruiting team at the company I work for in order to polish the "mechanism" to identify people too attached to the mentioned groups in order to dismiss them at the beginning of the process, and there are a lot of hints in the candidate's CV that you can use.

Exhibit A is this imaginary resume that includes skills such as HTML, CSS, SASS and jQuery, which is excellent because we need those skills. Following we find a lot of background experience building corporate websites only, but never using a CMS as there is no mention for WordPress, Joomla, Drupal, or similar.

Finally, the work experience is a mix of marketing and design, mostly a transition from the later to a developer. The court rules guilty for being too much of a member of the web designers group.

A second example is this also imaginary resume that includes all the fancy words I already used to, such as Angular, AngularJS, React, VUE, Node... you name it... and a background experience that mostly includes working on the back end side of some sites.

I don't have to tell you to which group this imaginary candidate belongs to.

So, again, someone in between. Find that resume that have a mix of the trending topic's keywords for the first and second group, and you got yourself a feasible Magento front end developer. Or work the other way around: burn the resumes that falls into the extremes and what lays in the middle is the people you should interview next.

No group is better than the other

Don't get me wrong... or let me clarify.

I do not think one group is better than the other one, and if you belong to the first one there's no obligation to learn what the other group knows, neither the other way around.

Let me put another short perspective into this: if the company you work for (or the company you applied for, or your company if you happens to have one) really separates this two groups into really two separates job positions, and if you only have to worry about the PSD to xHTML thing because somebody else is handling the functionality... good for you, and go for it, as again this depends on the scenario you're standing.

That's why I mentioned something about the way a company is structured before, because in some places you might not need to worry about the "in between" as it doesn't apply.

Happy hunting.

How to interview a front end developer and not die in the process

Being an interviewer it's not an easy task... well, of course it might be harder for the one looking for the job, but the candidate's chances of getting the job depends not only on the candidate's technical skills but also on the ability of the interviewer to rule on the truth of those said skills in a 60 minutes talk.

I started conducting front end interviews about two years ago, probably, and it doesn't became an easy task as days go by. The "interview techniques" and the "tricks or treats" gets better as more interviews I get done, but at the end of that hour of interview I need to walk to my boss and answer one not simple question: Nahuel, should I hire that guy or not?

If No and the candidate's seniority was really high but I couldn't tell during the interview then the company loses a good resource, but if Yes and the candidate's skills wasn't as near as good as I though during the interview then everybody loss time. It's too much pressure!

How to actually interview somebody

There's no answer to how to actually interview somebody, so don't expect to get the answer to life, the universe and everything by reading this post.

You can Google "how to interview a front end developer" and you'll get a lot of techniques. My suggestion is that you should pick the one that makes you more comfortable, start interviewing with it, and then you'll mutate it to fit even better with you personality, your interviewer's skills, and your (or your company) needs.

What I can do is give you my technique, it might help you if you're conducting an interview for the first time.

What questions needs an answer at the end of the interview?

It's necessary to have in mind to what questions you need answers, otherwise the interview it'll just be a talk and you'll get nothing of it.

  • Will the candidate be able to use the techniques/technologies/programming languages/whatever your company use on the daily basis? In other words, will the candidate be able to do the job you're interviewing him/her for?
  • How is the enthusiasm or learning skills of the candidate? In other words, how do you think the candidate will handle techniques/technologies/programming languages/whatever the candidate doesn't handle at the moment of the interview but it's required in the work daily basis?

And I have a third question someday Human Resources asked me but I'll save it for the end because of drama.

Evaluating programming skills in a friendly conversation

It's almost impossible, or at least really not accurate by itself.

The interview process doesn't start or end with a face to face interview. In my case it starts when HR says to me that somebody applies for the job position, and I can start evaluating the technical skills of the candidate at that moment thanks to the fact that we as a company ask the candidate for code examples.

That code example is really important for the interview process and helps to evaluate the programming skill of the candidate because it's real life work. It's code they really write for a real job (as long as the candidate it's not lying), so it's probably the job I'll get done by the candidate on his/her first day at the job if I hire him/her (it's a start and the candidate can only improve on that point. Theoretically, very theoretically).

Not always the code send by the candidate helps me. Sometimes they send me a GitHub URL (which is great), a ZIP file (which is nice), or an URL to show a full website they developed (which is sometimes a bummer).

Short story: once somebody send us the URL to a National Geographic website. I can believe you that you code part of it, but since it's a huge projects I know you weren't the only one working on that webpage so it's kind of impossible to know the parts of the code you actually developed.

Back to the code example, I try to get as much accurate as possible the candidate's seniority since he/she won't be able to code something complex during the face to face interview.

Going live: Face to face interview

Tell me about a project you had, any project you want, from the beginning to the end. Starting with the client entering the company and saying "I need this", going through the planning process, the design process, the development process, your relationship with the team, how do you interacted with the back end developers, and the day you delivered the project to the client.

That's how I start the interview. It allows me to detect in which parts of the process the candidate it's involved and what he/she did on those said parts.

As the candidate speaks I can either hook up on specific keywords or write them down to go deep into specific subjects later. Like, "you mentioned the website was responsive, how did you face that requirement?", and then the candidate talks again and I repeat the technique until I have all the data I need.

The hard technical skills during this talk are very hard to detect (that's why we had the code example on the first place), but I get a glimpse of the previous candidate's daily work.

The props during the face to face interview

It's not like I interview hands empty. I know I can't give the candidate a computer and a real JIRA's ticket to code, and it wouldn't be fair to ask the candidate to code something complex with a paper and pencil in front (pff, like I can do it).

Knowing that, I hand over two exercises that can be solve in around 5 minutes: the first one it's a request to use CSS to resolve a simple requirement, and the second one it's a simple logic problem that can be solve with conditionals and control statements (you can use JS, PHP, whatever you want, even pseudocode).

The two exercises can be solve with around 15 lines of code, they're really simple. They don't need to work if I copy them to a computer, it's not what I'm expecting. I want to see how you react and act to a logic problem, I need to know how would you confront this short notice problem.

They are so simple it might not help me to understand how good the candidate can code, but trust me when I say that this exercises rules a lot of people out when I see they can't solve them.

Decision time: to hire or not to hire

Get back to the initial questions and you'll be able to make a decision. Also, as I said before, I have a third question that helps me when I'm not sure if I should proceed with the candidate or not.

Would you work next to that person on a project?

Assume you hire the candidate, would you like to work with him/her?. And don't think you'll be sharing a beer. Would you share a project with the candidate?

Try to answer that and you'll end up saying things like "Well, he's lacking some technical skills but he learns fast so yes" or "Mmm, I think he won't be able to handle the technical pressure of the technologies we use so no". This last question might save the day.

This is what I do, this is what I can share with you. Good luck on your next interview on the other side of the table.