To find the last new hire, 95% were weeded out just based on resume for lack of experience, or non-relevant experience. Of the remaining 5% who made it to a phone screen, 80% were weeded out because they could not convince me that their knowledge matched their experience (e.g. 10 years of Javascript but they can't explain Function.prototype.call() or Function.prototype.bind()). The rest who passed the phone screen, the decision to not make an offer came down to personality fit or geography (quite a few people were out of state, and would not be able to move here quickly).
I think that's interesting. I understand that you're looking for someone with basic/foundational knowledge - but can you really judge them on not knowing (or be able to explain) a specific function?
Wouldn't it be better to ask a problem and see how the person might solve the problem?
Of course I would never eliminate anyone on the basis of not being able to explain a specific function. That said, there are some questions you can ask that if the client can't answer correctly usually further questions only confirm my initial suspicion. These aren't brain teasers or anything like that. For a Javascript developer with 10 years of experience not to have even encountered bind(), apply() and call() is telling. Maybe it's just interview nerves, so you can ask a followup, like:
let's say you have a callback function cb that is going to be called by some async process, and in this callback we refer to this.method(). At the time we defined the callback, "this" referred to someObject. How can we be sure that when the callback is called, this.method() refers to someObject.method()
In nearly every case where the candidate could not tell me about bind(), call(), or apply(), they can't explain a clean way to do what is described in the followup (e.g. pass your callback as cb.bind(this)).
Maybe the problem is that you're asking questions built around bad ways of writing code, that good developers simply avoid. bind() doesn't even work on IE 6, and nobody in their right mind would pass a callback function around that uses "this" and later check that "this" refers to the same object.
How is modifying the context of a function related to "bad ways of writing code"? Using `bind()` is absolutely common, and even game way to new syntax (arrow functions) in ES6. In any case the point here is to ask a very practical question that anyone with minimal experience with the language should be able to answer.
If you're writing a function that uses "this"... and using "bind" at where the function expression is written, you should just name the object itself and refer to it in the function body that way. If you're defining the function one place with the expectation that "this" is bound to the right thing by code in another place, you should make your function take an explicit argument and pass it that way. That's how.
That would still be a satisfactory answer, and demonstrate that the person has the necessary knowledge. You need to know how to manipulate `this` before you can reach the [subjective] conclusion that it is bad code.
The thing is, if you're interviewing and throwing away candidates because you're expecting knowledge of stuff that, for example, doesn't work in IE 6, or is based on your specific way of writing Javascript code, you're just throwing away good candidates.
(Also, coding standards are not subjective. Some ways of writing code are more productive than others. The idea that it's subjective is nice to believe, because then you can pretend that nobody is wrong.)
I would question anyone who cites IE6 as a reason for coding a certain way in 2015. IE6 hasn't been relevant for at least 5 years now. But if a candidate said that he was familiar with bind() but would avoid it for the sake of compatibility with IE6 that at least shows familiarity with it. Using your logic, it would be ok for a candidate to say he had never heard of transparent PNGs because IE6 doesn't support them.
I'm citing it as a reason for somebody not being familiar with it. IE6 certainly was a restriction in some environments in the past five years or less. And that's on top of the reason that there's no good reason to use bind in what many people consider to be reasonably written code. Knowledge of these sorts of library features is a terrible proxy for actual ability to write good Javascript. There are better ways to test for that in a phone screen.
It's still relevant today, unfortunately, in some industries where upgrading is prohibitively expensive.
E.g., you'd need to buy a new POS system, or paid millions to have custom-made medical software recertified (or re-written) to work on a newer browser, etc..
It's much rarer -- most places have bitten the bullet by now -- but I still see it (and IE7 is certainly still around).
I'm continually amazed when I hear numbers like this. For the last two frontend hires, I went through maybe 20 resumes (resume reviewing, phone screens, and in person interviews). A few were personal referrals. One of the hires was a referral of mine from IRC - he turned out to be an excellent hire.
IMO, some of what you describe sounds like the wrong way to hire. Stuff like Function.prototype.bind can be easily found By Googling. You want candidates who can adapt to the unknown. I remember a well-known PHP developer in the DC area telling me a story about him guest interviewing candidates for a friend's company - he asked a lot of intense edge questions about PHP to candidates, and only one would give him straightforward answers about not knowing the answer and being willing to Google the answer. That candidate ended up being a phenomenal hire for that company.
Stuff like Function.prototype.bind can be easily found By Googling. You want candidates who can adapt to the unknown.
That is true, but it is a warning sign that someone with 10 years of working with Javascript has never had to use those functions (even if they had to Google it 5 years ago, they should remember it now). It would be like hiring a driver with 10 years of experience who didn't know what the parking brake was for. Granted it is possible to live your whole life in a flat state and never have to use it, but that's rare, and even if true, I want a driver who has seen at least a hill or two.
Once you've passed the basic questions like this, we definitely get to more difficult and tricky questions, and even a question that has no answer to force the candidate to either BS or admit he doesn't know.
I still prefer to give a candidate the benefit of the doubt there, unless there is more supporting evidence.
I have more sympathy towards people who may have not been fortunate to have seen the more challenging aspects of development and help them get there - only 2 1/2 years ago, I was unemployed for the past 2 1/2 years out of grad school without any company having given me such a shot at any career, and here I am now as a lead frontend engineer who is trusted to solve any problem thrown at me and build a team. Just as I was pissed off that so many companies were originally dismissive of me despite my education pedigree, I try not to be dismissive of candidates because they didn't happen to use [insert feature]. Stuff like that is easily studied or taught, and I evaluate almost wholly on things that (almost) can't be studied since it pre-empts candidates from giving me answers that hide important characteristics about them.
I understand what Function.prototype.call() does (and I'm an amateur ruby dev), I don't know what .bind() does but could go for a wild guess. Explaining something like this, might be more tricky. However with 10+ years of experience I'd expect someone to make rounds around things like that.
On the other hand an excellent hire might be a cheat that put the effort to become a good developer once he joined the company or... You might hire a very promising young man who (because this or that) he ended up being a bad hire.
I think that's a false dichotomy. It's not simple to separate "personality" from "technical". A person's personality is what drives them to acquire technical skills. Candidates with a curious, open minded personality will spend more time acquiring technical skills than more passive or close minded candidates will. In my experience it's rare to see someone with solid technical skills that doesn't have passable interpersonal skills too. Learning is just too social.
This plays out at a larger scale too - some cultures are more open to borrowing from other cultures, and some are more closed. The more open ones utilize better technology than the closed ones.
In my experience it's rare to see someone with solid technical skills that doesn't have passable interpersonal skills too.
I've worked with some developers who are brilliant technically, but are not people you would hang out with outside of work. You don't want to duck out or pretend you have a doctor's appointment just to avoid going to lunch with a coworker. You also don't want an arrogant know-it-all on your team, even if he is a genius with code. I remember interviewing a guy and asking him how he would accomplish something in PHP, and he said "PHP sucks, I would write it in a real language." That's the kind of person you don't want to hire to work on a PHP app.
I don't think "would hang out with them outside of work" or "would make a good lunch mate" is the right way to think about personality fit when hiring. I've had many effective coworkers and employees that I didn't spend any time with outside of work. If you can't work with someone that doesn't click perfectly with you, shame on you, not them.
'That's the kind of person you don't want to hire to work on a PHP app.' Definitely. I would also be surprised if they were even technically capable of giving a good answer, given that attitude.
'You also don't want an arrogant know-it-all on your team, even if he is a genius with code.' Agreed. And since nobody else wants to work with someone like this, this type has a tendency either tone down their attitude or to get weeded out before they can really grow technical expertise. I've interviewed hundreds of people and can only think of a couple of examples that were close to that, and those were either for internships or people fresh out of college. Do you often run into people that are technically a great fit but are too arrogant to hire?
There are many facets to personality, some of which (like curiosity) will relate to technical skills (acquired by finding interesting things to learn). But you will also see technical skills acquired by non-personality reasons (like plain old work and academic experience), and you will also see personality traits (like arrogance) that will have very little to do with the technical skills you are exploring. If you rely too much in linking the two in your interview, you will probably reach incomplete and biased conclusions about the candidate.
However, you are correct in that there are correlations between them that you can use to guide the interview:
I've read this is Mark Zuckerberg's policy when hiring people to report directly to him. It makes sense when hiring management positions, but there is a lot of room in organizations for people that aren't going to manage others and don't necessarily need the skills, experience and interests that make good managers.
The question I ask myself is the above. If I would not work for a person because, perhaps there is something fishy or it is not a good fit, I will not hire him.
I try very hard to focus on what the candidate knows. Most of the other stuff is bullshit anyway.
Recent interviews:
- A somewhat well-known poster here, the kind of coder who parachutes in when startups are having trouble shipping and need help. Didn't actually know the programming language very well, which is sadly common amongst coders of the language in question. Sometimes that's ok, but this person presented themselves as an expert in the language and did not know very basic things about it.
- Again, not very strong with the language, but very strong in other languages and overall quite an impressive candidate. I recommended to hire this person, but for a different engineering role. Got hired for a different role and is doing a great job.
I had an interview pretty recently where, I'm positive the interviewer came to the conclusion that I didn't know the language despite years of experience because I made some embrassing syntax mistakes during a phone screen. This was something I know, is very basic and core to the language but I hadn't done in a while because it's a construct that is explicitly disallowed in the code base I currently work in.
That sucks! I think it's unfair to ask candidates to write code on the spot. You're already nervous, and if you don't have your computer with you then you're totally out of your element and without the tools you normally use. We have a small coding exercise we ask candidates to do at home in their own time. I think it's much more fair that way.
In the interview itself, as I said, no coding. Sometimes I will ask the candidate to spot bugs in a function, or read code and say what it outputs, or have a whole function written with one thing missing, and ask what's missing. But asking the candidate to create something where nothing yet exists is not fair, I think. Whiteboard coding and all that, it's no good.
When I say the candidate didn't know the language well, I meant conceptually. Like, imagine if someone told you C had a built-in array type, for example. It was that sort of thing. And remember, this was a person claiming expertise.
We don't use coding in interviews partly for this reason -- but more importantly, it sounds to me like the problem here was partly that flub, but possibly more an issue with your communication skills.
One of the principal things I look for in candidates is ability to speak comfortably about their thought processes & confidence level -- because it's so much more valuable to have a developer say "well, I can think of two ways to solve this, but I'll have a much more solid answer if I can take 10 minutes to refresh my memory on a project I did 5 years ago" than one who says "there are 2 options".
This shows up in interviews (and I look for it); if you give a wrong answer to a question, but you seem to be confident, that's bad. If you give the same wrong answer, but you mention that you don't use the construct (and thus aren't fully confident on your response), that can even be better than giving the right answer.
An interview that only saw correct answers can easily be less informative than one that ran into areas of uncertainty -- because it's crucial to see how they handle that. Do they realize they're guessing? If not: don't hire. Are they comfortable revealing uncertainty or missing knowledge? If not, don't hire.
Ideally they should know how roughly how confident they should be, and also know how to get to a better answer quickly. Real development isn't at all like a closed-book test, and interviews that operate like a closed-book test aren't useful for that reason.
I find a lot of candidates with tons of college experience and theoretical knowledge, but no grease under the fingernails... no practical experience building real systems.
- Candidate could not form coherent answers to my questions
- Candidate was lacking in fundamentals in his/her domain
- Candidate could not demonstrate a good critical thinking ability
The first was a total dealbreaker on a phone screen.
I prefer strong critical thinkers, and am willing to eschew complete knowledge of a domain from a candidate and mentor him/her up to speed, but weak critical thinking is nearly a dealbreaker for me as a manager.
I have been extraordinarily happy with all the people I have hired so far.
I agree about critical thinking, but how do you test it?
I've seen signs of poor logic crop up just when going into detail about past experience; but otherwise it can be hard to see -- particularly when the candidate has been working on projects where someone else was providing technical leadership.
I do ask candidates to go through a thought exercise -- basically a software dev related puzzle requiring no special knowledge (except a bit of basic crypto). Something like "here are the 5 constraints; walk through how these 3 scenarios would work" -- no code involved, but requiring the ability to convert constraints and goals into step-by-step instructions.
This has been pretty useful (there's a surprisingly huge range in the types of responses I get) but wouldn't reveal much about how good someone's choices would be deciding how to implement new features from scratch, for example.
I task candidates with problems, and then I ask questions as the candidate attempts to solve the problem to learn what the candidate is thinking, and how the candidate approaches the problem - solving the problem isn't important to me, but seeing how the candidate works is. I'll ask questions like "Why did you choose [insert data structure]?" or "Why didn't you approach this problem [insert way]?" or "Why did you approach this problem this way?", or even questions like "What would happen if you chose to do it [insert way]?" You also find out a lot about the person's knowledge as well.
I don't necessarily expect perfection in code design - I can help teach that, but a good foundation is paramount.
Because the candidate couldn't write a JavaScript function that allows chaining method calls on its result... along the lines of myFunction().setAttr('a').setAnotherAttr('b').toString(). In my experience, candidates either tackle this in 5-10 minutes, get close and finish with some hints in 20-30 minutes, or have no clue.
If it goes well (first scenario), I like to spend the rest of the interview pairing on a task like writing a parse method for a Backbone model that needs to transform a response for a charting library or something like that with Underscore/Lodash.
One time, a candidate started checking emails on his phone during an on-site interview. That candidate wasn't hired.
function myFunction() {
var a, b, func;
func = function () {
return {
attrA: function (attr) {
a = attr;
return this;
},
attrB: function (attr) {
b = attr;
return this;
},
toString: function () {
console.log([a, b].join(' '));
return this;
}
}
}
return func();
}
This allows us to call myFunction multiple times, set attributes (imagine it were createPerson instead, with a name, age, etc...) and not run into problems with state being shared.
I like this question because it covers closures, this, objects and functions. It also doesn't qualify as a brain teaser, IMO.
That's debatable. It requires a piece of unusual thinking ('return this'), and a bit of magic (knowing about the 'this' magic variable), but once you've seen it, the answer's obvious, and it's pretty easy to replicate everywhere.
Understanding 'this' is foundational when it comes to understanding JavaScript, IMO. So, I don't think it's that unusual. Out of curiosity, what's another question that demonstrates a solid understanding of JavaScript as a language?
I'll bring it from the other angle. I know why I wasn't hired (though I wasn't told):
- No formal background
- I don't code on the spot, and not on a whiteboard with zero resources but rote memory
- I'm not "senior" enough (with >15 years in roles with progressively increasing responsibilities and contributions)
- Buzzword trivia was fun in 2003. Not so much.
- Had an off day
The roles I've been hired into where I wasn't subject to a dog and pony show have arguably been the best, as I've been approached as a person and a professional, and not as a little blue box filling an opening in the calendar.
There is no rule as to what the reason is.
Firstly, the person must be a good fit for the team - a team player, right values, work well with the other members, be self driven, passionate etc.
If that is ok, then secondly they've got to be able to do the job! Technical skills must align to the salary they are asking for - if they are expensive resources then they really need to do what they say they can. If they are not so expensive then there is more room for new learning and basic growth. None of this is possible without the right attitude.
Successful candidates must have both.
40 comments
[ 3.1 ms ] story [ 82.3 ms ] threadWouldn't it be better to ask a problem and see how the person might solve the problem?
let's say you have a callback function cb that is going to be called by some async process, and in this callback we refer to this.method(). At the time we defined the callback, "this" referred to someObject. How can we be sure that when the callback is called, this.method() refers to someObject.method()
In nearly every case where the candidate could not tell me about bind(), call(), or apply(), they can't explain a clean way to do what is described in the followup (e.g. pass your callback as cb.bind(this)).
(Also, coding standards are not subjective. Some ways of writing code are more productive than others. The idea that it's subjective is nice to believe, because then you can pretend that nobody is wrong.)
E.g., you'd need to buy a new POS system, or paid millions to have custom-made medical software recertified (or re-written) to work on a newer browser, etc..
It's much rarer -- most places have bitten the bullet by now -- but I still see it (and IE7 is certainly still around).
IMO, some of what you describe sounds like the wrong way to hire. Stuff like Function.prototype.bind can be easily found By Googling. You want candidates who can adapt to the unknown. I remember a well-known PHP developer in the DC area telling me a story about him guest interviewing candidates for a friend's company - he asked a lot of intense edge questions about PHP to candidates, and only one would give him straightforward answers about not knowing the answer and being willing to Google the answer. That candidate ended up being a phenomenal hire for that company.
That is true, but it is a warning sign that someone with 10 years of working with Javascript has never had to use those functions (even if they had to Google it 5 years ago, they should remember it now). It would be like hiring a driver with 10 years of experience who didn't know what the parking brake was for. Granted it is possible to live your whole life in a flat state and never have to use it, but that's rare, and even if true, I want a driver who has seen at least a hill or two.
Once you've passed the basic questions like this, we definitely get to more difficult and tricky questions, and even a question that has no answer to force the candidate to either BS or admit he doesn't know.
I have more sympathy towards people who may have not been fortunate to have seen the more challenging aspects of development and help them get there - only 2 1/2 years ago, I was unemployed for the past 2 1/2 years out of grad school without any company having given me such a shot at any career, and here I am now as a lead frontend engineer who is trusted to solve any problem thrown at me and build a team. Just as I was pissed off that so many companies were originally dismissive of me despite my education pedigree, I try not to be dismissive of candidates because they didn't happen to use [insert feature]. Stuff like that is easily studied or taught, and I evaluate almost wholly on things that (almost) can't be studied since it pre-empts candidates from giving me answers that hide important characteristics about them.
On the other hand an excellent hire might be a cheat that put the effort to become a good developer once he joined the company or... You might hire a very promising young man who (because this or that) he ended up being a bad hire.
This plays out at a larger scale too - some cultures are more open to borrowing from other cultures, and some are more closed. The more open ones utilize better technology than the closed ones.
I've worked with some developers who are brilliant technically, but are not people you would hang out with outside of work. You don't want to duck out or pretend you have a doctor's appointment just to avoid going to lunch with a coworker. You also don't want an arrogant know-it-all on your team, even if he is a genius with code. I remember interviewing a guy and asking him how he would accomplish something in PHP, and he said "PHP sucks, I would write it in a real language." That's the kind of person you don't want to hire to work on a PHP app.
'That's the kind of person you don't want to hire to work on a PHP app.' Definitely. I would also be surprised if they were even technically capable of giving a good answer, given that attitude.
'You also don't want an arrogant know-it-all on your team, even if he is a genius with code.' Agreed. And since nobody else wants to work with someone like this, this type has a tendency either tone down their attitude or to get weeded out before they can really grow technical expertise. I've interviewed hundreds of people and can only think of a couple of examples that were close to that, and those were either for internships or people fresh out of college. Do you often run into people that are technically a great fit but are too arrogant to hire?
However, you are correct in that there are correlations between them that you can use to guide the interview:
- breadth of technical knowledge -> curiosity
- depth of knowledge on a topic -> focus
- length of experience on a topic -> patience
- sources of knowledge -> self-guidance
- etc.
Recent interviews:
- A somewhat well-known poster here, the kind of coder who parachutes in when startups are having trouble shipping and need help. Didn't actually know the programming language very well, which is sadly common amongst coders of the language in question. Sometimes that's ok, but this person presented themselves as an expert in the language and did not know very basic things about it.
- Again, not very strong with the language, but very strong in other languages and overall quite an impressive candidate. I recommended to hire this person, but for a different engineering role. Got hired for a different role and is doing a great job.
In the interview itself, as I said, no coding. Sometimes I will ask the candidate to spot bugs in a function, or read code and say what it outputs, or have a whole function written with one thing missing, and ask what's missing. But asking the candidate to create something where nothing yet exists is not fair, I think. Whiteboard coding and all that, it's no good.
When I say the candidate didn't know the language well, I meant conceptually. Like, imagine if someone told you C had a built-in array type, for example. It was that sort of thing. And remember, this was a person claiming expertise.
One of the principal things I look for in candidates is ability to speak comfortably about their thought processes & confidence level -- because it's so much more valuable to have a developer say "well, I can think of two ways to solve this, but I'll have a much more solid answer if I can take 10 minutes to refresh my memory on a project I did 5 years ago" than one who says "there are 2 options".
This shows up in interviews (and I look for it); if you give a wrong answer to a question, but you seem to be confident, that's bad. If you give the same wrong answer, but you mention that you don't use the construct (and thus aren't fully confident on your response), that can even be better than giving the right answer.
An interview that only saw correct answers can easily be less informative than one that ran into areas of uncertainty -- because it's crucial to see how they handle that. Do they realize they're guessing? If not: don't hire. Are they comfortable revealing uncertainty or missing knowledge? If not, don't hire.
Ideally they should know how roughly how confident they should be, and also know how to get to a better answer quickly. Real development isn't at all like a closed-book test, and interviews that operate like a closed-book test aren't useful for that reason.
- Candidate was lacking in fundamentals in his/her domain
- Candidate could not demonstrate a good critical thinking ability
The first was a total dealbreaker on a phone screen.
I prefer strong critical thinkers, and am willing to eschew complete knowledge of a domain from a candidate and mentor him/her up to speed, but weak critical thinking is nearly a dealbreaker for me as a manager.
I have been extraordinarily happy with all the people I have hired so far.
I've seen signs of poor logic crop up just when going into detail about past experience; but otherwise it can be hard to see -- particularly when the candidate has been working on projects where someone else was providing technical leadership.
I do ask candidates to go through a thought exercise -- basically a software dev related puzzle requiring no special knowledge (except a bit of basic crypto). Something like "here are the 5 constraints; walk through how these 3 scenarios would work" -- no code involved, but requiring the ability to convert constraints and goals into step-by-step instructions.
This has been pretty useful (there's a surprisingly huge range in the types of responses I get) but wouldn't reveal much about how good someone's choices would be deciding how to implement new features from scratch, for example.
I don't necessarily expect perfection in code design - I can help teach that, but a good foundation is paramount.
If it goes well (first scenario), I like to spend the rest of the interview pairing on a task like writing a parse method for a Backbone model that needs to transform a response for a charting library or something like that with Underscore/Lodash.
One time, a candidate started checking emails on his phone during an on-site interview. That candidate wasn't hired.
Example:
var a = function(x){ this.x = x+1; return this; }
var b = function(){ this.x *= 2; return this.x; }
a(3).b(); //result = 8
I like this question because it covers closures, this, objects and functions. It also doesn't qualify as a brain teaser, IMO.
That's debatable. It requires a piece of unusual thinking ('return this'), and a bit of magic (knowing about the 'this' magic variable), but once you've seen it, the answer's obvious, and it's pretty easy to replicate everywhere.
- No formal background
- I don't code on the spot, and not on a whiteboard with zero resources but rote memory
- I'm not "senior" enough (with >15 years in roles with progressively increasing responsibilities and contributions)
- Buzzword trivia was fun in 2003. Not so much.
- Had an off day
The roles I've been hired into where I wasn't subject to a dog and pony show have arguably been the best, as I've been approached as a person and a professional, and not as a little blue box filling an opening in the calendar.