8 ms·

Destroy all hiring processes

112 points by ubernostrum 11y ago

Mithaldu 11y ago
> even if we don’t have a sense of ethics we do have a problem of numbers, and more desks and seats and spots than people to fill them I get this a lot, but it is amazingly self-inflicted. Almost all of the random job offers i seem to be getting from people i don't know are from clients who: - underpay - demand on-site only - don't even look at the copious provided code samples, only at the CV The reason for that is simple: A lot of companies view developers as identical to factory workers. There is nothing more to it. -- Sadly i think this is not something that writing blog posts about can possibly help. The people making these mistakes when looking for developers make them because they are ignorant and do not care enough to gather the required knowledge. Until they realize their "illiteracy" and wish to fix it themselves, the scale of this education problem makes it unassailable.
- ubernostrum 11y ago
  I left out some of my frustrations simply because there wasn't room for everything and the piece was already getting long. I've also run into the "OK, you got through all the interviews, here's an offer for a contracting slot rather than employment". I've run into impossibly-broad non-compete agreements that I simply can't sign without risking my livelihood if the position doesn't work out. I've run into interviewers who didn't know basic things about the tech they were interviewing me on. I've also gotten a few speculative recruiters who are just obviously going off a list of auto-slurped email addresses from GitHub and not taking the time to match up positions to skills (including one person who very persistently wanted me to look into a job writing C++ all day). And on the flip side I've applied speculatively to a few smaller shops that looked like they were doing interesting stuff, only to get the "we think you're overqualified and can't afford you" reply.
- xacaxulu 11y ago
  >> demand onsite only!! The companies making the most demands usually offer the least. My favorite new flavor is recruiters saying "well for remote the pay rate is lower" to which I answer, "will I be doing less work in that case?".
  - MCRed 11y ago
    Interesting... as I have taken to giving the random LinkedIn recruiters two rates-- one an on site rate and one a remote rate. The remote rate is my normal rate, which is lower than the on-site rate which has a healthy have-to-go-into-an-office premium. When you couple that with the higher productivity of remote work, the smart employer will let me work remotely (at least most of the time.)
    - Mithaldu 11y ago
      Same here, i quote them my current rate for remote work, and for on-site work they get a markup.
blizkreeg 11y ago
> Even among the most common demographics for developers (American, male, white, skewing young and middle-class background), we are absolutely abysmal at this.. How does nationality, gender, race, age, and income level have _anything_ to do with this at all?
- ubernostrum 11y ago
  People tend, consciously or not, to recruit most heavily from among people like themselves (for lots of reasons which aren't necessarily bad: a lot of referrals are based on knowing someone, for example, and a lot of peoples' social circles/contacts tend to be pretty homogeneous to begin with). In other words, even on the easiest default approach (recruiting from people similar to ourselves), we suck. God help us as we try to recruit from people dissimilar to ourselves.
  - blizkreeg 11y ago
    IMHO you are subconsciously profiling if that is what you're doing in your hiring i.e., making assumptions about people's skills/talent based on any of those attributes.
    - URSpider94 11y ago
      That's exactly what you are doing, and there is copious data out there to say that we all do it. The generally accepted term is "unconscious bias." I saw a summary of a study recently in which people were asked to rate top character indicators of success for male and female candidates for a job, things like "aggressive," "nurturing," "outspoken," "mediator." Not surprisingly, the adjective sets for male and female candidates were substantially different.
    - URSpider94 11y ago
      Cite here: http://www.catalyst.org/system/files/Women_Take_Care_Men_Take_Charge_Stereotyping_of_U.S._Business_Leaders_Exposed.pdf http://www.catalyst.org/system/files/Women_Take_Care_Men_Tak...
- 11y ago
DrJokepu 11y ago
I disagree with this. Coding interviews are great. The interviewer needs to realise though that they're not there to be an adversary or a judge, but to help the candidate demonstrate their skills, to help the candidate get the job.
- toolz 11y ago
  I feel like all you're saying is 'Coding interviews could be great' not 'coding interviews are great'.
- NhanH 11y ago
  Coding interviews are great if the interviewers are perfectly rational and omnipotent agents. They need to be able to perceive the job, derives the set of abilities that is necessary for it taking into account and predicting future changes. Asking the set of questions that will subsequently narrow down the candidate's ability (while understand the answer, obviously). All the while gauging candidate's "social skill" and "team work" ability, among with any and all trending required characteristics there are. Oh, and you got an hour to do that. You have 5 interviewers going through the same candidate? Fine, they need to be one-fifth omnipotent. Good luck with that.
- fooster 11y ago
  Depends what you mean. If you mean google style whiteboarding coding interviews are great I'm here to tell you they are not. I've never been payed to write code on a whiteboard, have you?
- 1stranger 11y ago
  That's the theory but it doesn't work in practice. Interviewing other developers is a skill and it's a skill that most developers don't have.
jvanderbot 11y ago
I would offer that the subtle point missed in coding interviews is the ability of the interviewer to judge the flexibility, poise, and social skills of the interviewee. That seemed very important during my interviews. This may be why the best advice is to "talk it out" Any yay-or-nay judgements based on hastily-written program output should be taken with a grain of salt by both parties.
dustywusty 11y ago
As both an interviewer and interviewee at Weebly, I'm pretty confident in saying I prefer our approach of the trial week. It really gives a great opportunity for the candidate to show off their skills without the on-the-spot pressure of a coding interview. A great side-effect is the candidate gets to determine if they like the team, and vice versa. I honestly wouldn't work somewhere else where I couldn't come in for at least a few days to meet and work with the team.
- nickonline 11y ago
  This is pretty rough on any interviewee who already has a job as they'd have to take holiday days to interview. Do you give them a week off in lieu if they get the job?
  - msandford 11y ago
    What happens if they don't get the job, and they burned 1/3 of their year's vacation?
