[Jemaclus]

My primary criteria when interviewing junior candidates are:

1) Do you have basic problem solving skills?

2) Can you communicate clearly?

3) Do I want to sit next to you for the next 6 months or longer?

If you don't know Ruby, I can teach you. If you don't know Elasticsearch, I can teach you. What I can't and don't have time to teach you is how to solve a problem on your own without me holding your hand, and I especially don't have time to waste trying to communicate poorly with you.

And obviously, I want to work with someone who is pleasant and interesting. I don't wanna sit next to someone for 40 hours a week who stinks or is rude or can't carry a conversation.

If you meet those three criteria, you've beaten 90% of candidates that walk through the door. The last 10% is what gets you the job. (Obviously, if you DO know Ruby or Elasticsearch, that's a huge plus... but it's not one of the bare minimum requirements.)

[fnbr]

As a junior developer, I find myself confused by your comment. It seems as if a large proportion of the posts on HN claim that, when looking to hire someone, they focus on problem solving abilities and and culture fit.

However, in May when I was interviewing with companies (including YC backed startups), almost every company focused on quizzing me about trivia [1]. I was actually given a paper quiz by one of the companies on equality comparisons in Javascript (e.g. "Does 4 == '4'?"), which I found pointless, as I can test that within seconds at a computer.

[1] The major exception was 42Debut. Even though they didn't give me an offer (just stopped replying to my emails, but c'est la vie), I was treated with respect throughout the whole process, and the interview was very well done, with challenging questions that forced me to think, and didn't rely on language trivia. I would recommend the company to any of my friends, whereas I can't say that about almost any other company I interviewed with.

[lostcolony]

That kind of question can actually be useful as a proxy for experience with the language, and whether you're the type of person who digs into understanding your tools. If you say "I'm a rockstar Javascript dev", it's very hard to prove it; but if you've never been bitten by some of Javascript's type conversions, and/or have never really looked into some of its intricacies on your own, you probably aren't. It's just one data point, it won't be enough on its own to sway the interview either way, but it's interesting.

To give you an idea, I once interviewed a Javascript dev who said you should null out your variables with 'undefined' when you were finished with them. Oh, why is that? 'Because sometimes they leak out into the global scope and that can cause problems elsewhere in the code.' This person had noted that you could declare a global anywhere in Javascript, but had not noticed, nor asked anyone, nor looked up, nor anything, to find out that there's a difference between "x = 5" and "var x = 5". We didn't hire him.

Had he simply been unaware you -could- declare globals (and had instead said that "x = 5" won't work, you have to use the 'var' key word, or something), we wouldn't have counted it against him; he's following a best practice and never encountered it, fair enough. If he had never been bitten by the scoping rules, fair enough, a minor ding but we'd continue the interview. But the fact he had seen it, possibly been bitten by it, and just handwaved it away as non-deterministic weirdness that required a mystical incantation to avoid? No.

[x0x0]

I find it hard to believe anyone has spent a bunch of time writing js and never been bitten by a type conversion. Am I wildly off base?

I do data science, but everyone who writes R has been bitten by it's scoping rules, which are definitely not mainstream. Everyone I know who writes java or python has been bitten at least once by the pass object references by value (is there a better name for this?) function argument semantics. Everyone who writes java has accidentally written == when they meant .equals and stared at the code for far too long. etc etc etc You just can't claim you can competently use a language without understanding some basics, like how functions work, how arguments are passed, and how equality is decided.

[scarmig]

Not at all off base.

Which is the reason I would be deeply annoyed by the 4 == '4' question. The technical answer is it evaluates to true, but the real answer is "any code that requires all readers to have intimate knowledge of Javascript type conversion rules to read and understand is horrific code."

[x0x0]

I'm with @lostcolony: if I were interviewing and a candidate said "don't do that, it's unpredictable, do this instead" it's a great answer.

[fnbr]

At the same time though, as someone looking for their first dev job, I'm not going to tell the interviewer "don't do that." Given the people I've met in industry, I can't see that ending well- I would expect some variation of "who does this kid think he is!?"

[kourt]

pass object references by value (is their a better name for this?)

Barbara Liskov used "call by sharing", aka "call by object-sharing" or "call by object". http://stackoverflow.com/questions/40480/is-java-pass-by-ref...

[x0x0]

thank you! I really like that

[lostcolony]

Agreed. So when someone answers it wrong, while claiming some knowledge of Javascript, that's kind of a major ding against them.

[mikeleeorg]

I was treated with respect throughout the whole process, and the interview was very well done, with challenging questions that forced me to think, and didn't rely on language trivia. I would recommend the company to any of my friends, whereas I can't say that about almost any other company I interviewed with.

This is a really important point to remember for interviewers. The interview process isn't just to help you find good candidates, it can be a great branding/marketing vehicle as well. I've gotten many good people from former candidates who enjoyed our process and spoke highly of our team.

I wouldn't have just stopped replying to emails though. An interviewer should always reply, even to politely decline. And it can help to add a reason why you are declining a candidate too, since it can help them improve and perhaps return for another interview in the future (I've hired a few people that I originally passed on too).

