5 ms·

Ask HN: Why did you Not hire that candidate?

13 points by peterchon 11y ago

Was it more a technical reason? or a personality reason?

byoung2 11y ago
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).
- peterchon 11y ago
  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?
  - byoung2 11y ago
    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)).
    - SamReidHughes 11y ago
      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.
      - ricardobeat 11y ago
        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.
        SamReidHughes 11y ago
        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.
        ricardobeat 11y ago
        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.
        SamReidHughes 11y ago
        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.)
- Bahamut 11y ago
  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.
  - byoung2 11y ago
    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.
    - Bahamut 11y ago
      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.
neonfreon 11y ago
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.
- peterchon 11y ago
  Thank you for the thoughtful response!
- byoung2 11y ago
  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.
  - neonfreon 11y ago
    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?
andersthue 11y ago
If I wouldn't work for him/her, then I will not hire him/her.
- neonfreon 11y ago
  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.
  - andersthue 11y ago
    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.
serve_yay 11y ago
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.
- Impossible 11y ago
  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.
  - serve_yay 11y ago
    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.
  - jtheory 11y ago
api 11y ago
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.
Bahamut 11y ago
- 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.
- jtheory 11y ago
  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.
  - Bahamut 11y ago
    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.
bzalasky 11y ago
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.
- jhildings 11y ago
  Out of curiosity, what is the things you need to do to make that possible?
  - tienthanh8490 11y ago
    You just need to "return this;" for the methods whose result need to be chained. 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
  - bzalasky 11y ago
    Something along the lines of this: 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.
    - fragmede 11y ago
bitshepherd 11y ago
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.
Warewolf-ESB 11y ago
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.

13 points by peterchon 11y ago

Was it more a technical reason? or a personality reason?

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).

peterchon 11y ago
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?
- byoung2 11y ago
  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)).
  - SamReidHughes 11y ago
    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.
    - ricardobeat 11y ago
      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.
      - SamReidHughes 11y ago
        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.
        ricardobeat 11y ago
        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.
        SamReidHughes 11y ago
        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.)
Bahamut 11y ago
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.
- byoung2 11y ago
  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.
  - Bahamut 11y ago
    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.

neonfreon 11y ago

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.

peterchon 11y ago
Thank you for the thoughtful response!
byoung2 11y ago
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.
- neonfreon 11y ago
  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?

andersthue 11y ago

If I wouldn't work for him/her, then I will not hire him/her.

neonfreon 11y ago
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.
- andersthue 11y ago
  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.

serve_yay 11y ago

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.

Impossible 11y ago
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.
- serve_yay 11y ago
  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.
- jtheory 11y ago

api 11y ago

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.

Bahamut 11y ago

- 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.

jtheory 11y ago
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.
- Bahamut 11y ago
  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.

bzalasky 11y ago

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.

jhildings 11y ago
Out of curiosity, what is the things you need to do to make that possible?
- tienthanh8490 11y ago
  You just need to "return this;" for the methods whose result need to be chained. 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
- bzalasky 11y ago
  Something along the lines of this: 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.
  - fragmede 11y ago

bitshepherd 11y ago

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.

Warewolf-ESB 11y ago

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.