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.
I recently interviewed with a company that had advertised (in my paraphrase) "we've noticed that a lot of perfectly good developers do poorly in interviews for reasons that appear to be unrelated to job performance. So you can now interview with us by completing a project on your own time, and during the interview we'll talk about that".
My project was a regex matcher. I ended up getting the following feedback:
> We thought you wrote a great, very full featured regular expression matcher. It was especially impressive how much you dug into the academics behind regular languages.
> However we made the decision because we felt that while going through the project together during the interview, we didn't see the fluency of programming when adding to it that we had hoped for. While we specifically designed the take home project track to help overcome the difficulties of coding under time pressure with someone watching, we do still need to see a certain level of programming during the interview. This didn't seem to be the case here.
Disagree (on the second part). Rather than giving you the equivalent of a walk-up pop quiz on a random topic, they are giving you followup questions and discussions on code that the candidate wrote recently.
That seems quite a bit more representative of regular work than a pop quiz. Yes, you still need to be able to talk live about code with other developers. That's unchanged and shouldn't change, IMO.
Look like either bad communications or some sort of discrimination about your in person appearance, or they filled the open headcount with someone they liked better.
Wow, what the f_ck kind of person do they want? You showed when you can code, build a complex application that actually does something valuable. You know, understand, and can use deeper level stuff.
I get that they and every other business wants to find a team of wunderkinds that can plug right into their repo and get to work. That's the ideal.
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.
I recently interviewed at Facebook and they seem to want the shoot from the hip type person who is extremely confident (borderline arrogant) about their answers. Theh drill and drill amd expect rapid fire responses.
And if they do follow too many standards, it's a red flag. Or if they follow a mix of standards and non-standards. Big red flag there. If the person is wearing nice shoes, definitely a red flag. But you don't want them to be too normal, because that could be a red flag also.
This hypersensitivity goes in both directions. One company may be worse than another at hiring, despite having an equal or better engineering department. Sometimes, you might just get bad luck. Your interviewer might not have had their coffee that day. Or their dog may have just died. Or you may get a guy who just proposed to his now-wife and is having the best day of his life. Giving a reasonable benefit-of-doubt mixed with a bit of critical thinking is probably the way to go, rather than resorting to hard and fast rules that will end up just making you conclude no company is good enough for you.
> One company may be worse than another at hiring, despite having an equal or better engineering department.
I don't understand this. As far as I can see, the entire goal of hiring is to have good workers, so the company with a better engineering department is better, by definition, at hiring engineers.
It might be that their hiring prowess comes in part (or in whole) from factors largely outside the hiring process specifically, something like "you get to work for Elon Musk", but their hiring is still better.
Or they could hire a lot of people and quickly fire poor performers. I would class that as "bad at hiring," even though they manage to build a good team with the process.
Sure, but as the linked article emphasizes, these are humans you're talking about. I would never intentionally create a hiring process where we accept a large false-positive rate (I think you meant false positive? As in, we thought he was good, but he wasn't) with the expectation that we'll just fire the poor performers. It's inhumane.
No, I meant the false negative rate. Imagine you have a hiring process. It marks some applicants as "should hire" and some as "shouldn't hire". False negatives are marked "shouldn't hire" when really you should have hired them.
The only way to determine your false negative rate is to hire a bunch of "shouldn't hire"s and see how they work out.
Easy hire, easy fire is inhumane to people who believe that once you get one job somewhere your problems are over. Never-hire-because-we-never-want-to-fire is inhumane to people who interview poorly and do good work -- they're humans too. You can't win them all.
Just had an interview this morning. To almost all of the "how would you go about this" type questions, my answer was well, it depends on the data type / volume / customer needs.
Your response - totally. Similar experience: I was asked in a technical interview to use the "correct" collection class given the (very academic) sorting problem. I responded with "there is no right answer, so my answer will be the simplest one". According to them that was wrong. The "right" answer was the best performing scenario (although more complex of a solution).
That's exactly why it pays to prepare for coding interviews. If companies are not going to be thoughtful about interviewing, candidates can either reject those companies, or prepare for those interviews. My belief is that if more candidates are professionally prepared with those closed-ended questions, this will eventually force companies to be more thoughtful.
When you have 15 years of general experience covering servers, databases, programming languages and other tools, its difficult to choose something to brush up on.
Agreed, but what is my option? I can't expect companies to just talk about what I've done, take it at face value and hand me a lucrative job. Not to mention that things change in tech so often.
> 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.
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.
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?".
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.)
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.
* 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. *
Ok, so here is an anecdotal sample. I have not seen this problem before.
After reading the problem description I tried one round of the game on the paper (actually in the text editor) to get the feeling of the game play and then it took me about few minutes to come up with one possible solution and then after a little bit of thinking with a more optimal one.
So not impossible (but I was in comfort of my home).
I actually think that this is a rather classical CS problem that does not require some thinking about more abstract mathematical corner cases.
I give an example of the later one.
You have an array or numbers [1 - n], that is not sorted. One of the numbers got changed to 0. Given an array after the change return the changed number in linear time.
Assume the some array but two of the numbers got changed to 0. Given an array after the change return the changed numbers in linear time.
Some information is actually missing/not obvious and interviewers may actually evaluate your reaction to this situation because this would also model (to some degree) a real life situation.
So I added the missing bits (and fixed typos).
You have an array size of n of integers from 1 to n, that is not sorted. There are no duplicate numbers in this array.
One of the numbers got changed to 0. Given the array after the change return the changed number in linear time and constant space.
Assume the same array but two of the numbers got changed to 0. Given an array after the change return the changed numbers in linear time and constant space.
The first part of this problem should be simple. The second part is more tricky.
FWIW I've had this same question in an interview years ago in Australia. Don't recall seeing the second part (which is more interesting, mathematically), but it just goes to show how many questions end up re-used by different companies as their employees travel.
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:
The best predictor of how someone will perform in a job is a work sample test (29 percent). This entails giving candidates a sample piece of work, similar to that which they would do in the job, and assessing their performance at it. Even this can’t predict performance perfectly > http://www.wired.com/2015/04/hire-like-google/
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.
"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.)
For much the same reason that someone who has no CS background can productively do a short coding bootcamp and be employable, someone who has a theory-heavy and practice-light CS background can almost certainly pick up practical skills quickly. It's more of an educated vs. educable thing, and anyone who's demonstrated that they're educable is probably worth at least looking into a bit more even if they don't come with the full practical skillset already.
(and I say this, ironically, as a lifelong opponent of theory-heavy CS programs which churn out people who can derive an answer to your question straight from the Church-Turing thesis but couldn't code it up to save their lives)
> For much the same reason that someone who has no CS background can productively do a short coding bootcamp and be employable, someone who has a theory-heavy and practice-light CS background can almost certainly pick up practical skills quickly.
I don't think they're equivalent at all.
The truck driver simply never had the opportunity or exposure to programming. He didn't know what it was like and hence couldn't do it.
The theory student did have exposure but was either incapable or uninterested in pursuing it. Even in the most theory-heavy of programs, you program a little. The kids who actually understand and like the programming aspect latch onto it and continue to learn and grow, ending up employable. The kids who, having been exposed to programming and realized that it's not for them, never learn any more and continue to flail around in masters programs teaching mathematics in the guise of CS.
Some people just can't learn the programming part.
I studied (and helped with labs a few times) two of these. Mathematics and theory was fine, but the rest not. Weird, I wouldn't have believed it was possible after years of university, if I hadn't seen it.
One became a teacher, I don't know about the other. He might have become a quite good entrepreneur. Seriously.
The point is, it is possible one of these are the next person with a theory heavy background you interview... (But ok, we all know that too well even with little experience of hiring. :-( )
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.
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.
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).
> 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".
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.
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).
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:
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.
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.
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.
Instead of repetitively saying that you went through this same gauntlet yourself, how about an argument for how you think this is possibly a valid strategy for attracting good already-employed developers?
As I see it, there are 2 huge barriers to me ever doing a trial week while currently employed:
1. If it doesn't work out, I've just burned 1/4 of my vacation time for the year. That's a pretty massive ask for a company to make. I could do a bunch of math with expected values, but I'm sure it would work out to Weebly having to have insanely great compensation (>$300k) for me to do it.
2. Even if it does work out with Weebly, it makes it impossible for me to concurrently solicit and evaluate multiple offers, which I absolutely do when looking for a new position.
How do you overcome those problems which make it very unlikely that 99% of employed developers will do your process?
Of course, it could also be that this is a brilliantly designed strategy for weeding out expensive employees by focusing on the unemployed and unsavvy.
> Of course, it could also be that this is a brilliantly designed strategy for weeding out expensive employees by focusing on the unemployed and unsavvy.
This is the result, intended or not.
The problem is, the good people usually don't need a job. So the more of a gauntlet you make your hiring process, the less likely it is you'll get one of those already-employed, perfectly happen and great employees. You're selecting the people who couldn't get jobs at your competitors (modulo the false-negative rejects).
I did something similar with another company wherei did remote part time work for 2 months to see if they would like me and vice versa.
Didn't end up working out so I was glad it was only part time and I didn't make the jump. If I made the jump directly, I likely wouod have been laid off and unemployed.
<em>I'm pretty confident in saying I prefer our approach of the trial week.</em>
A full week is pretty close to insane. It means that application is effectively limited to the currently unemployed (or those who are willing to burn what might be all the vacation they can take for months).
That said, it does make pretty clear that Weebly doesn't give a single shit about employee's lives; so it's kind of Weebly to make clear, right out of the gate that they expect to be the only thing that matters in your life.
As a pretty happily employed Weebly for a few years now, I'm frustrated that you think that, but I'm glad that you went out of your way to register an account to reveal your thoughts. In this case, I guess we'll just agree to disagree.
How would you handle the currently-employed with a such a setup? Having to either give notice or use up a week's worth of vacation days just for an extended interview at a single company sounds like a real horror show from the interviewee end.
Contract-to-hire at least gives you a couple months of fairly sure income.
I was employed when I did my trial week at Weebly, and I had to use a week's vacation to do it. Weebly paid for my time, not to mention the trip to SF. Obviously it was worth it to me, but I can see where you're coming from.
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.
You've mentioned this twice. Yet, it means nothing for vast majority of people in the workplace. The majority have to be at work programming instead of interviewing for programming positions. They neither have unlimited vacation time nor a 100% guarantee using a vacation for some interviews will go anywhere. If anything, the OP's post shows quite the opposite for them in common case.
So, how does a trial week work for candidates committed to another job? If anything, it seems to self-select for part-time or remote workers that are already in a position with time on their hands. The best I know don't fit into that category: you'd miss them.
EVERY job switch has inherent risks. It's unreasonable to expect otherwise. No one can help that and OPs situation wasn't crazy. He/She took a risk and it paid off. The downside is just a lost week of PTO? Not too crazy and anyone with a full-time job and some PTO could do this. I'd even get 'really sick' if I had too.
It's true that every job has risks. Where do you see me (or OP) say otherwise? The question is should every candidate give up a whole week of his or her time knowing it will get most people nowhere. That method's benefit is almost entirely rigged for the hiring party with huge potential for waste for other party in any environment with multiple, decent candidates. A few anecdotes that worked out don't change that.
So, the question is: "Should employers put this kind of burden on every candidate or try a method which demonstrates skill with less time?" I push for the latter.
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?
How many interviews can you afford to have like this?
Likely, the decision was already made by you being willing to risk the week of vacation and put in the effort to get hired, while they showed a similar regard.
You might be able to get away with 1 or 2 of these things a year... but it's a REALLY good way to burn bridges.
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.
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.
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)?
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.
> 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?
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.
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.
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.
Most examination / testing procedures rely more or less overtly on various cultural assumptions to obtain comparable and acceptably accurate results. In the western world these assumptions are generally those shared by white, somewhat affluent people (I recall reading an interesting explanation from David Foster Wallace to his students on the necessity of being able to use "correct" - i.e. not ethnic dialects - English).
He's emphasizing how determining whether a candidate is good or not is hideously inaccurate and frustrating for everyone involved... Even without barriers of language, ethnicity, culture, age, or discrimination-of-same.
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.
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.
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.
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.
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?
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.
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?
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.
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.
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.