[danielweber]

Of the many companies that have rejected me, Suitable Technologies (makers of Beam robot doubles) were the best. The biggest thing was that they rejected me as soon as they knew they had rejected me. Within a few hours.

Which hurt, in the short term, because I am a human being. But it was better than many other companies that would say "we'll tell you later today" and then wait a week, or wait for two weeks since my last interview and then reject me in the middle of the CTF they are running and I'm participating in (what, did my answers in the CTF suck?) and then invite me to apply for a job at the end of the CTF after rejecting me. That's really yanking my chain.

[dllthomas]

"And it can help to add a reason why you are declining a candidate too, since it can help them improve and perhaps return for another interview in the future (I've hired a few people that I originally passed on too)."

I've always tremendously valued the rare feedback I've gotten, but my understanding is this is not the same advice a lawyer would give (and that makes me a little sad).

[Jemaclus]

I don't generally ask those kinds of questions. Mine are more of the algorithmic variety (i.e., given this problem, how do you solve it?). Having said that, the last 10% of getting the job is demonstrating that you know SOME programming. I may ask you some programming questions like the one you presented, just to see whether you know programming at all. If you got this right, you're 95% of the way in the door, as opposed to just 90% of the way in the door. It's not a deal breaker -- I can teach you the difference between 4 and '4' -- but it's a huge plus if you get it right.

Plus, like the article says, most people suck at tech screens, so that interviewer may have just been asking random questions with no clear idea of what they're looking for.

[x0x0]

Testing 4=='4' is far from pointless. For better or worse, programming as the majority of us practice it is no longer about flipping bits or moving bytes or red-black trees or building common collections data structures. It's now about a language plus an api or apis, and the language of front end web development is javascript. So checking if front end or fullstack dev candidates have a basic understanding of types in javascript is perfectly reasonable.

[RogerL]

One can learn facts. In fact, it is incredibly trivial to do so if you are smart. I need to do it dozens of times a day to do my job, as does any programmer.

I don't program javascript at all, but am vaguely aware of the terrible implicit conversions it does. Isn't that the important part? I do not have memorized that

   false == 'false'    // false, yet
   false == '0'        // true

Why would I (I had to google that, took 5 seconds, btw)? It is ugly, terrible code. Sure, if I spend my days in a terrible code base I might be forced to learn those conversion rules, but that isn't exactly the mark of a hirable person - it is just the employment history of that person.

Now, if somebody who claimed they knew javascript was writing 'j := 0' for assignment I'd be concerned - but probably they've just been writing a lot of Go lately.

I can see a question like this being asked as part of a lead in to a more general discussion about types, type conversion, how different languages manage it and the trade offs thereof. But, most of the nit-picky questions I have ever been asked in an interview were just nit-picky. What is the output of the obfuscated C? What happens if you abuse the syntax like so? Just pointless questions compared to the real thing you should be measuring - can I produce high quality code on schedule and budget that adds value to the organization without making everyone around me wish they were dead rather than talk to me again? Can I recognize inefficieces in the company and improve things? Can I step up and lead a team or a project? If asked to do something outside of my comfort zone, like go on a sales call, can I do it? Will I complain bitterly if asked to fix bugs for awhile? Will I skip off to a new job just as I start becoming productive at your company? Can I mentor junior people? Can I converse with the CEO and tell him difficult facts if necessary? Can others read my code, modify and extend it without undue problems? Can I untangle other people's spaghetti code?