- tomtang0514 11y ago
  But how do you handle the case that candidates already have a job somewhere else? They can't take a whole week off for this.
  - dustywusty 11y ago
    I took a week off at my previous job to trial at Weebly. My previous job had a very strict vacation policy, but I knew the importance of what I was doing. Weebly has an unlimited vacation policy, so, it worked out pretty well.
    - duderific 11y ago
      What a disaster though, if you didn't get the job. 1) Lose a week of PTO, and 2) Feel really bad that the people you spent a week with didn't think you were good enough. Also, from the Weebly end of things, what if you know a couple days in that the candidate isn't going to work out? Cut them off right then or finish out the week?
teen 11y ago
this article is awful. it cites a single bad coding interview as a problem with all coding interviews. as someone who gives tons of code interviews, they are absolutely invaluable, and are a strong indicator in weeding out people who can't write code. you can't blame bad interviewers for the entire process not working.
- ubernostrum 11y ago
  I have, in the recent past, done multiple coding interviews. Thus far none of them have been useful to me, and none of them have provided information the interviewers couldn't have gotten already from my GitHub contributions. The single personal anecdote was meant to reinforce my points: from that interviewer's perspective there's a good chance that I'll be one of those "people who can't write code" who forms the basis of later stories about how great it is to use coding interviews as a filter. Meanwhile, I do go into some detail about the issues with coding interviews in general, and the way they can affect and accidentally weed out candidates a company probably didn't want to weed out that way. Also, the "nobody can really code, you have to do this to filter them" thing is approaching cargo-cult status at this point. Further up in the section on education I touched on some reasons why I think those situations happen.
- gqvijay 11y ago
  Slippery slope fallacy...You are incredibly oversimplifying what he is saying. Sure, he is generalizing but he isn't citing a single coding interview to judge the entire process. Having said that, I actually agree with him because I've learned that it's not always simple as who can't write code. I would much rather assess a candidates' ability to learn (sharpness) than the current skill-set.
  - fieryeagle 11y ago
    Second this, but Joel Spolsky said it much better http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html http://www.joelonsoftware.com/articles/ThePerilsofJavaSchool...
msoad 11y ago
I'm working on open source stuff for two years now. Everything I do is public for everyone to see. Including my responses to bug reports and design documents. Yet I get the same algo/ds puzzle questions that you should've solved before in order to solve it in an interview setup. Google reached to me and said based on my profile I can skip the phone interview but I'm so afraid of the interview that I postponed it multiple times. I'm fine with algorithm questions only if I'm solving it in the same setup as my actual work where I have access to internet and can write some quick programs to test my ideas. I was good at solving pretty much any problem I had in my actual work. Even if I had to read a paper on the topic or learn about a new concept from ground up. Google asks questions like pots of gold[1] where it's really impossible to solve it on a whiteboard if it's your first time seeing the problem. I'm on hiring side of equation also. I get it, it's really hard to judge people. Even when the candidate have a GitHub page. I got a candidate from Hack Reactor where he had tons of contributions. But when I looked closely at those contributions they were mostly fake. Some other candidate had exactly same codebase in their GitHub. [1]: http://careercup.com/question?id=15422849 http://careercup.com/question?id=15422849
- qmalxp 11y ago
  It's not impossible to solve those types of problems if you prepare ahead of time. I think that problem just requires dynamic programming/memoization, which is one of the things you're told to study beforehand.
- skimpycompiler 11y ago
  These problems aren't that hard, although they do not say anything about the person that solves them. One can prepare for a Google interview in 1-3 months and I'm sure there's a pretty high chance they would pass it. I've seen tens if not more people from my unknown middle EU university nail the interviews, ending up with jobs at Google, Facebook, Microsoft etc. and I've cooperated with some of them, knowing that their programming skills and knowledge, teamwork are lacking. But they can solve some simple dynamic programming problems, or maybe a silly breadth-first-search, and they'll get the job. I, personally, wouldn't like to be hired at a firm that evaluates me that ridiculously. Yes, I'm a fresh graduate but thinking that knowing Dijkstra's algorithm evaluates my abilities makes me believe the whole culture is entirely deformed and I do not want to be fascinated by these ridiculous puzzles when I'm working with others. Give them a week to implement something of larger complexity and they are drowned by so many concepts they decided to skip to earn an internship/full-time position at their beloved giants. But I guess giants can afford having engineers that aren't that productive, or aren't doing projects that matter. I wouldn't like to be one of these engineers. So, the real question is do you want that, or is the cash blinding you? :D Books like these below can increase your chances significantly: http://www.amazon.com/Elements-Programming-Interviews-Insiders-Guide/dp/1479274836/ref=sr_1_1?s=books&ie=UTF8&qid=1445301895&sr=1-1&keywords=Elements+of+Programming+Interviews http://www.amazon.com/Elements-Programming-Interviews-Inside... http://www.amazon.com/Competitive-Programming-3rd-Steven-Halim/dp/B00FG8MNN8/ref=sr_1_1?ie=UTF8&qid=1445301997&sr=8-1&keywords=competitive+programming http://www.amazon.com/Competitive-Programming-3rd-Steven-Hal... http://www.amazon.com/Cracking-Coding-Interview-6th-Edition/dp/0984782850/ref=pd_sim_14_2?ie=UTF8&refRID=1B0CS1XQC5YD255KDVY1&dpID=51lcgdiQAlL&dpSrc=sims&preST=_AC_UL160_SR112%2C160_ http://www.amazon.com/Cracking-Coding-Interview-6th-Edition/...
