Hacker News new | ask | show | jobs
by levemi 3709 days ago
If you complain about CS requirements for software engineering jobs your complaints are going to fall on a lot of deaf ears because people desire competency. Dunning-Kruger is having its impact felt in these threads. If you think computer science fundamentals aren't a requisite for software engineering it's probably because you don't have the experience and skill necessary to understand what engineering competence looks like.
3 comments

Mindcrime isn't saying CS isn't required, they're saying it doesn't require a full hour to judge whether they're competent or not
Mindcrime isn't saying CS isn't required, they're saying it doesn't require a full hour to judge whether they're competent or not

Yes, exactly.

That said, I should add the disclaimer that I'm referring to fairly general roles. If you're genuinely hiring for a highly specialized role that requires more specific knowledge, then that might change the equation a bit. I should have been more explicit about that earlier.

I find it very difficult to imagine how an engineering position wont benefit from having strong CS fundamentals. If you write code you need to understand how the code you are writing works. How the libraries you depend on do what they do. If you run into problems you'll be need to able to think of solutions. This idea that you'll look up how to do some computer science algorithm when you need to is ignorant, because you may not know when you need it.

A lot of the CS fundamentals in interview questions demonstrate an ability for problem solving and abstract thinking. It demonstrates your ability to handle coding problems under stress. Resorting to complaining about hard computer science problems is the exact opposite response you should have. It should motivate you to improve and learn more, not feel bitter and angry. Likely this attitude indicates a poor culture fit as well. So in effect asking computer science question is doubly useful, because it helps filter out candidates who opt for alternatives to self-improvement and overcoming challenges.

You were replying to me, but I agree 100% with all of that, and it doesn't contradict anything I said, so I'm not sure what else to say. I guess I could just be more clear in saying that, for me personally, I'm not "complaining about hard computer science problems", I'm just thinking about how to optimize use of time. Personally, whether I'm the interviewer or the interviewee, I'm not partial to interview processes that take all day. That and I'm not partial to asking people to implement difficult algorithms on the whiteboard. My take is this:

1. If you're doing whiteboard stuff, keep it high level, see if the conceptual understanding is there, and move on.

OR

2. Give the candidate a computer, editor / IDE, compiler, google, etc., and let them work they way they work, implementing $WHATEVER.

A couple of questions - how many years out of college are you, and how many red-black trees have you actually had to implement from scratch in that time? Me, 20 and 0, respectively.
Dunning-Kruger is about competence, as in competence at the job you will be doing. Competence in CS does not translate into competence in software engineering. People who are employed to write REST APIs or most other software should not regularly write novel implementations of basic data structures like hash tables, it's an incredible code smell.

Thinking that CS makes you competent as a software engineer and that you will regularly be implementing red-black trees is a typical fresh-out-of-college mistake.

Your comment would make sense if CS is all they talked about during the interview, but it's actually only a small portion of the total process--an hour or less.