27 ms·

People suck at technical interviews (2014)

265 points by sgift 10y ago

crikli 10y ago
Someone in a similar HN thread once recommended the book "Hiring With Your Head" and then sorta did a mic drop. I must do the same. Buy the book and implement it. It directly deals with so many issues mentioned here (great dev but crap at silly tests, great dev but a bad interviewer, etc).
skrebbel 10y ago
In all honesty, I'm not sure the author did a lot of interviewing. For example, > The famous fizzbuzz test simply asks "are you aware of the modulo operator?" Wait, what? No, it asks "can you write a for loop without breaking a sweat?". There's a rightfully vivid debate going on about the virtue of asking algorithmic questions in interviews, but fizzbuzz is hardly algorithmic. I'd wager that virtually all programmers iterate a collection at least once daily. The followup sentence drives it home for me: > Yet people will spend twenty minutes on it in an interview, a huge waste of limited time. Well, if it takes an applicant twenty minutes to Fizzbuzz, you're done! Just saved everybody lots of time. I used to think Fizzbuzz was insulting and bullshit until I started interviewing. I haven't yet met a programmer who couldn't solve a Fizzbuzz-level question, but I've met many who took over 10 minutes and made little logical errors. It's a great predictor for "can this person actually program, well, at all?".
- ProfChronos 10y ago
  Agree on technical questions + what he says on "team fit" really doesn't make sense: "You are NOT hiring for "team fit" I have never heard a definition of "team fit" that didn't end up sounding like "let our bias run free". Phrases like "looks like they belong here" are terrifying. More insidious are complaints like "doesn't like the same social activities we do". Grow up. Your office is not your frat house, and socializing with your co-workers outside of work is not some crucial test. There is no requirement that you like someone socially as long as you want to work with them." You don't ask people to be exactly like but you expect them to be able to work in a cool mood with you and to share things. Who would hire somebody that doesn't get along with the team??!!
  - qaq 10y ago
    Team fit is actually pretty important as far as how long the Dev will stick around.
- ktRolster 10y ago
  * It's a great predictor for "can this person actually program, well, at all?".* How do you know, have you hired many who had trouble with the Fizzbuzz? Or are you just guessing? (I don't know either; there's a lot of missing data in interviews)
  - Maakuth 10y ago
    Everyone I know doing recruiting says that FizzBuzz reliably disqualifies surprisingly large fraction of candidates. Even half of them, even after prefiltering by education or relevant experience.
    - LionessLover 10y ago
      That is a useless statement unless they followed the rejected candidates for a few more years at least. Otherwise it's just a tautology: They suck because my favorite test says so (i.e. because I say so). Sure it weeds out "non-programmers" - any programming task (more than "Hello World") does. But how many people who are good programmers and just suck a) under pressure, b) especially when surprised are falsely out-selected? I once failed to answer what a right join is. I got the (freelancer) job anyway - and of course I knew all along what that is, but when I got that question I had not used any joins in years (doing infrastructure work instead), and under interview pressure I can't think except along narrow lines. I ended up doing most of the complicated SQL queries in the department, with people coming to me because to me that was easy. After failing a very simple interview question on joins.
      - titzer 10y ago
        > That is a useless statement unless they followed the rejected candidates for a few more years at least. Otherwise it's just a tautology: They suck because my favorite test says so (i.e. because I say so). The same comment could apply to any rejection criteria. At my employer, we do have some data, since we do reinterview candidates after years in-between, especially if they are fresh from college. I can't speak for our organization but yes, basic programming hurdles do reliably weed out bad candidates. This is based on my experience of having done more than 150 technical interviews, all of which were balanced against the feedback of the other interviewers. Failing basic programming problems is a good predictor. > But how many people who are good programmers and just suck a) under pressure, b) especially when surprised are falsely out-selected? Any kind of test that is given to candidates has the same risk. But, let's break it down. Do you want to interview candidates for programming positions and _not_ have them program in some form or fashion during an interview? IMO that's nuts.
- drinchev 10y ago
  I agree with the author that Fizzbuzz is about the modulo operator if you present it to the candidate like that. What I would simply do is : "Write fizzbuzz test for language ... use the modulo operator, which is ... for that language" By doing this it's all about the loop. On top of that I think the author is right, because the pressure of the candidate is sometimes huge. I prefer giving a task that they can do at home. For example if it's a front-end position, it would be a small landing page. When I interview I usually tell the candidate : "I really enjoyed the conversation so far. Just to let you know, the management wants from us to get from every candidate a code sample, so I will have to give you a small task that you can do at home. I'm really sorry about that, but I think it will be also helpful for you to check out what exactly you will be doing here. Do it whenever you want, just make sure you have something by the end of the week. You can also ask me anything at ..." This sentence makes miracles. The candidate is motivated. The code is cleaner and though-trough. Then you can actually see if the person will be able to do the job.
  - gavanwoolery 10y ago
    I can second the value of the take-home assignment. My last company, Appstem, gave them out, and it never once failed. It additionally succeeded in weeding out people who were not motivated enough to want the job.
- dfabulich 10y ago
  >> The famous fizzbuzz test simply asks "are you aware of the modulo operator?" > Wait, what? No, it asks "can you write a for loop without breaking a sweat?". There are notorious cases where senior engineers with years of actual honest coding experience "fail" fizzbuzz. IMO, That happens in two ways: 1) Not knowing (forgotten?) what a modulus operator is, and trying to code one up from scratch with a for loop. This can totally happen when you spend a few years working on line-of-business CRUD apps that never turn out to need modulus arithmetic. Coding modulus from scratch with just + - / * is a fun little challenge in its own right, but it'll probably take you longer than 10 minutes to write it correctly and solve fizzbuzz with it. That means you just took more than 10 minutes on fizzbuzz, which means you failed. 2) Trying to "clean up" the solution. http://c2.com/cgi/wiki?FizzBuzzTest http://c2.com/cgi/wiki?FizzBuzzTest has a good discussion on 'Why Fizz-Buzz is "hard:"', which points out that many of the most obvious solutions have code duplication, which some people then try to eliminate, tying themselves in knots trying to make it perfect. The third possibility, that a candidate with years of experience shipping code nonetheless struggles to write a for loop, is IMO just not as common as the above two failure cases. (Much more likely is that the candidate has lied/exaggerated on their resume.)
  - corecoder 10y ago
    #2 happened to me: I wrote the straightforward implementation in a few seconds, and then struggled and tied myself up trying to eliminate the duplication, making it worse and worse, until I started panicking. Luckily the interviewer understood what was happening and changed subject.
  - imtringued 10y ago
    >Coding modulus from scratch with just + - / * is a fun little challenge in its own right, but it'll probably take you longer than 10 minutes to write it correctly and solve fizzbuzz with it. It's surprisingly easy actually. var remainder = x - Math.floor(x/y)*y (Math.floor because javascript)
  - benhoyt 10y ago
    If you don't know about modulus, you don't have to re-implement it. For Fizzbuzz you're looping anyway, so you can just maintain two counters, one that counts to 3 and resets, and one that counts to 5 and resets. When one of the counters resets, you know the main loop counter is a multiple of 3 or 5. Like so: def fizzbuzz_no_modulo(): counter_three = 1 counter_five = 1 for i in range(1, 101): output = [] if counter_three == 3: output.append('Fizz') counter_three = 0 if counter_five == 5: output.append('Buzz') counter_five = 0 if not output: output.append(str(i)) print(''.join(output)) counter_three += 1 counter_five += 1
- imtringued 10y ago
  The trick part of FizzBuzz is that the easiest solution relies on the magic "15".
  - efaref 10y ago
    Even that's an unnecessary complication. The code solution should read like the spec, so that if someone comes along later to make FizzBuzz depend on some other set of constraints, they know what to do. The compiler can optimize away the duplicate tests. That's its job.
- chrshawkes 10y ago
  If you're so crafty at sifting through candidates to resort to FizzBuzz to help you do it, why do you have to copy and paste FizzBuzz, why not come up with something original?
  - skrebbel 10y ago
    Actually I usually ask a comparably difficult question for fear that people might have actually remembered the solution to fizzbuzz by heart. But I didn't think it added to the discussion to mention that.