deleted 11y ago
[deleted]
flippyhead 11y ago
It's funny, I've tried tons of different approaches to solving this problem and the only thing I now do is spend about 30 minutes with someone then decide to hire or not (usually I'm able to express this on the spot to whomever I'm interviewing). For better or worse, my instincts about who is smart, honest and kind seem at least as good (and often better) than any other approach we've tried.
- fishtoaster 11y ago
  I'm curious how you validate that approach. I'm not saying you're wrong– just that I don't know if you'd be able to tell if you're wrong. Do you measure the performance of people hired through that method, and have you done so for a long period with a significant sample size? Do you manage to measure your false-negative rate (by somehow following up on candidates you passed on)?
  - flippyhead 11y ago
    Well, the false-negative rate is something we never did even when we tried all kinds of other "standard" interview approaches. If you had a solution for that it'd be useful generally I expect. I'm only make anecdotal comparisons to the quality of persons hired by all other approaches vs. me just using the massive pattern matcher in my head. And to be sure, my company is small and it's my company so the ultimate determinant of hiring quality is really just me. I'm not sure this approach would work for medium+ organizations.
- Gibbon1 11y ago
  Your comment made me think these extreme interviewers are like a gardener who want to find that one true seed that will thrive when they plant it in a flower pot full of broken glass and gravel. Also reminds me of a comment by Robert Townsend. Which is a warning about following the practices of the biggest most illustrious firms. In his day that was General Motors etc. Today it's Apply and Google. I think those guys can spend a buttload of time and money looking for the perfect fit out of the line out the door of candidates because, it matters. Bad/Good hire could cost or make the company millions of dollars. It's also hard fire when your company is large. Your dinky company? A misperfect fit is going to cost you thousands to tens of dollars.
gfodor 11y ago
"People who have a master’s degree in CS but seemingly can’t code their way out of a paper bag probably actually aren’t bad; more likely they had an education which de-emphasized practical hands-on programming in favor of heavy theory. People who post “please give me the code” questions on mailing lists and forums probably actually aren’t bad; more likely they had an education which was based around memorizing and regurgitating stock answers to stock questions." What does this even mean? When someone lacks a certain skill, they aren't "bad" in some objective sense, they are misqualified for the job. If someone can't code their way out of a paper bag, should we be hiring them anyway for a programming position because they're not "bad"? What's the point of the interview in the first place? I don't understand the argument. To the other points, I completely agree there are many ways to screw up interviews and few ways to get them right. I'm still a believer that an interviewer who administers a coding question, one that is reasonably realistic, in both form and the environment the candidate has (ie they have their own laptop) can be a good way to assess someone's skills if you are doing it right. You let them work, let it be a humane environment, and don't get too hung up on the details. Usually if someone can hack it bleeds through pretty clearly, even if they don't get to the exact solution you wanted. (And of course, this is just one data point, that should be distilled into a larger picture of the person's history, accomplishments, etc.)
- supercanuck 11y ago
  I'm just kind of flabbergasted that someone with 6 years of matriculation from Computer Science Program has resulted in the equivalent of a truck driver spending four weeks on Code Academy. It just doesn't jive... >I have a philosophy degree, by the way. Not to be smug about it, but several very good people I know and respect in the software field came to it from that background. Ahh... now it makes sense...
  - mrep 11y ago
    I believe he is referring to people who got there bachelors in a different major, and then got their masters in CS.
- ubernostrum 11y ago
dx211 11y ago
A couple of years back, I was hiring some vendor developers for my team, and since I had some flexibility in the interviews that wouldn't be allowed for full-time employees, I tried an experiment: For one of the vendor candidates, I told him a day ahead of time that I'd be asking him to implement System.Collections.Hashtable in C#, with behavior equivalent to the one in .Net. The day of the interview came, and he whiteboarded it flawlessly, to a degree that I'd never seen any other candidate accomplish, and he was able to have a deep conversation about the implementation and all of its nuances. He then proceeded to bomb the rest of his interviews and didn't get the position. What this illustrates to me is that the typical programmer interview, where we come up with some weird problem and toss it to the candidate while they have no references to look at, no IDE to type into, and a 45 minute deadline looming over their head, is totally divorced from the actual work we actually really want them to do. If I need someone to implement a widget, I'd rather they took some time to research it and do it right, versus trying to crap out a solution in five minutes on a whiteboard.
- davnicwil 11y ago
  Brilliantly put. When I'm giving interviews I really like it when a candidate posed with a fairly complicated problem or design question pauses and actually thinks, then says something like "..well, I don't really know, I'd probably want to think about it more, but here's an idea" before putting forward their likely non-optimal but totally plausible and on-the-right-track design or solution that they thought of on the spot. Under-confidence in an answer (straight up asking for validation i.e. is this right?) or over-confidence (expecting to shoot straight from the hip with the perfect, 'right' solution, or just a plain old bullshitter implicitly insisting that anything they say is correct) are usually red flags for an extreme personality type - always exceptions to this but as a general rule, I've found it to be true - and the happy middle ground, coupled with answers that obviously point towards a depth of knowledge and skill, is what you're looking for. Trying to follow my own advice, I've done this myself as well when I'm the interviewee. Side benefit - if the interviewer actually is looking for a 'right answer' to complex questions out of the blue and on the spot - good for them if that's what they want but I'd want to self-select myself out of that type of expectation and working relationship. So everybody wins.
aurelianito 11y ago
When an actor goes to an interview (aka: casting) twice, he gets paid. I think we need this in this industry. A lengthy interview should be remunerated.
- kyllo 11y ago
  That's because actors have a union.
  - aurelianito 11y ago
    We need a union then.
