I like to ask the candidate to do a code review on a pull request. It needs to be something where they'll be able to demonstrate a good grasp of the fundamentals of software engineering, along with a solid understanding of the specific platform they'll be working with. Bonus points if the pull request introduces a couple subtle bugs they'll need to ferret out :)
This is one of my least favorite interview antipatterns: multiple small tasks that only show understanding of one of hundreds (if not thousands) of concepts front end devs should understand. Most things here are easily googleable - why judge someone on something that won't hamper them if they blank on it in the day-to-day?
Pub trivia is fun in the pub but absolutely rubbish for determining if a candidate is good at what they do.
"I mean a large-ish block of real code from the actual domain the candidate will be working in, which will likely offer a strong candidate many opportunities for pointing out how badly it is written"
That might be a bad idea. Interviews work both ways, and you could scare away the best candidates with bad code. Maybe it would be better to show them code and say, "Here's an example of code that could be improved - how would you improve it?"
`this` in javascript is tied to whatever object is calling it. For `User.getCount`, the object is User, but when you declare `func = User.getCount`, and then call `func()`, you are now calling from whatever object `func` belongs to (in this case, the "global" object)
The first call is to User.getCount() - 'this' refers to User, so the function returns 1.
The second call is to a bare function - or more exactly, a function on the global scope - so 'this' refers to the global object, which is window in a browser. So it returns undefined, as there is no window.count.
I just hate the concept that there exists such a stratification, such as the "front end" developer.
I similarly hate the distinction "qa developer" which seems to the ear like parlance for a hobbled, maimed version of an "actual" developer.
It's like HR and technical recruiters are making designs to pay you less, and harp on the fact that you somehow incur less responsibility, solve less challenging problems, and therefore, mostly importantly, deserve to be paid less.
>It's like HR and technical recruiters are making designs to pay you less ...
This is not an accurate description of the primary reason the term "front end developer" exists, and moreover is an unfortunate example of the unhelpful us-vs-them conspiracy theorizing that seems so prevalent lately.
The term "front end developer" exists, like the term "backend developer" to denote a particular specialization. If I need to improve the look and feel of my web app, someone with a strong design sensibility and a lot of experience in the latest web development technologies (i.e., a front end developer) is who I want -- not someone with a lot of experience doing low-level memory management in C for a graphics engine. The latter might be a great programmer, but won't be as helpful, as quickly, as the former.
In any case, frontend developers, as a class, bear no less "responsibility" than others (after all, the frontend is how the user experiences the product), and I think most frontend developers would tell you there are plenty of challenging problems to be solved there, rivaling anything else you'll find elsewhere in the stack.
What sets the price of frontend dev expertise is the same thing that sets the price of every other good and service in the known universe, barring weird regulatory interference: supply and demand. The calculus for a hiring manager is not "how can I pay X class of people less than others", it's "how can I minimize the amount of $$ I have to pay while maximizing the value I obtain?" In an individual case, it's "what's the least I can pay this particular individual in order to get him/her to do what I want"?
> I just hate the concept that there exists such a stratification, such as the "front end" developer.
I disagree, and think this industry needs more stratification.
I started out as an electrical engineer. Unless you hare hiring new grads, you do not hire an "electrical engineer", you hire a "power engineer", "analog engineer", "ASIC engineer", "RF engineer", "digital engineer", or one of the specializations I have forgotten. They are, fundamentally, all electrical engineers. They are not, however, interchangeable. You could certainly cross-train over a period of years, but it still takes those years of experience to gain the specialization.
That stratification does not necessarily imply one specialty is better than another. Some get paid more because there are fewer of them.
I never did well in interviews wherein someone asked me to solve a problem while they watch. Too conscious of their presence, I suppose. Give me time to think without someone breathing down my neck and I can demonstrate my aptitude.
So, seems to me a better approach for some candidates is to allow them to do some of the work from home or otherwise unattended. It's a more realistic work scenario anyway.
But, these types of interviews are de rigueur. Am I that unusual in finding this challenging?
Nope, I used to be somewhat nervous too, when someone was watching me. Not knowing where to begin, doing things slower than normal, losing my train of thought, etc... I did two things to overcome this: 1) showing people source code on my laptop while browsing, navigating and explaining it, and 2) develop new features in a coffee shop with lots of people around. I guess I found the nearby physical presence of someone distracting - but not anymore.
Google has a standard interview process for all software engineers and afterwards you can end up either on in front-end development or back-end development. So they at least think specific knowledge of front-end development isn't necessary coming in.
That's basically how we run things at my company. I'm the front end dev manager and I make the decisions on who to hire for the team. All of my dev's have a set of skills that includes backend dev work, they are just specialists at first end customer facing applications. It's worked really well so far.
Obviously it works for them, but my opinion (coming from another field of engineering) is that this is not a good general-purpose hiring strategy or a particularly good way to manage your internal teams. The field is too broad to say that an engineer with some set of fundamental knowledge can be successfully slotted into any software development position.
Well they still have a standard interview process for them, but maybe there's also a separate one. I joined Google in Novmeber after their standard SE interview process, and I primarily work in FE development (Angular).
20 comments
[ 2.7 ms ] story [ 57.3 ms ] threadPub trivia is fun in the pub but absolutely rubbish for determining if a candidate is good at what they do.
That might be a bad idea. Interviews work both ways, and you could scare away the best candidates with bad code. Maybe it would be better to show them code and say, "Here's an example of code that could be improved - how would you improve it?"
I similarly hate the distinction "qa developer" which seems to the ear like parlance for a hobbled, maimed version of an "actual" developer.
It's like HR and technical recruiters are making designs to pay you less, and harp on the fact that you somehow incur less responsibility, solve less challenging problems, and therefore, mostly importantly, deserve to be paid less.
This is not an accurate description of the primary reason the term "front end developer" exists, and moreover is an unfortunate example of the unhelpful us-vs-them conspiracy theorizing that seems so prevalent lately.
The term "front end developer" exists, like the term "backend developer" to denote a particular specialization. If I need to improve the look and feel of my web app, someone with a strong design sensibility and a lot of experience in the latest web development technologies (i.e., a front end developer) is who I want -- not someone with a lot of experience doing low-level memory management in C for a graphics engine. The latter might be a great programmer, but won't be as helpful, as quickly, as the former.
In any case, frontend developers, as a class, bear no less "responsibility" than others (after all, the frontend is how the user experiences the product), and I think most frontend developers would tell you there are plenty of challenging problems to be solved there, rivaling anything else you'll find elsewhere in the stack.
What sets the price of frontend dev expertise is the same thing that sets the price of every other good and service in the known universe, barring weird regulatory interference: supply and demand. The calculus for a hiring manager is not "how can I pay X class of people less than others", it's "how can I minimize the amount of $$ I have to pay while maximizing the value I obtain?" In an individual case, it's "what's the least I can pay this particular individual in order to get him/her to do what I want"?
I disagree, and think this industry needs more stratification.
I started out as an electrical engineer. Unless you hare hiring new grads, you do not hire an "electrical engineer", you hire a "power engineer", "analog engineer", "ASIC engineer", "RF engineer", "digital engineer", or one of the specializations I have forgotten. They are, fundamentally, all electrical engineers. They are not, however, interchangeable. You could certainly cross-train over a period of years, but it still takes those years of experience to gain the specialization.
That stratification does not necessarily imply one specialty is better than another. Some get paid more because there are fewer of them.
So, seems to me a better approach for some candidates is to allow them to do some of the work from home or otherwise unattended. It's a more realistic work scenario anyway.
But, these types of interviews are de rigueur. Am I that unusual in finding this challenging?