- Clubber 10y ago
  I think what he is pointing out is that if you don't know the modulus operator, you will fail FizzBuzz. The modulus operator is rarely used and somewhat obscure. The only time I use the modulus operator is when I'm writing something to track what record / rule I'm processing and I only want to show every 10,000th record or so. I can't think of a time I've used it otherwise.
  - lmm 10y ago
    You can implement it yourself if you forget it. Or use a counter (urgh). Or ask whether there's a library function that does that.
- PJDK 10y ago
  I had a pretty interesting experience with this. We were doing a bunch of interviews and decided to try out FizzBuzz. I wasn't doing this round of interviews, but things ended up a bit confused with timings and I had a 30-40 minute very casual chat with each candidate prior to the actual interview. In each of those I ended up probing a bit on technical stuff and everyone seemed to have a decent base level of competence. But they all went to pieces over fizzbuzz in the interview. The one I actually saw, I had had a fairly in depth conversation about what it actually means to use "ref" and "val" in C#, but then watched the same guy freeze and barely scrape through fizz buzz. My conclusion is that some people just can't write code in that kind of environment. What makes it tricky is some people (myself included) find it easy or even fun - maybe I can write fizz buzz in a single LINQ statement...Those people can assume that everyone not like them can't code.
  - jogjayr 10y ago
    I can confirm. I went to pieces once when asked to do FizzBuzz when I wasn't expecting to code in a phone interview. I'm not a "rock star" programmer but in the absence of pressure I can knock out a FizzBuzz in < 2 minutes. And I have written real software used by real users that made money for my employers.
gavanwoolery 10y ago
As someone who is going through many technical interviews right now, and failing all of them, I love this article. (It was actually brought to my attention last week.) My technical ability is readily apparent to those who have viewed my work, and by virtue of those who have praised it. I don't claim to be the best programmer in the world, just a competent one. I've also been programming for over 20 years, that might have something to do with it. However, I suck at interviews, in any way shape or form (personality tests, technical tests, you name it). Yet I've aced every job ever given to me, and people love to work with me (even in spite of my salty attitude). To think that you can determine what it is like to work with me over the span of a year within the span of an hour is completely and utterly ridiculous. As it turns out, the little sub-problems they give are the most trivial part of programming. The hard part, the part it takes many years to get any good at, is coherently organizing, documenting, and ensuring the stability of a larger system, particularly concurrently with other programmers. Or designing an algorithm that you can't just Google. Or making a really tough decision about what features to cut or what direction to pivot. Or organizing a vision of what will add the most value for the customer. Or...etc Being an introvert with a monotone voice, general lack of expression, and deadpan sarcastic humor does wonders for personality tests. Most people's default reaction to me (in interviews or otherwise) is that I am a total dick. Which I am, but the kind you don't mind hanging around. I don't do well with programming that has a one hour deadline. But give me a day and I can produce the typical output a programmer would within a day. If I spent all my time practicing for interviews, I'd probably be better at them (with stuff like Top Coder or Interview Cake or whatever). And I think giving these things a whirl is well worth it (not for the sake of winning in interviews). But it is not my life goal to be good at interviews. It is my goal to work in areas I am interested, and continue learning things that are directly relevant to my real-world tasks (sorry, writing a red-black tree on a white board within an hour never happens to me in the real world).
- ktRolster 10y ago
  But it is not my life goal to be good at interviews. It is my goal to work in areas I am interested, and continue learning things that are directly relevant to my real-world tasks You have to look at the programming career as requiring two skills: the first is programming, and the second is finding a job. That might suck, but it's the nature of a career where you change jobs every three years or so.
WaxProlix 10y ago
Oh man, I thought they were on to me, but no, it's for the givers of technical interviews. Phew.
- gavanwoolery 10y ago
  I chuckled :)