aggieben 11y ago
> a belief that memorizing a bunch of that stuff and being an automaton who spits back the correct algorithm name and a pseudocode implementation is all there is to programming. Because what companies really want is to hire a Fisher-Price See-‘n-Say toy, right? I get the overall rant. I understand the frustrations - but this is wrong-headed. If you can't see the value of understanding algorithms - learning both how to write them and how to evaluate them (including proving their correctness), then you've misunderstood computer science education altogether. Nevermind all the rest of CS, which encompasses far more than just "names of algorithms".
- ubernostrum 11y ago
  It's more that there's a lot of cargo-culting and "Google did this, so it must be good" flying around, and a lot of really bad CS programs which revolve more around the Feynman-rant memorize-and-regurgitate style than actually understanding performance characteristics. Which in turn produces interview processes that really are of the See-'n-Say variety. Though to be honest, for a lot of what I do my working set in memory (metaphorically) involves very very little algorithms/data-structures stuff and a lot more quirks of libraries/frameworks/protocols stuff. When I need the algorithms and data structures, I pick up the reference I keep on my desk and look up the thing I'm thinking about to double-check that I'm using the right approach.
  - aggieben 11y ago
    Fair enough, but then you should explain that what you're against is mindless regurgitation, not good CS education (which again, has algorithms at its core, but goes far beyond that).
    - ubernostrum 11y ago
      I think that what you seem to be treating as "good CS education" is something I'd be more likely to call "good math education, but probably not great training for programming". A big part of the problem is over-generalization. Here's a reddit comment I posted in a similar discussion not too long ago, touching on that: https://www.reddit.com/r/Python/comments/3nfbkr/patreon_is_a_flask_app_and_was_hacked_because/cvobo03 https://www.reddit.com/r/Python/comments/3nfbkr/patreon_is_a... The person I was replying to there had made the mistake of assuming that because in these fields of programming, knowledge of data structures, algorithms and big-O characteristics is one of the most important things for performance, that must be true of all fields. When, in fact, it's not true of all fields, and I provided an example of one where it isn't true and where quizzing someone on their big-O cheat sheet wouldn't actually reveal whether the candidate has the most relevant knowledge for what's going on.
NullCharacter 11y ago
As someone in the computer science/cyber security field who didn't go to college, I tend to agree with this article in a few ways. Having no college degree has really hindered me in terms of landing interviews, but once I'm given a chance on the job I'm always flourished and proved my worth. I've also found it strange that it didn't matter what my degree was in, just having one wold have secured me interviews. A theoretical degree in Turfgrass Science would have benefited equally as a proper degree in CompSci.
dkarapetyan 11y ago
Try triplebyte. Their process is actually pretty good.
fishtoaster 11y ago
I'm of the opinion that pretty much every interview technique has at least some tradeoffs. Too many false positives, too many false negatives, selecting for or against certain groups, etc. At my current company, we don't do any phone-coding or whiteboard-coding, for which I am very thankful (for the reasons the article laid out). We do do a take-home dev test (4-6 hours). This has the benefits of being low-pressure, repeatable, and similar to the real work we do. It has the tradeoff that we might miss out of great devs who don't have the time to do it. We're working on shortening it to offset that. We also do a bit of paired programming on-site (using the candidates computer and dev environment of choice). This has a distinct tradeoff, since it can be a bit high-pressure. We try to do everything we can to ease candidates, but I haven't found anything else that works well for getting a feel for what it's like to work with someone in a technical capacity. Every interviewing technique has issues, and I think phone and whiteboard coding are among the worst still actively used (now that brainteasers are mostly dead). I think what we have is the least-bad, but we're still iterating on it (and hopefully always will be).
raygull 11y ago
I've been interviewing recently and it does suck just as described here, so I'm glad somebody called out these issues. One company I talked to was like a caricature of the bad startup interview: we have a billionaire founder, we have wine on tap, a totally disorganized 4-hour series of discussions where the first person just sat down and started quizzing me with hardly an introduction, and I had to ask the second interviewer how many people I'd be talking to, technical questions ranging from the simple to somewhat difficult (using paper and pencil), with less and less time for each because they couldn't follow their own schedule, followed by an interview with an arrogant, hypercaffeinated CTO, consisting of two brain teaser questions and a series of elevator pitches, all in a tiny glass room near the back storage area, devoid of oxygen. And the following week I found out, sorry, they'd cut funding for the position the day before I came in.
tpiha 11y ago
There might be a solid startup opportunity here. I completely agree with the author, from both employee and employer point of view.
Overtonwindow 11y ago
Perhaps I missed it, but I didn't see anything mentioning certification. With that be an alternative? If you're hiring someone to code in Java, is there not a certification they can get?
JB8130 11y ago
I didn't read the entire article, I stopped after a couple of paragraphs. The problem as I see it is companies are trying to hire coders when they really want Software Engineers. Or maybe I should say they are trying to buy a Software engineer but only willing to pay the coder rate. A good Software engineer can design a program or system and not even have to know the programming language, they understand software and how it should work. I have on many occasions told our SQL coders/programmers where problems are and how to fix them without ever having programmed in SQL. The key is the Software Engineer understands the fundamentals of the system as an engineer and understand how everything goes together and should work. For example, if you are designing a business system, you engineers understand how the business works and how the program can help it. The coders know how to implement the design but not the why's. If you are hiring outside vendors then it is even worse. They are coders that know nothing about your business or your project or what you are trying to do but they do know how to code something, let you try it, have you change it and try it again and change it again and try it again an...you get the picture. If you hire a software engineer that understands software and learns your business, they can develop design documents that can then direct your vendor. This creates a better product the first time and at a lower cost. The schools today are creating more and more programmers and fewer Software Engineers.

