Hacker News Reader

Comment by mindcrime | Hacker News Reader

Sounds pretty horrid to me. I mean:

11:00 to 12:00: Computer Science and Algorithms

Do you really need a full hour to tell if somebody has a good basic grasp of CS and algorithms? I can't see it. At least not in the best case. The way I'd suggest doing it is this: Ask a question that can result in a "1 question yes". That is, pick a sufficiently advanced / interesting algorithm, and ask questions about it, and/or ask the candidate to implement it. If they pass on that, move on from CS/algorithms to something else. If not, move to the 2nd choice algorithm, and repeat. Do that for a few iterations. This way you only fill a full hour if the candidate forces you to dig really deep into your list of topics.

The same methodology could be applied to the other domains as well.

View on HN

Computer Science is a three year degree at least - you can't spend an hour talking about it?

Even implementing something simple and well known (like a breadth first search for example) on the white board can take an hour, if you are discussing it as you go along, and the algorithm has to be tailored and optimized to fit the interviewer's question.

Computer Science is a three year degree at least - you can't spend an hour talking about it?

Sure, you could spend all day or all week talking about it. But the question is, do you need to, and is it a useful thing to do in a job interview setting. But I'm biased here, because I'm generally not a fan of day long job interviews. I don't think they're necessary or practical, at least for most roles.

Funny you should mention breadth first search - there was a post about hiring just a few days ago where the author was complaining about its used as an interview question: https://medium.com/@evnowandforever/f-you-i-quit-hiring-is-b...

I'd be OK with using BFS or DFS, but with this caveat:

If it's a whiteboard thing, then don't expect a detailed, working implementation in code. Ask for a sketch / high level overview / pseudo-code that shows the candidate understand it well enough that you can infer that they could implement it with a compiler / google / book / etc.

If you want an implementation, give them a machine, let them use their language of choice, use google, etc., and let them actually code it up, making and fixing errors as they go, etc. I actually like this because it lets you see how someone approaches debugging, etc.

In either case, you could supplement the exercise with some discussion questions "why /when would you use BFS?" etc.

When I last did a bunch of interviews every single one had a BFS question!

I do not agree with hiring processes many companies are pushing. However, if you do not know what BFS is, I do not know where to begin.

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.

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.

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.

I actually thought 1 hour seemed pretty reasonable.

> has a good basic grasp of CS and algorithms?

Maybe they want to see if someone has more than a "good basic grasp".

Then I'd posit that they're probably wasting their time unless they're VERY specific in the requirements they publish in their job ads. CS is too big for anybody to be an expert in everything. If you want a graph specialist, or a machine learning specialist, or a filesystem specialist, then sure, go really deep. But my feeling is that most of the time, these companies aren't hiring for highly specialized roles and there's no point probing "is this candidate at an advanced level on graph algorithms" when the answer might be "no, but she's an expert on optimization algorithms and numerical computing" instead.

Reply on news.ycombinator.com