ktRolster 10y ago
When I interview, I try to find out what the person is good at. Everyone who comes to interview is good at something (even if it's just good at getting interviews). Sometimes their skill-set overlaps with what we need, sometimes it doesn't. But the focus is figuring out what they are good at, rather than an abstract test.
- yardie 10y ago
  Are you hiring? I've had a pretty miserable week of interviewing. Either I'm not the right fit or the potential employer is less than ideal.
  - ktRolster 10y ago
    Right now I'm looking for a job, not hiring haha. The table is always spinning.
MrLeftHand 10y ago
With one of many job applications I did, I received a small coding exercise before getting to the actual interview. It was about writing a small application in perl (one of my favorite scripting languages) to solve a problem. It was a number converter from arabic to roman and vice versa. Anyway I started by looking up a perl module that solved the whole thing in 3-4 lines of code. What was the answer? Sorry that's not we wanted. We would like to see, how you would solve it with general code. So you're saying that doing investigation work, finding an existing working solution and applying that solution is not a good answer for you? Sorry but that's how I work. I find a problem; I investigate for a solution; if there is one I use it and implement it; if not then I will write one. The moral of the story is: interviewing is fundamentally wrong and doesn't help you find a good candidate. There are millions of good solutions to one problem in programming. Asking for a solution you want to see and not a solution that solves the problem will never help. Then why don't you clone yourself and have an army of developers which work the same way and produce the same code with the same flaws over and over and over.
- dijit 10y ago
  The issue is many companies have NIH syndrome, sometimes for a generally good reason. in the same circumstances I would have noted my find and copied the relevant code into my project, not because I'd do that in personal projects, but because companies only care about integrating their requirements with as few external dependencies as possible.
  - MrLeftHand 10y ago
    Yes, that is a problem as well. They don't want to use libraries from the outside, so they develop a lot of stuff in-house. Which will have specific requirements and getting someone up to speed takes longer then using an existing API, which is well known and used by millions of other companies and developers. Also most of the times these in-house APIs are developed by if not one, but a handful of people. So if they leave, you are stuck with code which nobody understands and you keep on adding on top of it and breaking it in many ways. Not to mention your developers will be stuck and get experience with code not used anywhere else. If you want to cripple their prospect to get better jobs and experience, this is the way to go. It is a vicious cycle and it seems nobody is willing to break it.
itaysk 10y ago
Interviewing is hard.. I always hated the idea of judging someone based on a 1 hour chat (I was always the tech interviewer or first screen). I also hate that interviewers aim to challenge the candidate with hard technical questions that they might have or might have not had experience with. So what I do is ask the candidate to tell me about their experience, past projects, and also frankly ask them "what are you most comfortable talking about" and continue diving from here. When they talk about a topic they claim to be experienced with, you can really see what they worth. When someone can't fluently discuss something his claims to be knowledgeable in (yes that happened), that's a bad sign.
PuffinBlue 10y ago
There needs to be a bit of a shift in understanding what 'category' of worker a programmer 'is', both by companies and more importantly by (some) individuals themselves. Programming is both technical and artistic. It's a creative endeavour that relies on technical skill to complete. The best analogy to another profession would be to those in the 'technical arts', those like photography, joinery, painting, sculpture, drafting, perhaps writing too. It seems at the moment that companies are approaching programmers as if they are purely technical like an actuary or bookkeeper and are seeking to quantify artistic skill through interview tests. This is rubbing off on some programmers who begin to think of themselves in these terms. I don't recall a single instance as a photographer where I had to quantify my technical skill, but there were hundreds of times I had to based on my artistic skill, proving I had already made a vast range of photographs with sufficient quality to 'prove' my ability and by extension proving my technical ability. Crucially, it was the fact I had a portfolio that allowed me to prove my ability, both artistically and technically. I see a similar need in programming. I think programmers should create their portfolios of personal or paid for projects that showcase their technical and artistic skill and companies should take those seriously. At the moment it seems that far to many programmers are attempting to get jobs without a 'portfolio' which is why, in an creative endeavour like programming, companies that hire are trying to quantify and determine a new hires ability with these seemingly bullshit tests. There's room for improvement in this argument and there are outliers, but I think the basic premise is sound.
- gavanwoolery 10y ago
  That is actually a really great point. Its like hiring a writer based on their grammar. A writer could have perfect grammar but their books are boring as hell. Or even hiring a writer for adhering to the techniques of connoisseurs. The book "Ready Player One" was heavily criticized as amateur work (it was, after all, the author's very first book), but it nonetheless was hugely successful (and even has a movie in the making).
  - mruniverse 10y ago
    Would you hire a writer with bad grammar?
deleted 10y ago
[deleted]
lambdabit 10y ago
The problem with his interviews is that it's even more easily gamed. It doesn't really take a genius to go through their employment history and memorize blurbs that show learning technologies, applying it successfully while being humble and nice for one day.
- IndianAstronaut 10y ago
  >while being humble and nice for one day Employers need to screen for this more. So many horrible people making it into workplaces and ruining work cultures.
- vonmoltke 10y ago
  If an interview like that can be gamed by "memorizing blurbs" then it wasn't done correctly. A properly conducted interview will see the interviewer tugging at threads to go deeper. At some point they will crack because memorization won't be enough. Unless of course they are anpathological liar, but those are rare enough that I would ignore the posssibility at the interview stage.
  - lambdabit 10y ago
    You're right, I exaggerated but I don't think this is a hard game. People spend several months right now on studying interviews. The topics are wide and scope enormous, hence so many complaints; some companies test you on languages, others on algorithms, data structures, dynamic programming, bit manipulations, SQL queries, scalability, unix internals, I could go on and on. On the other hand, there's only so many paths these past history conversations can go, and you know where they can poke at.
skay_ 10y ago
A lot of people are saying that technical interviews are not good because some people are not good at them but they are indeed good software developers. Other people are saying that is impossible to judge someone in a few hours of technical interviews/exercises. I agree with both, but what's a better alternative? How to you minimise the risk of taking hiring a bad developer? At least, it is my belief that the technical interviews minimise the risk which is far better that ending up hiring someone who is not technically strong.
- Clubber 10y ago
  What I do is ask them about previous projects. 1. What was your favorite project and why? Explain. 2. What was your least favorite project and why? Explain. I can get a good idea of the person through those two simple questions. I throw a few simple technical questions like: What is a primary key? What is a foreign key? What is inheritance? What's the difference between a function and a procedure (Delphi days). Questions that anyone should be able to answer just by writing code.
l1feh4ck 10y ago
> Don't hire for a fancy degree. There are some companied coming to my college for hiring. The first criteria they put was 70% aggregate marks (60% for some companies). I have seen people who doesn’t know how to write even a small program getting hired, while people with good programming skills are not even eligible to attend the interview. Going through 200-300 candidates in an interview might be a tedious job, I am not sure. What other choice do they have?
- MrLeftHand 10y ago
  Had a coworker from a university, didn't even know how to write a while loop. He didn't last long to say the least. Of course we will never know, if he could have been a good programmer or not, but it was baffling to see people fresh out of uni with zero knowledge.
- Taylor_OD 10y ago
  I think the idea is that the "smart" person will be able to learn what they need to on the job quicker. The person with lower grades may be a better developer but right now of school I think most employees are hiring based on potential and culture fit vs actually development ability.
hanginghyena 10y ago
Hiring Manager Perspective: Everyone lies, sorry. As a candidate, I hate technical interviews. For the reasons above. As the poor schmuck asked to make the hiring decision, however, I've learned that I can't live without them. My technical isn't complicated. A very basic SQL assignment (delivered to an audience which claims to know SQL) that is followed by a few broader database design / data process QA questions. Entire assignment is 100% job relevant (in fact, my SVP asked for a copy of the report it generates when he saw the problem on my whiteboard). I don't care about the details of syntax. I do care, however, about candidates who produce SQL code which looks like the bastard love child of LISP and Java. About candidates who claim to know a skill but literally cannot write even basic syntax on the whiteboard. Who put "certificates" from Oracle on their bloody resume and break down under super gentle questioning and confess their tutor hasn't taught them JOINS (wtf ?) yet, never mind 5 years of claimed SQL experience at a big company on their resume. The coding question is most definitely not an exercise in sadism. We validated it with several new hires who were confirmed to be "good at SQL". Average completion time: 2 minutes, generally with trolling about why do we waste our time with easy stuff. That being said, my rejection rate from a basic coding interview is at least 50%, grading liberally and generally supported by several members of my team shaking their head about a candidate. I've tried screening resumes, I've tried doing non-coding phone screens. IT DOESN'T WORK. Actually, all it does is eliminate the socially challenged and non-communicative (who actually tend to pass the whiteboard test) in favor of the liars. And don't get me started about Python. Lest I bring up the Google-Motorola "I LUV Python heart heart heart" guy who didn't understand the difference between a list & dict.
- heartsucker 10y ago
  I've had the same experience. Someone listed 2 years Scala experience on a resume, but couldn't explain Unit, None, null, and Nothing to me. Or the guy this week who had several years of ops experience and when asked "how can you tell what indexes are being used in a SQL query" didn't even know about EXPLAIN. Basic technical interviews are a must, but someone people get hung up on "they couldn't explain a hash map implementation," because sometimes "you put a thing in the map and then get it back out later" is good enough for 99% of startup engineering tasks. Somewhere out there is a sweet middle ground, but it seems not one agrees where it really is.
bbcbasic 10y ago
I want this guy to interview me. Even if there is no job. I'm sure I'd feel a million dollars by going through the process.
seanwilson 10y ago
Some people are just bad at giving interviews. If someone is so bad at interviewing they will eliminate a candidate because they slipped up a little with a programming teaser, they're still going to be bad at interviewing if they try another technique. I'm completely happy doing programming puzzles in interviews myself as I've worked with people that claim to be experts in something when they aren't and some people exaggerate to the point of lying on CVs. As long as you don't penalise a candidate too much for not getting perfect answers I don't see the issue.
DrNuke 10y ago
Apart of job-related questions and general-thinking problems, tech interviews are still mostly a poor Tinder experience.
cmrdporcupine 10y ago
That companies now insist on running the Google-style whiteboard-algorithms-coding-skill-testing-question type of interview tells me that there is no shortage of programmers to hire. Because as far as I understand it we use that process at Google because we can afford a lot of false negatives because we are inundated with a lot of resumes. Smaller companies and startups surely are not, and finding candidates must be harder. Unless the job market is saturated with candidates. Many perfectly good, maybe even excellent, candidates will just falter and fail in a whiteboard coding interview. I do, and many people I've interviewed have. Coding on the spot using pen and paper sucks. I think by coding. Give me Emacs and a REPL, and let me go away and think for a bit, and I'll produce something way better. Smaller companies should think twice before trying to emulate Google, Facebook, Microsoft, etc. In a small company social cohesion is very important, so rapport and personality are very important, cultural factors are important, experience in dealing with similar types of environments, familiarity with technical stack. That's how I used to interview before coming to Google, anyways. It seems like the industry has turned in very large part to this hostile "prove yourself" methodology...
- machogeek 10y ago
  I would gather if companies like the ones you mentioned adopted new ways of interviewing, or at least randomized it in way that it couldn't be easily cloned, other companies would follow suit or adopt their own style. The challenge is that every companies wants the "best" engineers and believes they deserve it... So in their minds, they do what they think the "best" do. I have heard more than a handful of CTO's and companies sling this expression around as if using this phrase put them in company with the likes of Elen Musk. It's a joke to me really. I look forward to the day one of these guys says, hey, lets be original. Contrary to your point, I believe there is a shortage of qualified programmers... or at least senior ones that can solve hard problems independently. Smaller companies need devs that can solve problems independently, with minimal oversight. Copying Google and Facebook is what they think the path is to get there.
  - pyb 10y ago
    If there was really a shortage of qualified programmers, companies would be working to improve their interview practices. From this thread, and my own experience, things are going the opposite way. Companies appear to be able to afford to use more and more arbitrary filters. Which indicates an excess supply of great candidates!
ChemicalWarfare 10y ago
My fav way of interviewing and being interviewed is a quick assignment (nothing major like some companies want you to build an api, crud UI to drive it and then push it out to heroku for them to look at) - either at home or just leave the candidate alone in the conf room for an hour. After that if they pass - few questions about their code, maybe drill down into some areas depending on the answers etc. Alternatively, if someone has a project on their github profile using the tech you're looking for - few questions about that project can typically give you a go/no-go right away.
DeBraid 10y ago
The whole hiring process is a nightmare for both parties. Two things I've learned about hiring / interviews: it's both very difficult and imprecise. Process is more like dating than laboratory science; a race to establish rapport (a combination of comfort and trust). To get hired you must sufficiently possess an arbitrary blend of credentials and testing/interview performance. Whatever it takes to make the hiring manager comfortable and trusting. Some want 10x-ers only, are soothed by strong technical chops/coding test performance, others select for culture and ability to learn. YMMV as selection criteria based on job description, sector, company stage, weather/etc. This is why personal referrals are so powerful: trust is established MUCH faster, other flaws will be overlooked.
cloudjacker 10y ago
lol I had to do the fizzbuzz test a few weeks ago the modulo operator was obvious to me and after the interviewer kept adding conditions to the problem, they then asked me why I didn't concatenate strings instead of my approach of returning the string in each conditional statement so fellow engineers, without having the telepathic skills I possessed that allowed me to know exactly what traits the interviewers were looking for, would you have: a) erased your entire correct solution to write a more efficient solution, not knowing the time constraints for this problem b) created the most efficient and scalable fizzbuzz solution known to man at the beginning? in the 15 minutes provided c) laughed in the interviewer's faces since it was obvious the question was irrelevant to how you would solve problems for the company on a day to day basis? d) other
freek4iphone 10y ago
I totally agree with most of the points Laurie made, specially I hate the new trend of asking people for an online coding test before even talking to a person. I have worked on a ton of complex problems in life and in real world you never have to write 4 complex tree traversal algorithms using the best possible approach in under 60 minutes, never!
mknocker 10y ago
Too often, the team fit is put aside and you end up with people who does not play well with others in your team. Technical interview can be ok but I would not put too much details into it. I have been in technical interviews where people were asking questions about obscure API calls and they were expecting applicants to come up with questions that were not relevant to the job.
pklausler 10y ago
Over the years and across 100's of technical interviews, I've found that I get the best results from asking smaller numbers of easier problem-solving-with-code questions that require the candidate to demonstrate basic skills. I'm the guy who makes sure that the candidate can clearly get over a low bar. I do this because the candidate pool is swimming with people with great-looking degrees and long resumes and fine references who can talk all day long about computer programming but who simply cannot program a digital computer. So I ask a 5-minute easy warm-up question and then a 40-minute harder problem. I pace things slowly and give them all the time that they need. I happily answer any questions they may have about the problems, which can all be stated clearly in short sentences. I do not care what programming language they use or whether their syntax would compile or how descriptive their variable names are. Essentially, I'm trying to not generate a "false negative" result. If you can't do my easy stuff, I really don't want to work with you. If you're a great candidate, you'll have fun with this and take it away in interesting directions. (Sample easy question: Given two closed intervals [a,b] and [c,d], determine whether they overlap.)
soham 10y ago
[Disclaimer: I run http://Interviewkickstart.com http://Interviewkickstart.com, which helps candidates suck less at technical interviewing.] I have conducted countless technical interviews in my lifetime. I agree with the author; it's very difficult to actually become a good interviewer. The skill to judge someone's life and career of several years in 30 to 60 minutes is not something that comes easily. Alas, it's all too assumed to be easy. When you start, for quite some interviews, you are very likely on either extreme viz. either too strict or too lenient. It takes a while to calibrate your standard, and not give in to an extreme. And that too, only if you introspect, or when someone draws your attention to your interview results. Many companies don't have a culture which values interviewing as a skill. Rarely if so, I come across a company which has a process of shadowing and reverse-shadowing in an interview, which they take seriously. It is viewed as a cost center, when it's actually a profit-center when done right. And due to my business, I have come across plenty of them. At least in the valley.
whack 10y ago
Every time I read one of these articles, the author invariably ends up recommending solutions that have glaring holes, just as large as the ones he spends the entire time attacking. In this case, the author begins the entire essay by telling us that we shouldn't hire on the basis of what someone already knows. One of his first solutions later presented is the exact opposite of this: find out about their level of existing knowledge, regarding specific technologies and frameworks. He then goes on to rile against "team fit," because of its potential for bias. But his entire solution basically comes down to behavioral interviews, which are notorious for how bias-prone they are. His solution basically tells us that we shouldn't consider fancy degrees or companies. And yet, in the span of 30-60 minutes, we should be able to form accurate judgement on how much talent and drive someone has, and what they will be able to do in the next 3 years? Sorry, but unless you're the Steve Jobs of character reading, there's no way you can do the above accurately. Everyone lies on interviews. They pad their accomplishments, and inflate what they have previously done. The only thing you achieve through such a discussion, is figuring out how good a talker someone is. The following article sums up everything that is wrong with almost every "Hiring is Broken" critique ever. Every single approach people have ever thought up, is broken in so many ways, as ably demonstrated by many others. Unless someone has hard data to show why one technique's pros outweigh its cons, such discussions are almost always pointless. http://www.thecaucus.net/#/content/caucus/tech_blog/684 http://www.thecaucus.net/#/content/caucus/tech_blog/684
up_and_up 10y ago
My optimal hiring process: 1. Screen resumes...throw out anything that seems bogus, hype-y etc. Time investment: 1-3 mins per resume. 2. Phone screen...ask them simple technical and project questions directly from their resume. They wrote it so they should know it. Generally, bullshitters are exposed right away. Time investment: 20-30 mins 3. Take home project. A somewhat simple but non-trivial project like: Write an autocomplete search script using a large text document as your dictionary. This will test their understanding of algos and software engineering best practices. Time investment: 10 mins to review the code 4. They talk with 3-4 other engineers. Those engineers now have a simple project to compare candidates and to question the candidate with. "Why did you choose this algo?", "How did you break down this problem?". Each engineer can ask whatever they want. Time investment: 30 mins. 5. Final engineering huddle. Compare candidates, pros and cons. Gut feelings. Etc. Time investment: 30 mins. The small take home project is extremely revealing and more useful IMO. You get to see their actual ability at coding a small feature. Is it well-composed? Did they include tests? Do I want to maintain his/her code? The project also spares the rest of the team from wasting time interviewing non-serious candidates.
- odonnellryan 10y ago
  > Time investment: 10 mins to review the code I never think this is fair. Why is it fair for the candidate to spend a day working on a project (which you will do for even simple projects, if you actually want to get hired) when it takes you ten minutes to review the code? > The small take home project is extremely revealing and more useful IMO. You get to see their actual ability at coding a small feature. Is it well-composed? Did they include tests? Do I want to maintain his/her code? Honestly, you don't get to see much if that person has a day job. You don't know who wrote it, if they had a friend review it, if they spent two or twenty hours on the project. You don't know anything about them by reading this project. If it is shit, yes, you probably shouldn't hire them. But if it is good code... 1) The user might be doing something your devs don't understand, because they are bad devs, not because they suck. 2) "Good code" is fairly subjective. I've written some pretty good code and been shot down for "not using a graphing database."
  - 10y ago
tn13 10y ago
I think the problem is not whether you can design a 100% awesome tech interview process that will have high precision and recall. That is known. Spend enough time with the person basically to judge him rather than asking few questions to taking him to whiteboard. But then most companies wont be able to show profits if the start spending that much resources on each candidate. Hence they optimize their processes only for precision and not for recall. That explains why a lot of people fail first few times.
deleted 10y ago
[deleted]
liquidise 10y ago
I had actually written a post a few months back[1] that bares a remarkable similarity to this one. It's encouraging to see others have, and are, coming to similar conclusions. Remember that each person who learns these methods now improves a round of interviews in the future. 1: https://blog.benroux.me/4-steps-to-making-your-interview-suck-less/ https://blog.benroux.me/4-steps-to-making-your-interview-suc...
probinso 10y ago
so I seem to be alone in this. although whiteboarding is not representative of Industry workflow, I feel that it can be used as a metric for communication. everybody knows that it's coming, and everybody knows how to practice it. if you perform poorly on whiteboarding that means you didn't practice it. it's a learned skill it's not a natural thing. anybody I've met who complains about having trouble in whiteboarding has also never seriously practiced it.

265 points by sgift 10y ago

Someone in a similar HN thread once recommended the book "Hiring With Your Head" and then sorta did a mic drop. I must do the same. Buy the book and implement it. It directly deals with so many issues mentioned here (great dev but crap at silly tests, great dev but a bad interviewer, etc).

skrebbel 10y ago

In all honesty, I'm not sure the author did a lot of interviewing. For example, > The famous fizzbuzz test simply asks "are you aware of the modulo operator?" Wait, what? No, it asks "can you write a for loop without breaking a sweat?". There's a rightfully vivid debate going on about the virtue of asking algorithmic questions in interviews, but fizzbuzz is hardly algorithmic. I'd wager that virtually all programmers iterate a collection at least once daily. The followup sentence drives it home for me: > Yet people will spend twenty minutes on it in an interview, a huge waste of limited time. Well, if it takes an applicant twenty minutes to Fizzbuzz, you're done! Just saved everybody lots of time. I used to think Fizzbuzz was insulting and bullshit until I started interviewing. I haven't yet met a programmer who couldn't solve a Fizzbuzz-level question, but I've met many who took over 10 minutes and made little logical errors. It's a great predictor for "can this person actually program, well, at all?".

ProfChronos 10y ago
Agree on technical questions + what he says on "team fit" really doesn't make sense: "You are NOT hiring for "team fit" I have never heard a definition of "team fit" that didn't end up sounding like "let our bias run free". Phrases like "looks like they belong here" are terrifying. More insidious are complaints like "doesn't like the same social activities we do". Grow up. Your office is not your frat house, and socializing with your co-workers outside of work is not some crucial test. There is no requirement that you like someone socially as long as you want to work with them." You don't ask people to be exactly like but you expect them to be able to work in a cool mood with you and to share things. Who would hire somebody that doesn't get along with the team??!!
- qaq 10y ago
  Team fit is actually pretty important as far as how long the Dev will stick around.
ktRolster 10y ago
* It's a great predictor for "can this person actually program, well, at all?".* How do you know, have you hired many who had trouble with the Fizzbuzz? Or are you just guessing? (I don't know either; there's a lot of missing data in interviews)
- Maakuth 10y ago
  Everyone I know doing recruiting says that FizzBuzz reliably disqualifies surprisingly large fraction of candidates. Even half of them, even after prefiltering by education or relevant experience.
  - LionessLover 10y ago
    That is a useless statement unless they followed the rejected candidates for a few more years at least. Otherwise it's just a tautology: They suck because my favorite test says so (i.e. because I say so). Sure it weeds out "non-programmers" - any programming task (more than "Hello World") does. But how many people who are good programmers and just suck a) under pressure, b) especially when surprised are falsely out-selected? I once failed to answer what a right join is. I got the (freelancer) job anyway - and of course I knew all along what that is, but when I got that question I had not used any joins in years (doing infrastructure work instead), and under interview pressure I can't think except along narrow lines. I ended up doing most of the complicated SQL queries in the department, with people coming to me because to me that was easy. After failing a very simple interview question on joins.
    - titzer 10y ago
      > That is a useless statement unless they followed the rejected candidates for a few more years at least. Otherwise it's just a tautology: They suck because my favorite test says so (i.e. because I say so). The same comment could apply to any rejection criteria. At my employer, we do have some data, since we do reinterview candidates after years in-between, especially if they are fresh from college. I can't speak for our organization but yes, basic programming hurdles do reliably weed out bad candidates. This is based on my experience of having done more than 150 technical interviews, all of which were balanced against the feedback of the other interviewers. Failing basic programming problems is a good predictor. > But how many people who are good programmers and just suck a) under pressure, b) especially when surprised are falsely out-selected? Any kind of test that is given to candidates has the same risk. But, let's break it down. Do you want to interview candidates for programming positions and _not_ have them program in some form or fashion during an interview? IMO that's nuts.
