I am fortunate that I have the opportunity to screen the devs that enter our humble abode. We were looking for a Front-End position in our company because of my boss who is also developer is now shifting his position into a product and management side. For that, we need to find someone that will fill that role he will be leaving. Finding one takes time, too. Interestingly enough, Front-End developers are a rare breed in the industry. Or at least those who are interested in working for a “corporate overlord” that is.
This post will cover my thoughts on what I had observed when I interviewed people for the position. This role is a first for me and being on the opposite end of the table gave me some fascinating insight on how applicants try to win our hearts for that matter. I’m just going to write some things I observed and how I discern what we are looking for in the position and how you, either as a new interviewer or applicant should do for this regard.
When you are interviewing, the first thing you need to do is study their resume. It will be your guide to having an idea of what kind of direction you want to take in the interview. Applicants have a diverse career path, and your job is to check whether that path related to your company’s intention. You also need to check if their stories check out. Resume padding is a thing in the IT space. It is where people “overextend” their abilities to what they know. While it may seem like lying, but if you were to ask me, it would depend on the kind of “overextension” they are doing. The thing that is important to me is that you can carry on them, or show that you try to learn them in some way or form. There’s a saying “fake it till you make it” attitude and it not a bad thing, and many people who started out didn’t new much, but the attitude of “making it.” is what matters in the end.
In my case, I look at the skills they listed on their CV; often some applicants tend to put ratings in their abilities. Either a number or a star. I always find that self-serving, but a the same time a show of confidence on how they are proud of their skills. I often ignore that since there is a better way to check if they “walk the talk” later in the post. The next part of is reviewing their work history. Working in IT has many facets, not all of them go toward dev. I often get CVs of people whose primary role in are managerial or leads. At a glance, you would think that they’re just promoted devs, but often the case they are not. I find them the least desirable for a dev position since they are more busy managing teams than writing code. They are the “sea wall” between the actual grunt devs and business managers. Which is another burden that gives that person less time to do actual code? They are the kind of people that say they “code”, but if you work with them, you can tell right away that they know jack shit, by how they do their estimates for tasks. If they put their foot forward for the business, then they haven’t coded in a while.
That is why, while it is easy to dismiss them. We still need to give these people the benefit of the doubt. But consider what I had said above and thread the interview checking if this person is the kind of manager I had described. It may often be the case, but there are exemptions, and that is what I want to discern.
Now this part will be subjective and can perhaps be specific. It depends on what your organisation needs so my thoughts may not be reflective on yours. But I hope that you can get an idea of what I want to convey here. This what makes or break an applicant. Pass, and you get to the final boss (usually). Fail then find another job. While passing the exam wouldn’t mean smooth sailing. Their code can also be a tool to tell you how much their CV is telling the truth.
Finding a manager that can code to those who are more suited to managing people can be seen by the way they code. You can also tell if the ratings in their CV speaks for the skill they mentioned. I’ve encountered both of these. One is a manager who did pass the coding exam, but if you check their code, you can spot some tell-tale signs that it is done poorly. Either that person is declaring libraries that aren’t supposed to be there. To having the a production file being included when it should not be. We didn’t hire them, of course, and these are some of the red flags that look out.
Regarding Front-end work, while this is more of a personal preference than any, If you listed your abilities in the CV and rate them, at least bother to showcase them in your code when necessary. Case in point. Applicants who know how to write a webpack configuration should build their app from scratch, and not use create-react-app (we are looking for FEs with React experience) for the test. While doing the later is okay, and there are valid reasons why one should do it. It is just a wasted opportunity to do it either.
Applying those two parts I mentioned should give you a general aim in your interview. In my case, together with my co-interviewer, we want to make sure that the applicant isn’t lying. The “can you describe yourself” question goes here. One way to spot a lie is that they don’t know their history. Lies are built in sequences, at least poorly built ones. You throw curve balls to the applicant and ask questions about their work history out of order. Then look at the body language. Then there is also that level of over-detailing your role. While perfection is excellent, being perfect also raises some suspicion. I like vague answers since that is an exciting way to start a conversation and we can drill down the specifics through interviews.
Then we also have this “jargon bukake” as I would describe it. It is a part where an applicant goes and tells a bunch of technical words to describe something. I usually get this when I ask something about their previous project. I find that behaviour as a red-flag since it is something people do when they want to hide something. It is also called hiding by obfuscating. The coding test speaks more, and I use that test to determine if he is BSing me. We typically rush the interview upon that point to finish it up.
To give a summary of what I had said. I can boil my points into these:
- Padding your resume is accepted, be sure you can back it up.
- Don’t bother rating your skills. It doesn’t mean anything to us.
- Not all managers can code. It is more of an exception than given.
- We prefer that you use the skill in your CV to your practical exam.
- Make sure you know how your code works.
- We are not impressed by spouting jargons. Knowing those words doesn’t make you stand out.