Personal bias also potentially factors into how you describe it (so consider presenting it written, in the same format for everyone). E.g. let's say the interviewer goes into extra detail or ask for confirmation of understanding from candidates they favour.
Generally if you are hiring on work product skills (coding for software folks) and can show that your test is unbiased and you hire to the test, then you can avoid being found guilty of discrimination even if you hire a disproportionate number of a certain group. To be rock solid you also need to show that your applicant pool is highly diversified and has representation from all groups. Sometimes that means going out and seeking out candidates (like women or hispanics) who are self selecting to not apply. And why you really do better if you blind the resumes your HR staff sees before they sort them into phone screen and skip piles.
This is a great point and it's why I always include FizzBuzz in any interview—no matter how they were referred, how impressive their resume is, or their confidence level.
Having consistent benchmarks helps give you legal cover, but it's also essential to running a solid interview process. If you're not applying the same tests to all candidates, it's impossible to detect problems in your filters and you can easily end up making biased decisions or hiring the wrong people.
Yes, I understand that it can be annoying to have to solve such a basic problem in an interview, but it only takes a few minutes—just get it over with, it's not meant as an insult.
Passed through all the on-site interview problems and then they silently dropped me. No "we're sorry, you're not a good match." No emails, no phone calls. Nothing.
How in the world are people making it through schools (with a MS!) without actually.... uhh.... you know.... knowing the subject at all?
I'm sure that there are many more people who could complete FizzBuzz on a homework assignment, with the help of the Googles, than could do so in an interview. And there are many mid-tier MS programs that are happy to take money from international candidates and give them every opportunity to keep paying.
Absolutely. They may even have washed out at higher numbers. The applicant pool described in the complaint definitely isn't representative of US CS majors nationwide, so you can't use it to draw inferences about the quality of students overall.
Recent undergraduate grad here. A lot of the algorithms I've seen on technical interviews were only covered once or twice in the curriculum. Basically, one such algorithm would come up in either the data structures or algorithms class, we would then work on it for the given assignment/exam, and finally we would move on from it. Subsequent course work would barely reference it.
These things are best learned through repetition. Unfortunately, with all of the other CS coursework topics that I was being educated on, it seemed like there was little room for the repetition to take place. (At least, not in the stereotypical four year timespan assuming that the given student enters a CS program with no prior programming knowledge.)
This is bizarre to me. It's like someone signing up for a music degree having never played an instrument. Maybe you'll cram enough to pass a test on the theory, but it's useless knowledge. It's unanchored and will float away.
Engineering students are expected to have a strong maths background. If you can't do algebra and basic calculus then there's no chance of getting in.
It's completely reasonable to expect a CS student to have experience programming.
If you say so. I neither see the reason nor the advantage. Don't get me wrong: I had experience in programming before entering a CS program, but I had fellow students who never did any programming before and they did just fine, while others with programming experience failed. And I'm pretty confident that all of them who managed to stay through the introductory year were/are able to do FizzBuzz.
When I studied CS, data structures and algorithms was the second CS course we were expected to take, right after "introduction to programming". It would usually be taken in the second semester.
That's the last time we were tested on a long range of algorithms, except indirectly if we happened to need a given algorithm to complete our work later. In the 22 years since, I've probably needed e.g. a depth first search once, and many of the algorithms I learned I've never touched on since.
So for many, it boils down to whether or not you cared about and liked that course. I happened to love it - I read the set texts the first weekend of the course, and spent a lot of time reading up on algorithms in the years before and after. But for a lot of my class mates it was a course they had to endure to get to more interesting stuff. Many of them would go on to do very well in other subjects.
If they can't figure out a problem like FizzBuzz given a complete description, then that's a deeper problem. But a lot of algorithm questions can sound like they are on that level because we expect people to know a catalogue of algorithms that most developers don't actually need through most of their careers.
same here - almost 20 years of dev, last time I needed to implement basic cs algorithms were in college and grad school classes (and some idiotic corporate interviews where preferred way of coding is apparently using a white board).
basic knowledge of fizbuzz, dfs, bfs, quicksort, and similar things of course is needed - however asking developers actually implement them in front of you is pointless, at least as far as job performance goes.
"Take these two variables, derpyOne and derpyTwo, and swap their values"
FizzBuzz is not some arcane algorithm. You don't need to study it.
It's literally writing a loop, testing equality, and printing some output. I don't know how you could program professionally and not be able to solve FizzBuzz.
This is the same for a lot of the basic algorithms we learnt and forgot.
This, to me is the big caveat. Just as there are a lot of people who are horrible at solving stuff they should easily be able to, I've conversely seen so many horrible interviewers that under-specify the problems they ask about because they assume people should understand algorithms that would make it easier to understand, or just assume people will infer things most people wouldn't.
For the record, I'm absolutely not talking about algorithms questions. I'm talking about literal FizzBuzz. A majority of candidates cannot solve it in 15 minutes.
> How in the world are people making it through schools (with a MS!) without actually.... uhh.... you know.... knowing the subject at all?
It's through a combination of:
1. Tests being based on memorization, not actual knowledge or programming. If you manage to stuff enough keywords into answers, it's possible to pass.
2. Lots of group work. The 20% of students who actually know how to program finish the project while everyone else slacks off and asks for help "with this one thing."
3. Outright cheating. There's a thriving market in recycled homework and exam answers.
No, 80% of people in the 'currently looking for a job developer pool' are terrible. But you have to consider that the worse a candidate is, the longer they stay in that pool. So judging developers as a whole based just on interviews makes them look much worse than they are.
You're right that the actual population of all job applicants over time is equally qualified to the employed developers.
However, the data that I have available to me as a hiring manager is the sample of developers who actually applied to my job. In that sample, incompetent developers are much more likely to be present because a competent developer only sends out <15 applications before getting a job while the incompetent ones can send out hundreds.
At any given moment, a competent developer is more likely to be employed than an incompetent one. Hence the incompetent ones are constantly generating job applications at a much higher rate than their actual presence in the population would suggest.
For the record, this isn't merely theoretical. The last time I was looking for a job, I was able to get an offer from the second company I applied to. Meanwhile a friend of mine with barely any experience had to apply to about 50 places before getting a single offer. If you were to pull a random sample of our applications, his would be way over-represented.
> think Google came out a while ago and said that their initial hires had no correlation to the really successful people in the company after...5(?)... years.
Sure, but Google still spends a lot of time and money on interviewing because anyone they hire has to be better than the average applicant. They get huge numbers of job applicants, the majority of whom are grossly unqualified.
> The interviewing process is known to be broken, so trying to extrapolate to say that the job-seekers are less good at these metrics than the employed is erroneous.
There are lots of problems with the interview process, but I'm really including anyone who managed to get to an interview (past the phone screen) in the "competent" category. There are seriously huge number of job applicants who can't program a basic loop without extensive help.
Actually, you only have the sample of developers you interviewed for the job. How many didn't get an interview? Are you confident that your resume filter is good and that the resumes rejected were actually bad?
> Meanwhile a friend of mine with barely any experience had to apply to about 50 places before getting a single offer.
Following up my previous point, how many interviews did that yield? The discussion here is over developers who look like idiots in the interview. Confusing that with applications clouds the discussion.
More specifically, I have the sample of developers who I did a phone screen with.
I'm reasonably confident that my resume filter is "good" in the sense that it's not rejecting people prematurely. If your resume shows any hint that you'd be able to do the job (ie. any amount of programming job experience and/or a CS degree) then I'm willing to give you 15 minutes.
> Following up my previous point, how many interviews did that yield?
A dozen or so. I'm deeply skeptical that the pool of applicants would be better than the pool of interviewees.
On the other hand this process makes about as much sense as requiring that I know how to shift a non-synchronized manual transmission in order to pass a driving test. Nobody is implementing most of these algorithms from scratch, and if they did it would be a bad practice without having a good reason to do it.