drinchev 10y ago
I agree with the author that Fizzbuzz is about the modulo operator if you present it to the candidate like that. What I would simply do is : "Write fizzbuzz test for language ... use the modulo operator, which is ... for that language" By doing this it's all about the loop. On top of that I think the author is right, because the pressure of the candidate is sometimes huge. I prefer giving a task that they can do at home. For example if it's a front-end position, it would be a small landing page. When I interview I usually tell the candidate : "I really enjoyed the conversation so far. Just to let you know, the management wants from us to get from every candidate a code sample, so I will have to give you a small task that you can do at home. I'm really sorry about that, but I think it will be also helpful for you to check out what exactly you will be doing here. Do it whenever you want, just make sure you have something by the end of the week. You can also ask me anything at ..." This sentence makes miracles. The candidate is motivated. The code is cleaner and though-trough. Then you can actually see if the person will be able to do the job.
- gavanwoolery 10y ago
  I can second the value of the take-home assignment. My last company, Appstem, gave them out, and it never once failed. It additionally succeeded in weeding out people who were not motivated enough to want the job.
dfabulich 10y ago
>> The famous fizzbuzz test simply asks "are you aware of the modulo operator?" > Wait, what? No, it asks "can you write a for loop without breaking a sweat?". There are notorious cases where senior engineers with years of actual honest coding experience "fail" fizzbuzz. IMO, That happens in two ways: 1) Not knowing (forgotten?) what a modulus operator is, and trying to code one up from scratch with a for loop. This can totally happen when you spend a few years working on line-of-business CRUD apps that never turn out to need modulus arithmetic. Coding modulus from scratch with just + - / * is a fun little challenge in its own right, but it'll probably take you longer than 10 minutes to write it correctly and solve fizzbuzz with it. That means you just took more than 10 minutes on fizzbuzz, which means you failed. 2) Trying to "clean up" the solution. http://c2.com/cgi/wiki?FizzBuzzTest http://c2.com/cgi/wiki?FizzBuzzTest has a good discussion on 'Why Fizz-Buzz is "hard:"', which points out that many of the most obvious solutions have code duplication, which some people then try to eliminate, tying themselves in knots trying to make it perfect. The third possibility, that a candidate with years of experience shipping code nonetheless struggles to write a for loop, is IMO just not as common as the above two failure cases. (Much more likely is that the candidate has lied/exaggerated on their resume.)
- corecoder 10y ago
  #2 happened to me: I wrote the straightforward implementation in a few seconds, and then struggled and tied myself up trying to eliminate the duplication, making it worse and worse, until I started panicking. Luckily the interviewer understood what was happening and changed subject.