112 points by ubernostrum 11y ago

> even if we don’t have a sense of ethics we do have a problem of numbers, and more desks and seats and spots than people to fill them I get this a lot, but it is amazingly self-inflicted. Almost all of the random job offers i seem to be getting from people i don't know are from clients who: - underpay - demand on-site only - don't even look at the copious provided code samples, only at the CV The reason for that is simple: A lot of companies view developers as identical to factory workers. There is nothing more to it. -- Sadly i think this is not something that writing blog posts about can possibly help. The people making these mistakes when looking for developers make them because they are ignorant and do not care enough to gather the required knowledge. Until they realize their "illiteracy" and wish to fix it themselves, the scale of this education problem makes it unassailable.

ubernostrum 11y ago
I left out some of my frustrations simply because there wasn't room for everything and the piece was already getting long. I've also run into the "OK, you got through all the interviews, here's an offer for a contracting slot rather than employment". I've run into impossibly-broad non-compete agreements that I simply can't sign without risking my livelihood if the position doesn't work out. I've run into interviewers who didn't know basic things about the tech they were interviewing me on. I've also gotten a few speculative recruiters who are just obviously going off a list of auto-slurped email addresses from GitHub and not taking the time to match up positions to skills (including one person who very persistently wanted me to look into a job writing C++ all day). And on the flip side I've applied speculatively to a few smaller shops that looked like they were doing interesting stuff, only to get the "we think you're overqualified and can't afford you" reply.
xacaxulu 11y ago
>> demand onsite only!! The companies making the most demands usually offer the least. My favorite new flavor is recruiters saying "well for remote the pay rate is lower" to which I answer, "will I be doing less work in that case?".
- MCRed 11y ago
  Interesting... as I have taken to giving the random LinkedIn recruiters two rates-- one an on site rate and one a remote rate. The remote rate is my normal rate, which is lower than the on-site rate which has a healthy have-to-go-into-an-office premium. When you couple that with the higher productivity of remote work, the smart employer will let me work remotely (at least most of the time.)
  - Mithaldu 11y ago
    Same here, i quote them my current rate for remote work, and for on-site work they get a markup.

blizkreeg 11y ago

> Even among the most common demographics for developers (American, male, white, skewing young and middle-class background), we are absolutely abysmal at this.. How does nationality, gender, race, age, and income level have _anything_ to do with this at all?

ubernostrum 11y ago
People tend, consciously or not, to recruit most heavily from among people like themselves (for lots of reasons which aren't necessarily bad: a lot of referrals are based on knowing someone, for example, and a lot of peoples' social circles/contacts tend to be pretty homogeneous to begin with). In other words, even on the easiest default approach (recruiting from people similar to ourselves), we suck. God help us as we try to recruit from people dissimilar to ourselves.
- blizkreeg 11y ago
  IMHO you are subconsciously profiling if that is what you're doing in your hiring i.e., making assumptions about people's skills/talent based on any of those attributes.
  - URSpider94 11y ago
    That's exactly what you are doing, and there is copious data out there to say that we all do it. The generally accepted term is "unconscious bias." I saw a summary of a study recently in which people were asked to rate top character indicators of success for male and female candidates for a job, things like "aggressive," "nurturing," "outspoken," "mediator." Not surprisingly, the adjective sets for male and female candidates were substantially different.
  - URSpider94 11y ago
    Cite here: http://www.catalyst.org/system/files/Women_Take_Care_Men_Take_Charge_Stereotyping_of_U.S._Business_Leaders_Exposed.pdf http://www.catalyst.org/system/files/Women_Take_Care_Men_Tak...
11y ago

DrJokepu 11y ago

I disagree with this. Coding interviews are great. The interviewer needs to realise though that they're not there to be an adversary or a judge, but to help the candidate demonstrate their skills, to help the candidate get the job.

toolz 11y ago
I feel like all you're saying is 'Coding interviews could be great' not 'coding interviews are great'.
NhanH 11y ago
Coding interviews are great if the interviewers are perfectly rational and omnipotent agents. They need to be able to perceive the job, derives the set of abilities that is necessary for it taking into account and predicting future changes. Asking the set of questions that will subsequently narrow down the candidate's ability (while understand the answer, obviously). All the while gauging candidate's "social skill" and "team work" ability, among with any and all trending required characteristics there are. Oh, and you got an hour to do that. You have 5 interviewers going through the same candidate? Fine, they need to be one-fifth omnipotent. Good luck with that.
fooster 11y ago
Depends what you mean. If you mean google style whiteboarding coding interviews are great I'm here to tell you they are not. I've never been payed to write code on a whiteboard, have you?
1stranger 11y ago
That's the theory but it doesn't work in practice. Interviewing other developers is a skill and it's a skill that most developers don't have.

jvanderbot 11y ago

I would offer that the subtle point missed in coding interviews is the ability of the interviewer to judge the flexibility, poise, and social skills of the interviewee. That seemed very important during my interviews. This may be why the best advice is to "talk it out" Any yay-or-nay judgements based on hastily-written program output should be taken with a grain of salt by both parties.

dustywusty 11y ago

As both an interviewer and interviewee at Weebly, I'm pretty confident in saying I prefer our approach of the trial week. It really gives a great opportunity for the candidate to show off their skills without the on-the-spot pressure of a coding interview. A great side-effect is the candidate gets to determine if they like the team, and vice versa. I honestly wouldn't work somewhere else where I couldn't come in for at least a few days to meet and work with the team.

