31–40 of 177 posts
My first technical interview they asked me to write a constructor and I completely panicked. It still haunts me to this day that I think the guys in the room thought I was some sort of idiot.
Earlier quoted context omitted.
He didn't say coding was bad. He said coding on a whiteboard is bad. And, if you evaluated 100 strong developers by comparing their performance at a terminal and a whiteboard, my guess is that you'd quickly see that he's absolutely right about that --- not only would everyone outperform the whiteboard with a terminal, but that the whiteboard deficit would be highly irregular, defying any attempt to "handicap" for it.
I would rather hire the strong developer that can code without autocomplete and write without spellcheck.
I think there are some good points here, but I would argue that a lot of these are essentially points for hiring more junior engineers. There are cases where hiring for what someone already knows DOES matter. I have come across too many codebases that were clearly written by folks who were in the "get stuff done" mentality. Frankly, when you're learning a new technology in addition to trying to do your job, your code…
Personally, I look for people who can think, who have exposure to a variety of patterns and can synthesize those patterns into their work, making appropriate choices. More power to us if, for our Perl shop, we hire someone with a strong background in modern Fortran because that different perspective is part of what makes the team diverse, creative, and successful.
I don't look for an expert in Perl to be even a senior developer here. It helps, but the primary consideration is their ability to work with abstract information. The language is just one of many tools to express that solution, and the language choice can change over time to suit needs.
[1] Not to be confused with "design patterns". I am using the term more fundamentally.
My first technical interview they asked me to write a constructor and I completely panicked. It still haunts me to this day that I think the guys in the room thought I was some sort of idiot.
Mostly do!
>> Somebody who can intelligently discuss technology >> Somebody who knows what they don't know I believe in these principles especially. Most of my interview questions are vague (and I tell the candidate this up-front, and explain why). For instance, I'll ask them to explain how they would debug a very slow cluster, or to explain everything happens between me hitting the keys 'google.com' to me viewing the web page.…
Oh god, a question like the Google one would have me not knowing what to say... I mean, to give a reasonably complete answer would take hours and hours! What do you do if someone really goes into detail and can't even get to the part where the packet leaves the local network in a practical amount of time? Is that viewed as inappropriate overkill or a poor understanding of the question?
If candidate lists lots of skills/experience, I do a self-assessment where I get them to claim that they're really good at something, then ask them to do something that requires bare-minimum skills in it. The idea is not that they need these skills to do the job, but that if you claim a CS degree, eight years work experience, and being a python expert, but you can't crack out a basic, non-trick whiteboard coding exercise blindfolded, something smells bad.
If a candidate doesn't have much experience, I'm trying to figure out just how green they are; low-experience candidates cover a huge range of skill all the way down to knowing literally nothing but a few buzzwords. If you don't know a language or a library or a technology I can teach you, but if you don't know anything it's going to be years before I can get anything shippable out of you.
I wish these weren't a major worry but the majority of people who come in the door (after a resume and phone screen!) don't pass.
What do those of you who are doing intensive whiteboard-coding interviews think you're getting out of it?
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 especi…
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 comp…
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.
I disagree with author about coding question. In my experience if somebody is not able to code quickly a simple task (like fizzbuz, reverse a string), it's a terrible sign. It's a simple objective test that filter out a lot of candidates. Yeah they may be able to be productive in some specific environment (e.g. deep in some framework, writing templates), but in general they likely don't have solid programming foundat…
My belief has become that the only way to hire the traits that I'm looking for (high technical ability, sufficient education, predisposition to rigor, and -- most importantly -- indefatigable persistence) is by judging a candidate on their work, not their performance in an interview. (After all, software engineering isn't done via pop quiz -- and it's not even a timed test.)
The problem then becomes: how do you judge the works of someone you've never worked with before? Three ways that have worked for me:
(1) Rolodex. This is an easy way to hire reliably: someone on the team has worked with the person in the past, and vouches for them as one of the tribe. Assuming that you trust the person vouching for them, the interview consists of you selling them, not them selling you. This method has high fidelity (though is still fallible), but also suffers from obvious limitations in terms of scale and breadth.
(2) Known curricula. There are some schools where I know (or someone on the team knows) the computer science curriculum very well, and can assess a student simply by the courses that they have taken (or, better, TA'd), the labs they have worked in, or the professors that they have worked for. The fidelity of this method will depend on the school, how well one knows the curriculum, etc. -- and it has all of the strengths and weaknesses of hiring university grads. (It also suffers from serious scale problems and runs the risk of creating monoculture.)
(3) Open source. If you lead open source projects that attract community contributors, you may find it surprisingly easy to coax the best of those contributors into working for you full-time. While I know that this isn't a fit for every company, it has become my preferred way to hire: you are hiring someone who can obviously do the work (because, um, they're already doing it) and who has demonstrated interested in the problem space (especially if their contributions have come during their free time). Importantly, you are also not limiting yourself to a particular geographic area or school or company history or whatever; the people I have hired via open source are people I never would have found otherwise. And, it must be said, they have proven (without exception, actually) to be great hires. There are obvious problems with this as well in terms of scale and (especially) predictability, but I view open source as the farm system for software engineering: it's a way to find and develop talent at lowest opportunity cost.
Edit: I forgot a fourth method that has actually worked for me.
(4) Homework. When interviewing someone who I don't know and who is otherwise a stranger, I will ask them some exceedingly basic questions to assess technical viability, and then proceed to discuss the problems that we're solving and why I personally find them exciting. If they are sufficiently interested at the end of this conversation (which is really more me selling them than them selling me), I will assign homework -- which is generally to take some fixed amount of time (I have usually said no more than eight total hours) to build something fun in one of the technologies that we have built or otherwise use. (When node.js was new, this was to build something in node.js -- but more recently, it's been to build something fun with Manta.[1]) If a candidate comes back with completed homework, you each know something about the other: they were sufficiently interested in you to actually play around (and they like playing around to begin with -- which is essential for us) and you now have some works by which to judge them.
[1] http://www.joyent.com/blog/introducing-kartlytics-mario-kart...