- imtringued 10y ago
  >Coding modulus from scratch with just + - / * is a fun little challenge in its own right, but it'll probably take you longer than 10 minutes to write it correctly and solve fizzbuzz with it. It's surprisingly easy actually. var remainder = x - Math.floor(x/y)*y (Math.floor because javascript)
- benhoyt 10y ago
  If you don't know about modulus, you don't have to re-implement it. For Fizzbuzz you're looping anyway, so you can just maintain two counters, one that counts to 3 and resets, and one that counts to 5 and resets. When one of the counters resets, you know the main loop counter is a multiple of 3 or 5. Like so: def fizzbuzz_no_modulo(): counter_three = 1 counter_five = 1 for i in range(1, 101): output = [] if counter_three == 3: output.append('Fizz') counter_three = 0 if counter_five == 5: output.append('Buzz') counter_five = 0 if not output: output.append(str(i)) print(''.join(output)) counter_three += 1 counter_five += 1
imtringued 10y ago
The trick part of FizzBuzz is that the easiest solution relies on the magic "15".
- efaref 10y ago
  Even that's an unnecessary complication. The code solution should read like the spec, so that if someone comes along later to make FizzBuzz depend on some other set of constraints, they know what to do. The compiler can optimize away the duplicate tests. That's its job.
chrshawkes 10y ago
If you're so crafty at sifting through candidates to resort to FizzBuzz to help you do it, why do you have to copy and paste FizzBuzz, why not come up with something original?
- skrebbel 10y ago
  Actually I usually ask a comparably difficult question for fear that people might have actually remembered the solution to fizzbuzz by heart. But I didn't think it added to the discussion to mention that.