nickonline 11y ago
This is pretty rough on any interviewee who already has a job as they'd have to take holiday days to interview. Do you give them a week off in lieu if they get the job?
- msandford 11y ago
  What happens if they don't get the job, and they burned 1/3 of their year's vacation?
tomtang0514 11y ago
But how do you handle the case that candidates already have a job somewhere else? They can't take a whole week off for this.
- dustywusty 11y ago
  I took a week off at my previous job to trial at Weebly. My previous job had a very strict vacation policy, but I knew the importance of what I was doing. Weebly has an unlimited vacation policy, so, it worked out pretty well.
  - duderific 11y ago
    What a disaster though, if you didn't get the job. 1) Lose a week of PTO, and 2) Feel really bad that the people you spent a week with didn't think you were good enough. Also, from the Weebly end of things, what if you know a couple days in that the candidate isn't going to work out? Cut them off right then or finish out the week?

teen 11y ago

this article is awful. it cites a single bad coding interview as a problem with all coding interviews. as someone who gives tons of code interviews, they are absolutely invaluable, and are a strong indicator in weeding out people who can't write code. you can't blame bad interviewers for the entire process not working.

ubernostrum 11y ago
I have, in the recent past, done multiple coding interviews. Thus far none of them have been useful to me, and none of them have provided information the interviewers couldn't have gotten already from my GitHub contributions. The single personal anecdote was meant to reinforce my points: from that interviewer's perspective there's a good chance that I'll be one of those "people who can't write code" who forms the basis of later stories about how great it is to use coding interviews as a filter. Meanwhile, I do go into some detail about the issues with coding interviews in general, and the way they can affect and accidentally weed out candidates a company probably didn't want to weed out that way. Also, the "nobody can really code, you have to do this to filter them" thing is approaching cargo-cult status at this point. Further up in the section on education I touched on some reasons why I think those situations happen.
gqvijay 11y ago
Slippery slope fallacy...You are incredibly oversimplifying what he is saying. Sure, he is generalizing but he isn't citing a single coding interview to judge the entire process. Having said that, I actually agree with him because I've learned that it's not always simple as who can't write code. I would much rather assess a candidates' ability to learn (sharpness) than the current skill-set.
- fieryeagle 11y ago
  Second this, but Joel Spolsky said it much better http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html http://www.joelonsoftware.com/articles/ThePerilsofJavaSchool...

msoad 11y ago

I'm working on open source stuff for two years now. Everything I do is public for everyone to see. Including my responses to bug reports and design documents. Yet I get the same algo/ds puzzle questions that you should've solved before in order to solve it in an interview setup. Google reached to me and said based on my profile I can skip the phone interview but I'm so afraid of the interview that I postponed it multiple times. I'm fine with algorithm questions only if I'm solving it in the same setup as my actual work where I have access to internet and can write some quick programs to test my ideas. I was good at solving pretty much any problem I had in my actual work. Even if I had to read a paper on the topic or learn about a new concept from ground up. Google asks questions like pots of gold[1] where it's really impossible to solve it on a whiteboard if it's your first time seeing the problem. I'm on hiring side of equation also. I get it, it's really hard to judge people. Even when the candidate have a GitHub page. I got a candidate from Hack Reactor where he had tons of contributions. But when I looked closely at those contributions they were mostly fake. Some other candidate had exactly same codebase in their GitHub. [1]: http://careercup.com/question?id=15422849 http://careercup.com/question?id=15422849

qmalxp 11y ago
It's not impossible to solve those types of problems if you prepare ahead of time. I think that problem just requires dynamic programming/memoization, which is one of the things you're told to study beforehand.
skimpycompiler 11y ago
These problems aren't that hard, although they do not say anything about the person that solves them. One can prepare for a Google interview in 1-3 months and I'm sure there's a pretty high chance they would pass it. I've seen tens if not more people from my unknown middle EU university nail the interviews, ending up with jobs at Google, Facebook, Microsoft etc. and I've cooperated with some of them, knowing that their programming skills and knowledge, teamwork are lacking. But they can solve some simple dynamic programming problems, or maybe a silly breadth-first-search, and they'll get the job. I, personally, wouldn't like to be hired at a firm that evaluates me that ridiculously. Yes, I'm a fresh graduate but thinking that knowing Dijkstra's algorithm evaluates my abilities makes me believe the whole culture is entirely deformed and I do not want to be fascinated by these ridiculous puzzles when I'm working with others. Give them a week to implement something of larger complexity and they are drowned by so many concepts they decided to skip to earn an internship/full-time position at their beloved giants. But I guess giants can afford having engineers that aren't that productive, or aren't doing projects that matter. I wouldn't like to be one of these engineers. So, the real question is do you want that, or is the cash blinding you? :D Books like these below can increase your chances significantly: http://www.amazon.com/Elements-Programming-Interviews-Insiders-Guide/dp/1479274836/ref=sr_1_1?s=books&ie=UTF8&qid=1445301895&sr=1-1&keywords=Elements+of+Programming+Interviews http://www.amazon.com/Elements-Programming-Interviews-Inside... http://www.amazon.com/Competitive-Programming-3rd-Steven-Halim/dp/B00FG8MNN8/ref=sr_1_1?ie=UTF8&qid=1445301997&sr=8-1&keywords=competitive+programming http://www.amazon.com/Competitive-Programming-3rd-Steven-Hal... http://www.amazon.com/Cracking-Coding-Interview-6th-Edition/dp/0984782850/ref=pd_sim_14_2?ie=UTF8&refRID=1B0CS1XQC5YD255KDVY1&dpID=51lcgdiQAlL&dpSrc=sims&preST=_AC_UL160_SR112%2C160_ http://www.amazon.com/Cracking-Coding-Interview-6th-Edition/...

