I've seen American university CS grads wash out on FizzBuzz level questions at alarming levels as well so this is not exclusively a phenomenon with these backgrounds.
How in the world are people making it through schools (with a MS!) without actually.... uhh.... you know.... knowing the subject at all?
The question is if the questions asked are really "FizzBuzz level" questions, or algorithm questions that are easy to consider of similar complexity when you know the expected algorithms.
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.
> basic knowledge of fizbuzz, dfs, bfs, quicksort, and similar things of course is needed
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.
People should be able to solve FizzBuzz provided it is explained properly and fully.
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.
Why do you bundle fizbuzz with some legit algorithms that require some knowledge? Fizzbuzz is a gimmick, deliberately picked as something very simple to filter out clowns. I can't imagine a more simple programming task. Any suggestions? ;)
A lot of people are pushing back on you, but I've seen the exact same thing. I think everyone who hasn't interviewed developers would be surprised by the general incompetence, but everyone who runs an interview process realizes that 80+% of "developers" are terrible.
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.
> everyone who runs an interview process realizes that 80+% of "developers" are terrible.
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.
Maybe. With a large enough population for either the job-hunters or the employed, you should regress to the mean for the total population and the deviation should also be similar. This assumes a normal distribution for the metrics that you are hired for, something that may not be in fact true, ie. Poisson or exponential distributions are reasonable. What you can take away from this: Your own developers may not be as good as you think they are OR they may be much better, same for the candidates. That particular day you interviewed them they may have been exceptional or they may have been ill and they failed, or a million other reasons. I 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. I can't find the citation, sorry. 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. I'm not saying you are wrong, just that using a binary decision like this to determine these things is wrong.
> With a large enough population for either the job-hunters or the employed, you should regress to the mean for the total population and the deviation should also be similar.
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.
> However, the data that I have available to me as a hiring manager is the sample of developers who actually applied to my job.
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.
> 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?
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.
IIRC Google said that their interview scores didn't correlate with how successful people were in the company. But you have to remember that obviously they're only talking about people who made the cut, so people who had at least moderately high scores to begin with.
> How in the world are people making it through schools (with a MS!) without actually.... uhh.... you know.... knowing the subject at all?
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.)
If you know even some basic programming and logic, you should be able to come up with a reasonable fizz buzz solution. You don't need to have studies the fizz buzz algorithm in college, or have practiced a solution.
> ..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.
Or a medical student who never did an operation before? Arts are the exception, not the rule. In other areas it is fully understood that the whole purpose of the program is to teach you everything, so actually saying "you have to know this before" would be weird.
Medical students are expected to have a strong science background, and well before they commit to being a surgeon they'll have units where they need to wield a scalpel. If they find out it's not for them there are plenty of other paths which don't involve surgery.
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.
> 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.
I would expect that the project they work on to utilize the knowledge in the courses. With 4 projects a year at 4 years, there's got to be something learned!
I got a BS in CS, graduated in 2006. What 4 projects? We had one project that lasted an entire semester, in one class; the rest was mostly one-off homework assignments that were very much topic-of-the-week. And most of them didn't really require coding.
"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.
Computer science programs, even at very prestigious schools, don't really require you to know anything about programming or practicality using computers. The amount of real hands-on work I did for classes in my entire undergrad career is less than I do in a good week at work.
> I've seen American university CS grads wash out on FizzBuzz level questions at alarming levels as well so this is not exclusively a phenomenon with these backgrounds.
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.
I'm rather shocked by this as well. I understand not knowing the latest frameworks and such, but I have close personal friends that say my name should be in parenthesis next to theirs on their diplomas. A lot of CS courses can be passed by getting help on take home assignments and rote memorization on tests. At least for your typical state schools.
How in the world are people making it through schools (with a MS!) without actually.... uhh.... you know.... knowing the subject at all?