Clubber 10y ago
I think what he is pointing out is that if you don't know the modulus operator, you will fail FizzBuzz. The modulus operator is rarely used and somewhat obscure. The only time I use the modulus operator is when I'm writing something to track what record / rule I'm processing and I only want to show every 10,000th record or so. I can't think of a time I've used it otherwise.
- lmm 10y ago
  You can implement it yourself if you forget it. Or use a counter (urgh). Or ask whether there's a library function that does that.
PJDK 10y ago
I had a pretty interesting experience with this. We were doing a bunch of interviews and decided to try out FizzBuzz. I wasn't doing this round of interviews, but things ended up a bit confused with timings and I had a 30-40 minute very casual chat with each candidate prior to the actual interview. In each of those I ended up probing a bit on technical stuff and everyone seemed to have a decent base level of competence. But they all went to pieces over fizzbuzz in the interview. The one I actually saw, I had had a fairly in depth conversation about what it actually means to use "ref" and "val" in C#, but then watched the same guy freeze and barely scrape through fizz buzz. My conclusion is that some people just can't write code in that kind of environment. What makes it tricky is some people (myself included) find it easy or even fun - maybe I can write fizz buzz in a single LINQ statement...Those people can assume that everyone not like them can't code.
- jogjayr 10y ago
  I can confirm. I went to pieces once when asked to do FizzBuzz when I wasn't expecting to code in a phone interview. I'm not a "rock star" programmer but in the absence of pressure I can knock out a FizzBuzz in < 2 minutes. And I have written real software used by real users that made money for my employers.

gavanwoolery 10y ago

As someone who is going through many technical interviews right now, and failing all of them, I love this article. (It was actually brought to my attention last week.) My technical ability is readily apparent to those who have viewed my work, and by virtue of those who have praised it. I don't claim to be the best programmer in the world, just a competent one. I've also been programming for over 20 years, that might have something to do with it. However, I suck at interviews, in any way shape or form (personality tests, technical tests, you name it). Yet I've aced every job ever given to me, and people love to work with me (even in spite of my salty attitude). To think that you can determine what it is like to work with me over the span of a year within the span of an hour is completely and utterly ridiculous. As it turns out, the little sub-problems they give are the most trivial part of programming. The hard part, the part it takes many years to get any good at, is coherently organizing, documenting, and ensuring the stability of a larger system, particularly concurrently with other programmers. Or designing an algorithm that you can't just Google. Or making a really tough decision about what features to cut or what direction to pivot. Or organizing a vision of what will add the most value for the customer. Or...etc Being an introvert with a monotone voice, general lack of expression, and deadpan sarcastic humor does wonders for personality tests. Most people's default reaction to me (in interviews or otherwise) is that I am a total dick. Which I am, but the kind you don't mind hanging around. I don't do well with programming that has a one hour deadline. But give me a day and I can produce the typical output a programmer would within a day. If I spent all my time practicing for interviews, I'd probably be better at them (with stuff like Top Coder or Interview Cake or whatever). And I think giving these things a whirl is well worth it (not for the sake of winning in interviews). But it is not my life goal to be good at interviews. It is my goal to work in areas I am interested, and continue learning things that are directly relevant to my real-world tasks (sorry, writing a red-black tree on a white board within an hour never happens to me in the real world).

ktRolster 10y ago
But it is not my life goal to be good at interviews. It is my goal to work in areas I am interested, and continue learning things that are directly relevant to my real-world tasks You have to look at the programming career as requiring two skills: the first is programming, and the second is finding a job. That might suck, but it's the nature of a career where you change jobs every three years or so.

WaxProlix 10y ago

Oh man, I thought they were on to me, but no, it's for the givers of technical interviews. Phew.

gavanwoolery 10y ago
I chuckled :)

ktRolster 10y ago