deleted 11y ago

[deleted]

flippyhead 11y ago

It's funny, I've tried tons of different approaches to solving this problem and the only thing I now do is spend about 30 minutes with someone then decide to hire or not (usually I'm able to express this on the spot to whomever I'm interviewing). For better or worse, my instincts about who is smart, honest and kind seem at least as good (and often better) than any other approach we've tried.

fishtoaster 11y ago
I'm curious how you validate that approach. I'm not saying you're wrong– just that I don't know if you'd be able to tell if you're wrong. Do you measure the performance of people hired through that method, and have you done so for a long period with a significant sample size? Do you manage to measure your false-negative rate (by somehow following up on candidates you passed on)?
- flippyhead 11y ago
  Well, the false-negative rate is something we never did even when we tried all kinds of other "standard" interview approaches. If you had a solution for that it'd be useful generally I expect. I'm only make anecdotal comparisons to the quality of persons hired by all other approaches vs. me just using the massive pattern matcher in my head. And to be sure, my company is small and it's my company so the ultimate determinant of hiring quality is really just me. I'm not sure this approach would work for medium+ organizations.
Gibbon1 11y ago
Your comment made me think these extreme interviewers are like a gardener who want to find that one true seed that will thrive when they plant it in a flower pot full of broken glass and gravel. Also reminds me of a comment by Robert Townsend. Which is a warning about following the practices of the biggest most illustrious firms. In his day that was General Motors etc. Today it's Apply and Google. I think those guys can spend a buttload of time and money looking for the perfect fit out of the line out the door of candidates because, it matters. Bad/Good hire could cost or make the company millions of dollars. It's also hard fire when your company is large. Your dinky company? A misperfect fit is going to cost you thousands to tens of dollars.

gfodor 11y ago

"People who have a master’s degree in CS but seemingly can’t code their way out of a paper bag probably actually aren’t bad; more likely they had an education which de-emphasized practical hands-on programming in favor of heavy theory. People who post “please give me the code” questions on mailing lists and forums probably actually aren’t bad; more likely they had an education which was based around memorizing and regurgitating stock answers to stock questions." What does this even mean? When someone lacks a certain skill, they aren't "bad" in some objective sense, they are misqualified for the job. If someone can't code their way out of a paper bag, should we be hiring them anyway for a programming position because they're not "bad"? What's the point of the interview in the first place? I don't understand the argument. To the other points, I completely agree there are many ways to screw up interviews and few ways to get them right. I'm still a believer that an interviewer who administers a coding question, one that is reasonably realistic, in both form and the environment the candidate has (ie they have their own laptop) can be a good way to assess someone's skills if you are doing it right. You let them work, let it be a humane environment, and don't get too hung up on the details. Usually if someone can hack it bleeds through pretty clearly, even if they don't get to the exact solution you wanted. (And of course, this is just one data point, that should be distilled into a larger picture of the person's history, accomplishments, etc.)

supercanuck 11y ago
I'm just kind of flabbergasted that someone with 6 years of matriculation from Computer Science Program has resulted in the equivalent of a truck driver spending four weeks on Code Academy. It just doesn't jive... >I have a philosophy degree, by the way. Not to be smug about it, but several very good people I know and respect in the software field came to it from that background. Ahh... now it makes sense...
- mrep 11y ago
  I believe he is referring to people who got there bachelors in a different major, and then got their masters in CS.
ubernostrum 11y ago

dx211 11y ago

A couple of years back, I was hiring some vendor developers for my team, and since I had some flexibility in the interviews that wouldn't be allowed for full-time employees, I tried an experiment: For one of the vendor candidates, I told him a day ahead of time that I'd be asking him to implement System.Collections.Hashtable in C#, with behavior equivalent to the one in .Net. The day of the interview came, and he whiteboarded it flawlessly, to a degree that I'd never seen any other candidate accomplish, and he was able to have a deep conversation about the implementation and all of its nuances. He then proceeded to bomb the rest of his interviews and didn't get the position. What this illustrates to me is that the typical programmer interview, where we come up with some weird problem and toss it to the candidate while they have no references to look at, no IDE to type into, and a 45 minute deadline looming over their head, is totally divorced from the actual work we actually really want them to do. If I need someone to implement a widget, I'd rather they took some time to research it and do it right, versus trying to crap out a solution in five minutes on a whiteboard.

davnicwil 11y ago
Brilliantly put. When I'm giving interviews I really like it when a candidate posed with a fairly complicated problem or design question pauses and actually thinks, then says something like "..well, I don't really know, I'd probably want to think about it more, but here's an idea" before putting forward their likely non-optimal but totally plausible and on-the-right-track design or solution that they thought of on the spot. Under-confidence in an answer (straight up asking for validation i.e. is this right?) or over-confidence (expecting to shoot straight from the hip with the perfect, 'right' solution, or just a plain old bullshitter implicitly insisting that anything they say is correct) are usually red flags for an extreme personality type - always exceptions to this but as a general rule, I've found it to be true - and the happy middle ground, coupled with answers that obviously point towards a depth of knowledge and skill, is what you're looking for. Trying to follow my own advice, I've done this myself as well when I'm the interviewee. Side benefit - if the interviewer actually is looking for a 'right answer' to complex questions out of the blue and on the spot - good for them if that's what they want but I'd want to self-select myself out of that type of expectation and working relationship. So everybody wins.

aurelianito 11y ago

When an actor goes to an interview (aka: casting) twice, he gets paid. I think we need this in this industry. A lengthy interview should be remunerated.

kyllo 11y ago
That's because actors have a union.
- aurelianito 11y ago
  We need a union then.

aggieben 11y ago

