I'd be interested to hear what you would expect as bare minimums for a "basic entry level technical role." I've heard of recruiters being dumbfounded at CS grads not being able to code FizzBuzz and to be honest I can't believe it.
One experience involved a recruiter who wanted a compete rewrite of a CV portion outlining a SQL project from planning to continuous implementation models I built.
This on top of 8 years of other experience in data design and management.
The recruiter wanted to pass on my resume because I had failed to indicate my experience with flat CSV files and thought I needed more experience with them as a "highly specialized software stack".
I decided not to pursue that company further, maybe it was ego getting in the way but insisting I rewrite a technical resume covering 10 years of database experience over the omission of operating with flat files seemed like refusing to hire a qualified electrical engineer because he didn't list AA Batteries on his resume.
LOL! It won't be long before the majority of EEs under 25 won't even know what an AA battery is. In fact, I bet it would be pretty hard today to find someone in their 20s who knows what a 9-volt is.
Remember, their phones and tablets charge from a cable but their toys and remote controls use 9-volt, AAA, AA, and D batteries.
Edit: I guess you were emphasizing the obscurity of the 9-volt in particular, but I think they probably have several things that use 9-volts.
Now if you said 4.5V flat pack lantern batteries, then yes. I've seen like 1 before, and it was dead.
I know it sounds silly because it's written clearly here, but in a spoken interview it's possible an interviewee can miss a detail and suddenly think they're faced with travelling salesmen. Or are worried about I/O
Of course in those situations, the "right" thing to do is ask for clarification, or think out loud. And an interviewer should make sure the interviewee is solving the right question (in the real world, people help each other).
One proposed open-ended interview question in particular (these recruiters utilize both coding exercises & open-ended questions, plus some other stuff), "What's the difference between the stack and the heap?" was shot down for a number of reasons - colloquially, these refer to two different pools of memory wherein variables can be allocated. But stacks and heaps are also specific data structures, so there's some ambiguity. Most importantly, it's surprisingly difficult to answer that with anything that's 100% correct (e.g. "the stack is for variables with known lifetimes, whereas the heap is for those with unknown lifetimes" is really just a convention, and there are plenty of exceptions w.r.t. data structures of size that isn't compile-time constant, or dealing with polymorphism in certain languages). And since the question is rooted in fact, vs something that's intended to be debatable, lots of people won't throw forward the thoughts they have that are only 80% correct - they effectively freeze.
Should programmers in interviews know that?
After the second semester, CS students divide into three groups:
1) stressed out hobbyist programmers having their mind blown by the complexity of what they're learning,
2) people with no programming experience failing to learn to program (because the intro courses don't actually have any lectures about the basics of programming) and switching majors to business or engineering (because they've already taken calculus), and
3) other previous non-programmers who are copying other students' work or googled answers from the internet.
Type 3) eventually graduate, get jobs based on having the degree, and never finish a project in a programming role by utilizing a combination of charm, excuses, and transferring between jobs before they have to show their work. If they can paula = "Brilliant"[1] long enough, they can get into management before they are exposed.
So many of the people I did CS with never even learned basic programming skills before they got their diploma. This is at a major state university with a very well-regarded program.
Chalk it up to yet more evidence of how tech interviewing/hiring is utterly broken.
Both seemed to really liked hiring odd canidates but were no slouches on coding.
You aren't doomed or damaged if you haven't programmed before hitting college. Claiming that is slandering a generation of engineers.
I can see why my comment could be seen as slandering all non-hobbyist programmers rather than programs that don't bother to teach programming because they expect you to already know when you arrive, but you would probably have to skip the second sentence of the first paragraph, and the first parenthetical in item 2).
Thanks for the rage, though.
Again, I watched people graduate who couldn't fizzbuzz. They got jobs, and they still couldn't fizzbuzz. These were friends, who I liked very much as people, and I'm as happy that they got good jobs as I am sure that anybody who hired them should be fired.
No, I think you're just poor at communicating. Your claim was "After the second semester, CS students divide into three groups", and then listed those three groups, zero of which involved a person who was new to programming doing well. You had every opportunity to hedge your statement, and you did not.
People that have worked in brown fields are often selected out by recruiters because they think it's harder to build a system than to maintain one.
Said candidate did not know what a unit test was and could not figure out how to write one, even after the concept was explained.
I have no idea how this could ever happen.
Should they know about unit tests though? That's a developers job.
I also would be shocked if a CS grad could not complete FizzBuzz, but apparently that happens.