Measure that stuff, not whether I know if 0 == 'false'.

[x0x0]

Um, no. If you don't understand types in js, you don't understand js. I'm not hiring a front-end engineer who somehow hasn't learn js unless he or she is a totally raw intern. And a 1st or 2nd year intern, not a 4th. For anyone else, you need to know js, and if you don't understand types, you don't know js. If you need to google your example, you simply can't write js on a daily basis. (The one exception is, as noted below, saying "don't do that, here's why, do this instead"; that's a great answer.)

Types, functions, objects, classes, type conversions, etc, are part of the minimal working set needed to write code in a language.

[nawitus]

Well, testing 4 == '4' is pointless in my opinion, because you should never use the '=='-type equality in JavaScript. I never use it, so I don't even know what that evaluates to. You should always use ===, and set up a linter to enforce that.

What I think is valuable to understand is the concept of truthy and falsy, as I've seen even some experienced JavaScript programmers struggle with that. Maybe that could be a decent interview question.

[lostcolony]

A response of "I'm not sure; I always rely on === and explicit conversions to avoid the ambiguity. My guess would be (doesn't matter) though" is not only answering that question, it's scoring an 11/10 of the possible points (were it pointed).

[tptacek]

Criteria #3 is toxic. It's one of those things people adopt with the best intentions, but (a) is often at odds with the best interests of the firm and (b) provides an enormous amount of cover for prejudices and, more perniciously, cognitive biases. When you're interviewing a candidate, assume your brain is trying to trip you up (it is!). Build a hiring process that treats your intuition as an adversary and eliminates cover for biases.

[Peroni]

Criteria #3 is toxic.

Nonsense. It's as toxic as screening a resume.

On one hand you have people with immense industry experience (such as yourself) advocating to drop the "do I actually like this person" approach and on the other hand you have people who also have immense industry experience advocating that culture fit should be one of the most important criteria.

I'd be interested in hearing your thoughts on eliminating prejudice (both intentional and unintentional) and cognitive biases whilst at the same time, ascertaining whether or not someone would be comfortable within your companies established culture and also contribute positively to said culture.

[VLM]

To clarify, the difference you aren't seeing between the groups is the incompetent managers define "sit next to" as "sit next to at the nudie bar" or gaming table or harry potter movie premier or frat house or pretty much any place other than work. AKA young inexperienced white frat boys only need apply.

In comparison, competent managers define the same "sit next to" as "sit next to during an emergency bug fix" or while hashing out a new feature idea or optimizing a slow task or automating a process or just gossiping about a new technology. These are the kind of managers who "dare" to hire non-white people or women or older than 25 yrs old etc. Usually their company is much more successful for obvious reasons.

[Peroni]

I fail to see how criteria #3 in the parent comment: Do I want to sit next to you for the next 6 months or longer? is assumed to be toxic when it can be as easily assumed the intention is the latter half of your example.

[smm2000]

When you hire somebody for your your team, company is not the only one stakeholder. The CEO won't spend 40 hours/week with new hire. Your personal productivity and happiness depends on new hire and if he has (1) bad communication skills (2) unpleasant to be around, it's no hire no matter his technical skills. There are exceptions to this rule of course - like when you won't personally work with the person or he is genius.

[jawns]

I largely agree with B but I'm not so sure about A -- particularly since hiring someone whom you don't want to be around is likely to affect your performance, which is likely also at odds with the best interests of the firm.

[jebblue]

Unless that person does a better job at helping the firm make money in which case you might be the one "at odds with the best interests of the firm".

[pmiller2]

I'd like to know what company you work for so I can apply there. My email is in my profile.

[jghn]

It says in his profile ...