When I interview, I try to find out what the person is good at. Everyone who comes to interview is good at something (even if it's just good at getting interviews). Sometimes their skill-set overlaps with what we need, sometimes it doesn't. But the focus is figuring out what they are good at, rather than an abstract test.

yardie 10y ago
Are you hiring? I've had a pretty miserable week of interviewing. Either I'm not the right fit or the potential employer is less than ideal.
- ktRolster 10y ago
  Right now I'm looking for a job, not hiring haha. The table is always spinning.

MrLeftHand 10y ago

With one of many job applications I did, I received a small coding exercise before getting to the actual interview. It was about writing a small application in perl (one of my favorite scripting languages) to solve a problem. It was a number converter from arabic to roman and vice versa. Anyway I started by looking up a perl module that solved the whole thing in 3-4 lines of code. What was the answer? Sorry that's not we wanted. We would like to see, how you would solve it with general code. So you're saying that doing investigation work, finding an existing working solution and applying that solution is not a good answer for you? Sorry but that's how I work. I find a problem; I investigate for a solution; if there is one I use it and implement it; if not then I will write one. The moral of the story is: interviewing is fundamentally wrong and doesn't help you find a good candidate. There are millions of good solutions to one problem in programming. Asking for a solution you want to see and not a solution that solves the problem will never help. Then why don't you clone yourself and have an army of developers which work the same way and produce the same code with the same flaws over and over and over.

dijit 10y ago
The issue is many companies have NIH syndrome, sometimes for a generally good reason. in the same circumstances I would have noted my find and copied the relevant code into my project, not because I'd do that in personal projects, but because companies only care about integrating their requirements with as few external dependencies as possible.
- MrLeftHand 10y ago
  Yes, that is a problem as well. They don't want to use libraries from the outside, so they develop a lot of stuff in-house. Which will have specific requirements and getting someone up to speed takes longer then using an existing API, which is well known and used by millions of other companies and developers. Also most of the times these in-house APIs are developed by if not one, but a handful of people. So if they leave, you are stuck with code which nobody understands and you keep on adding on top of it and breaking it in many ways. Not to mention your developers will be stuck and get experience with code not used anywhere else. If you want to cripple their prospect to get better jobs and experience, this is the way to go. It is a vicious cycle and it seems nobody is willing to break it.

itaysk 10y ago

Interviewing is hard.. I always hated the idea of judging someone based on a 1 hour chat (I was always the tech interviewer or first screen). I also hate that interviewers aim to challenge the candidate with hard technical questions that they might have or might have not had experience with. So what I do is ask the candidate to tell me about their experience, past projects, and also frankly ask them "what are you most comfortable talking about" and continue diving from here. When they talk about a topic they claim to be experienced with, you can really see what they worth. When someone can't fluently discuss something his claims to be knowledgeable in (yes that happened), that's a bad sign.

PuffinBlue 10y ago

There needs to be a bit of a shift in understanding what 'category' of worker a programmer 'is', both by companies and more importantly by (some) individuals themselves. Programming is both technical and artistic. It's a creative endeavour that relies on technical skill to complete. The best analogy to another profession would be to those in the 'technical arts', those like photography, joinery, painting, sculpture, drafting, perhaps writing too. It seems at the moment that companies are approaching programmers as if they are purely technical like an actuary or bookkeeper and are seeking to quantify artistic skill through interview tests. This is rubbing off on some programmers who begin to think of themselves in these terms. I don't recall a single instance as a photographer where I had to quantify my technical skill, but there were hundreds of times I had to based on my artistic skill, proving I had already made a vast range of photographs with sufficient quality to 'prove' my ability and by extension proving my technical ability. Crucially, it was the fact I had a portfolio that allowed me to prove my ability, both artistically and technically. I see a similar need in programming. I think programmers should create their portfolios of personal or paid for projects that showcase their technical and artistic skill and companies should take those seriously. At the moment it seems that far to many programmers are attempting to get jobs without a 'portfolio' which is why, in an creative endeavour like programming, companies that hire are trying to quantify and determine a new hires ability with these seemingly bullshit tests. There's room for improvement in this argument and there are outliers, but I think the basic premise is sound.

gavanwoolery 10y ago
That is actually a really great point. Its like hiring a writer based on their grammar. A writer could have perfect grammar but their books are boring as hell. Or even hiring a writer for adhering to the techniques of connoisseurs. The book "Ready Player One" was heavily criticized as amateur work (it was, after all, the author's very first book), but it nonetheless was hugely successful (and even has a movie in the making).
- mruniverse 10y ago
  Would you hire a writer with bad grammar?

deleted 10y ago

[deleted]

lambdabit 10y ago

The problem with his interviews is that it's even more easily gamed. It doesn't really take a genius to go through their employment history and memorize blurbs that show learning technologies, applying it successfully while being humble and nice for one day.

IndianAstronaut 10y ago
>while being humble and nice for one day Employers need to screen for this more. So many horrible people making it into workplaces and ruining work cultures.
vonmoltke 10y ago
If an interview like that can be gamed by "memorizing blurbs" then it wasn't done correctly. A properly conducted interview will see the interviewer tugging at threads to go deeper. At some point they will crack because memorization won't be enough. Unless of course they are anpathological liar, but those are rare enough that I would ignore the posssibility at the interview stage.
- lambdabit 10y ago
  You're right, I exaggerated but I don't think this is a hard game. People spend several months right now on studying interviews. The topics are wide and scope enormous, hence so many complaints; some companies test you on languages, others on algorithms, data structures, dynamic programming, bit manipulations, SQL queries, scalability, unix internals, I could go on and on. On the other hand, there's only so many paths these past history conversations can go, and you know where they can poke at.

skay_ 10y ago

A lot of people are saying that technical interviews are not good because some people are not good at them but they are indeed good software developers. Other people are saying that is impossible to judge someone in a few hours of technical interviews/exercises. I agree with both, but what's a better alternative? How to you minimise the risk of taking hiring a bad developer? At least, it is my belief that the technical interviews minimise the risk which is far better that ending up hiring someone who is not technically strong.

Clubber 10y ago
What I do is ask them about previous projects. 1. What was your favorite project and why? Explain. 2. What was your least favorite project and why? Explain. I can get a good idea of the person through those two simple questions. I throw a few simple technical questions like: What is a primary key? What is a foreign key? What is inheritance? What's the difference between a function and a procedure (Delphi days). Questions that anyone should be able to answer just by writing code.

l1feh4ck 10y ago

> Don't hire for a fancy degree. There are some companied coming to my college for hiring. The first criteria they put was 70% aggregate marks (60% for some companies). I have seen people who doesn’t know how to write even a small program getting hired, while people with good programming skills are not even eligible to attend the interview. Going through 200-300 candidates in an interview might be a tedious job, I am not sure. What other choice do they have?

MrLeftHand 10y ago
Had a coworker from a university, didn't even know how to write a while loop. He didn't last long to say the least. Of course we will never know, if he could have been a good programmer or not, but it was baffling to see people fresh out of uni with zero knowledge.
Taylor_OD 10y ago
I think the idea is that the "smart" person will be able to learn what they need to on the job quicker. The person with lower grades may be a better developer but right now of school I think most employees are hiring based on potential and culture fit vs actually development ability.

hanginghyena 10y ago

Hiring Manager Perspective: Everyone lies, sorry. As a candidate, I hate technical interviews. For the reasons above. As the poor schmuck asked to make the hiring decision, however, I've learned that I can't live without them. My technical isn't complicated. A very basic SQL assignment (delivered to an audience which claims to know SQL) that is followed by a few broader database design / data process QA questions. Entire assignment is 100% job relevant (in fact, my SVP asked for a copy of the report it generates when he saw the problem on my whiteboard). I don't care about the details of syntax. I do care, however, about candidates who produce SQL code which looks like the bastard love child of LISP and Java. About candidates who claim to know a skill but literally cannot write even basic syntax on the whiteboard. Who put "certificates" from Oracle on their bloody resume and break down under super gentle questioning and confess their tutor hasn't taught them JOINS (wtf ?) yet, never mind 5 years of claimed SQL experience at a big company on their resume. The coding question is most definitely not an exercise in sadism. We validated it with several new hires who were confirmed to be "good at SQL". Average completion time: 2 minutes, generally with trolling about why do we waste our time with easy stuff. That being said, my rejection rate from a basic coding interview is at least 50%, grading liberally and generally supported by several members of my team shaking their head about a candidate. I've tried screening resumes, I've tried doing non-coding phone screens. IT DOESN'T WORK. Actually, all it does is eliminate the socially challenged and non-communicative (who actually tend to pass the whiteboard test) in favor of the liars. And don't get me started about Python. Lest I bring up the Google-Motorola "I LUV Python heart heart heart" guy who didn't understand the difference between a list & dict.

heartsucker 10y ago
I've had the same experience. Someone listed 2 years Scala experience on a resume, but couldn't explain Unit, None, null, and Nothing to me. Or the guy this week who had several years of ops experience and when asked "how can you tell what indexes are being used in a SQL query" didn't even know about EXPLAIN. Basic technical interviews are a must, but someone people get hung up on "they couldn't explain a hash map implementation," because sometimes "you put a thing in the map and then get it back out later" is good enough for 99% of startup engineering tasks. Somewhere out there is a sweet middle ground, but it seems not one agrees where it really is.

bbcbasic 10y ago

I want this guy to interview me. Even if there is no job. I'm sure I'd feel a million dollars by going through the process.

seanwilson 10y ago

Some people are just bad at giving interviews. If someone is so bad at interviewing they will eliminate a candidate because they slipped up a little with a programming teaser, they're still going to be bad at interviewing if they try another technique. I'm completely happy doing programming puzzles in interviews myself as I've worked with people that claim to be experts in something when they aren't and some people exaggerate to the point of lying on CVs. As long as you don't penalise a candidate too much for not getting perfect answers I don't see the issue.

DrNuke 10y ago

Apart of job-related questions and general-thinking problems, tech interviews are still mostly a poor Tinder experience.

cmrdporcupine 10y ago

That companies now insist on running the Google-style whiteboard-algorithms-coding-skill-testing-question type of interview tells me that there is no shortage of programmers to hire. Because as far as I understand it we use that process at Google because we can afford a lot of false negatives because we are inundated with a lot of resumes. Smaller companies and startups surely are not, and finding candidates must be harder. Unless the job market is saturated with candidates. Many perfectly good, maybe even excellent, candidates will just falter and fail in a whiteboard coding interview. I do, and many people I've interviewed have. Coding on the spot using pen and paper sucks. I think by coding. Give me Emacs and a REPL, and let me go away and think for a bit, and I'll produce something way better. Smaller companies should think twice before trying to emulate Google, Facebook, Microsoft, etc. In a small company social cohesion is very important, so rapport and personality are very important, cultural factors are important, experience in dealing with similar types of environments, familiarity with technical stack. That's how I used to interview before coming to Google, anyways. It seems like the industry has turned in very large part to this hostile "prove yourself" methodology...

machogeek 10y ago
I would gather if companies like the ones you mentioned adopted new ways of interviewing, or at least randomized it in way that it couldn't be easily cloned, other companies would follow suit or adopt their own style. The challenge is that every companies wants the "best" engineers and believes they deserve it... So in their minds, they do what they think the "best" do. I have heard more than a handful of CTO's and companies sling this expression around as if using this phrase put them in company with the likes of Elen Musk. It's a joke to me really. I look forward to the day one of these guys says, hey, lets be original. Contrary to your point, I believe there is a shortage of qualified programmers... or at least senior ones that can solve hard problems independently. Smaller companies need devs that can solve problems independently, with minimal oversight. Copying Google and Facebook is what they think the path is to get there.
- pyb 10y ago
  If there was really a shortage of qualified programmers, companies would be working to improve their interview practices. From this thread, and my own experience, things are going the opposite way. Companies appear to be able to afford to use more and more arbitrary filters. Which indicates an excess supply of great candidates!

ChemicalWarfare 10y ago

My fav way of interviewing and being interviewed is a quick assignment (nothing major like some companies want you to build an api, crud UI to drive it and then push it out to heroku for them to look at) - either at home or just leave the candidate alone in the conf room for an hour. After that if they pass - few questions about their code, maybe drill down into some areas depending on the answers etc. Alternatively, if someone has a project on their github profile using the tech you're looking for - few questions about that project can typically give you a go/no-go right away.

DeBraid 10y ago

The whole hiring process is a nightmare for both parties. Two things I've learned about hiring / interviews: it's both very difficult and imprecise. Process is more like dating than laboratory science; a race to establish rapport (a combination of comfort and trust). To get hired you must sufficiently possess an arbitrary blend of credentials and testing/interview performance. Whatever it takes to make the hiring manager comfortable and trusting. Some want 10x-ers only, are soothed by strong technical chops/coding test performance, others select for culture and ability to learn. YMMV as selection criteria based on job description, sector, company stage, weather/etc. This is why personal referrals are so powerful: trust is established MUCH faster, other flaws will be overlooked.

cloudjacker 10y ago

lol I had to do the fizzbuzz test a few weeks ago the modulo operator was obvious to me and after the interviewer kept adding conditions to the problem, they then asked me why I didn't concatenate strings instead of my approach of returning the string in each conditional statement so fellow engineers, without having the telepathic skills I possessed that allowed me to know exactly what traits the interviewers were looking for, would you have: a) erased your entire correct solution to write a more efficient solution, not knowing the time constraints for this problem b) created the most efficient and scalable fizzbuzz solution known to man at the beginning? in the 15 minutes provided c) laughed in the interviewer's faces since it was obvious the question was irrelevant to how you would solve problems for the company on a day to day basis? d) other

freek4iphone 10y ago

I totally agree with most of the points Laurie made, specially I hate the new trend of asking people for an online coding test before even talking to a person. I have worked on a ton of complex problems in life and in real world you never have to write 4 complex tree traversal algorithms using the best possible approach in under 60 minutes, never!

mknocker 10y ago

Too often, the team fit is put aside and you end up with people who does not play well with others in your team. Technical interview can be ok but I would not put too much details into it. I have been in technical interviews where people were asking questions about obscure API calls and they were expecting applicants to come up with questions that were not relevant to the job.

pklausler 10y ago

Over the years and across 100's of technical interviews, I've found that I get the best results from asking smaller numbers of easier problem-solving-with-code questions that require the candidate to demonstrate basic skills. I'm the guy who makes sure that the candidate can clearly get over a low bar. I do this because the candidate pool is swimming with people with great-looking degrees and long resumes and fine references who can talk all day long about computer programming but who simply cannot program a digital computer. So I ask a 5-minute easy warm-up question and then a 40-minute harder problem. I pace things slowly and give them all the time that they need. I happily answer any questions they may have about the problems, which can all be stated clearly in short sentences. I do not care what programming language they use or whether their syntax would compile or how descriptive their variable names are. Essentially, I'm trying to not generate a "false negative" result. If you can't do my easy stuff, I really don't want to work with you. If you're a great candidate, you'll have fun with this and take it away in interesting directions. (Sample easy question: Given two closed intervals [a,b] and [c,d], determine whether they overlap.)

soham 10y ago

[Disclaimer: I run http://Interviewkickstart.com http://Interviewkickstart.com, which helps candidates suck less at technical interviewing.] I have conducted countless technical interviews in my lifetime. I agree with the author; it's very difficult to actually become a good interviewer. The skill to judge someone's life and career of several years in 30 to 60 minutes is not something that comes easily. Alas, it's all too assumed to be easy. When you start, for quite some interviews, you are very likely on either extreme viz. either too strict or too lenient. It takes a while to calibrate your standard, and not give in to an extreme. And that too, only if you introspect, or when someone draws your attention to your interview results. Many companies don't have a culture which values interviewing as a skill. Rarely if so, I come across a company which has a process of shadowing and reverse-shadowing in an interview, which they take seriously. It is viewed as a cost center, when it's actually a profit-center when done right. And due to my business, I have come across plenty of them. At least in the valley.

whack 10y ago

Every time I read one of these articles, the author invariably ends up recommending solutions that have glaring holes, just as large as the ones he spends the entire time attacking. In this case, the author begins the entire essay by telling us that we shouldn't hire on the basis of what someone already knows. One of his first solutions later presented is the exact opposite of this: find out about their level of existing knowledge, regarding specific technologies and frameworks. He then goes on to rile against "team fit," because of its potential for bias. But his entire solution basically comes down to behavioral interviews, which are notorious for how bias-prone they are. His solution basically tells us that we shouldn't consider fancy degrees or companies. And yet, in the span of 30-60 minutes, we should be able to form accurate judgement on how much talent and drive someone has, and what they will be able to do in the next 3 years? Sorry, but unless you're the Steve Jobs of character reading, there's no way you can do the above accurately. Everyone lies on interviews. They pad their accomplishments, and inflate what they have previously done. The only thing you achieve through such a discussion, is figuring out how good a talker someone is. The following article sums up everything that is wrong with almost every "Hiring is Broken" critique ever. Every single approach people have ever thought up, is broken in so many ways, as ably demonstrated by many others. Unless someone has hard data to show why one technique's pros outweigh its cons, such discussions are almost always pointless. http://www.thecaucus.net/#/content/caucus/tech_blog/684 http://www.thecaucus.net/#/content/caucus/tech_blog/684

up_and_up 10y ago

My optimal hiring process: 1. Screen resumes...throw out anything that seems bogus, hype-y etc. Time investment: 1-3 mins per resume. 2. Phone screen...ask them simple technical and project questions directly from their resume. They wrote it so they should know it. Generally, bullshitters are exposed right away. Time investment: 20-30 mins 3. Take home project. A somewhat simple but non-trivial project like: Write an autocomplete search script using a large text document as your dictionary. This will test their understanding of algos and software engineering best practices. Time investment: 10 mins to review the code 4. They talk with 3-4 other engineers. Those engineers now have a simple project to compare candidates and to question the candidate with. "Why did you choose this algo?", "How did you break down this problem?". Each engineer can ask whatever they want. Time investment: 30 mins. 5. Final engineering huddle. Compare candidates, pros and cons. Gut feelings. Etc. Time investment: 30 mins. The small take home project is extremely revealing and more useful IMO. You get to see their actual ability at coding a small feature. Is it well-composed? Did they include tests? Do I want to maintain his/her code? The project also spares the rest of the team from wasting time interviewing non-serious candidates.

odonnellryan 10y ago
> Time investment: 10 mins to review the code I never think this is fair. Why is it fair for the candidate to spend a day working on a project (which you will do for even simple projects, if you actually want to get hired) when it takes you ten minutes to review the code? > The small take home project is extremely revealing and more useful IMO. You get to see their actual ability at coding a small feature. Is it well-composed? Did they include tests? Do I want to maintain his/her code? Honestly, you don't get to see much if that person has a day job. You don't know who wrote it, if they had a friend review it, if they spent two or twenty hours on the project. You don't know anything about them by reading this project. If it is shit, yes, you probably shouldn't hire them. But if it is good code... 1) The user might be doing something your devs don't understand, because they are bad devs, not because they suck. 2) "Good code" is fairly subjective. I've written some pretty good code and been shot down for "not using a graphing database."
- 10y ago

tn13 10y ago

I think the problem is not whether you can design a 100% awesome tech interview process that will have high precision and recall. That is known. Spend enough time with the person basically to judge him rather than asking few questions to taking him to whiteboard. But then most companies wont be able to show profits if the start spending that much resources on each candidate. Hence they optimize their processes only for precision and not for recall. That explains why a lot of people fail first few times.

deleted 10y ago

[deleted]

liquidise 10y ago

I had actually written a post a few months back[1] that bares a remarkable similarity to this one. It's encouraging to see others have, and are, coming to similar conclusions. Remember that each person who learns these methods now improves a round of interviews in the future. 1: https://blog.benroux.me/4-steps-to-making-your-interview-suck-less/ https://blog.benroux.me/4-steps-to-making-your-interview-suc...

probinso 10y ago

so I seem to be alone in this. although whiteboarding is not representative of Industry workflow, I feel that it can be used as a metric for communication. everybody knows that it's coming, and everybody knows how to practice it. if you perform poorly on whiteboarding that means you didn't practice it. it's a learned skill it's not a natural thing. anybody I've met who complains about having trouble in whiteboarding has also never seriously practiced it.