> a belief that memorizing a bunch of that stuff and being an automaton who spits back the correct algorithm name and a pseudocode implementation is all there is to programming. Because what companies really want is to hire a Fisher-Price See-‘n-Say toy, right? I get the overall rant. I understand the frustrations - but this is wrong-headed. If you can't see the value of understanding algorithms - learning both how to write them and how to evaluate them (including proving their correctness), then you've misunderstood computer science education altogether. Nevermind all the rest of CS, which encompasses far more than just "names of algorithms".

ubernostrum 11y ago
It's more that there's a lot of cargo-culting and "Google did this, so it must be good" flying around, and a lot of really bad CS programs which revolve more around the Feynman-rant memorize-and-regurgitate style than actually understanding performance characteristics. Which in turn produces interview processes that really are of the See-'n-Say variety. Though to be honest, for a lot of what I do my working set in memory (metaphorically) involves very very little algorithms/data-structures stuff and a lot more quirks of libraries/frameworks/protocols stuff. When I need the algorithms and data structures, I pick up the reference I keep on my desk and look up the thing I'm thinking about to double-check that I'm using the right approach.
- aggieben 11y ago
  Fair enough, but then you should explain that what you're against is mindless regurgitation, not good CS education (which again, has algorithms at its core, but goes far beyond that).
  - ubernostrum 11y ago
    I think that what you seem to be treating as "good CS education" is something I'd be more likely to call "good math education, but probably not great training for programming". A big part of the problem is over-generalization. Here's a reddit comment I posted in a similar discussion not too long ago, touching on that: https://www.reddit.com/r/Python/comments/3nfbkr/patreon_is_a_flask_app_and_was_hacked_because/cvobo03 https://www.reddit.com/r/Python/comments/3nfbkr/patreon_is_a... The person I was replying to there had made the mistake of assuming that because in these fields of programming, knowledge of data structures, algorithms and big-O characteristics is one of the most important things for performance, that must be true of all fields. When, in fact, it's not true of all fields, and I provided an example of one where it isn't true and where quizzing someone on their big-O cheat sheet wouldn't actually reveal whether the candidate has the most relevant knowledge for what's going on.

NullCharacter 11y ago

As someone in the computer science/cyber security field who didn't go to college, I tend to agree with this article in a few ways. Having no college degree has really hindered me in terms of landing interviews, but once I'm given a chance on the job I'm always flourished and proved my worth. I've also found it strange that it didn't matter what my degree was in, just having one wold have secured me interviews. A theoretical degree in Turfgrass Science would have benefited equally as a proper degree in CompSci.

dkarapetyan 11y ago

Try triplebyte. Their process is actually pretty good.

fishtoaster 11y ago

I'm of the opinion that pretty much every interview technique has at least some tradeoffs. Too many false positives, too many false negatives, selecting for or against certain groups, etc. At my current company, we don't do any phone-coding or whiteboard-coding, for which I am very thankful (for the reasons the article laid out). We do do a take-home dev test (4-6 hours). This has the benefits of being low-pressure, repeatable, and similar to the real work we do. It has the tradeoff that we might miss out of great devs who don't have the time to do it. We're working on shortening it to offset that. We also do a bit of paired programming on-site (using the candidates computer and dev environment of choice). This has a distinct tradeoff, since it can be a bit high-pressure. We try to do everything we can to ease candidates, but I haven't found anything else that works well for getting a feel for what it's like to work with someone in a technical capacity. Every interviewing technique has issues, and I think phone and whiteboard coding are among the worst still actively used (now that brainteasers are mostly dead). I think what we have is the least-bad, but we're still iterating on it (and hopefully always will be).

raygull 11y ago

I've been interviewing recently and it does suck just as described here, so I'm glad somebody called out these issues. One company I talked to was like a caricature of the bad startup interview: we have a billionaire founder, we have wine on tap, a totally disorganized 4-hour series of discussions where the first person just sat down and started quizzing me with hardly an introduction, and I had to ask the second interviewer how many people I'd be talking to, technical questions ranging from the simple to somewhat difficult (using paper and pencil), with less and less time for each because they couldn't follow their own schedule, followed by an interview with an arrogant, hypercaffeinated CTO, consisting of two brain teaser questions and a series of elevator pitches, all in a tiny glass room near the back storage area, devoid of oxygen. And the following week I found out, sorry, they'd cut funding for the position the day before I came in.

tpiha 11y ago

There might be a solid startup opportunity here. I completely agree with the author, from both employee and employer point of view.

Overtonwindow 11y ago

Perhaps I missed it, but I didn't see anything mentioning certification. With that be an alternative? If you're hiring someone to code in Java, is there not a certification they can get?

JB8130 11y ago

I didn't read the entire article, I stopped after a couple of paragraphs. The problem as I see it is companies are trying to hire coders when they really want Software Engineers. Or maybe I should say they are trying to buy a Software engineer but only willing to pay the coder rate. A good Software engineer can design a program or system and not even have to know the programming language, they understand software and how it should work. I have on many occasions told our SQL coders/programmers where problems are and how to fix them without ever having programmed in SQL. The key is the Software Engineer understands the fundamentals of the system as an engineer and understand how everything goes together and should work. For example, if you are designing a business system, you engineers understand how the business works and how the program can help it. The coders know how to implement the design but not the why's. If you are hiring outside vendors then it is even worse. They are coders that know nothing about your business or your project or what you are trying to do but they do know how to code something, let you try it, have you change it and try it again and change it again and try it again an...you get the picture. If you hire a software engineer that understands software and learns your business, they can develop design documents that can then direct your vendor. This creates a better product the first time and at a lower cost. The schools today are creating more and more programmers and fewer Software Engineers.