Hacker News Reader

Comment by squiguy7 | Hacker News Reader

Interviewing seems broken to me too. I have spent the last few months trying to get a job out of college and everyone seems to be interested in how well you can regurgitate CS fundamentals.

They are seemingly less interested in seeing how you solve problems and work through the process of software.

I would be more than happy to see this process change, I am just not sure what it entails.

View on HN

Devil's avocado: if they're truly CS fundamentals, then they should be baked into you good and deep during the course of your college education. It shouldn't be painful at all.

Especially as a fresh grad. Reviewing for a week or two if you've gone to a good school/actually did your work instead of 'consulting google' is definitely enough...

I think the real issue is that most programming jobs aren't computer science jobs, so CS fundamentals are almost totally irrelevant.

amen to that!

I graduated this spring and I don't know how to do that. Now, I am not a boy genius but I doubt it is a CS fundamental.

What material did you spend time on that you don't know how to reverse a binary tree?

It isn't a difficult problem, even having never seen it before. This is one of those warmup problems to test how comfortable a candidate is with basic concepts such as recursion.

I think it's a pretty easy question. Pretty much all algorithms courses teach you enough to be able to solve this question.

I took CS 101 classes almost a decade ago, and since then, I have never once needed to write a binary search tree outside of an interview.

I think "CS Fundamentals" are really just "abstract concepts used to teach programming", and calling them fundamentals is disingenuous.

CS fundamentals like BSTs are definitely not used to teach programming--things like video game projects are--they're used to teach algorithm design and analysis. CS is an academic science, it's not a technology trade.

Maybe you're just not doing serious programming. Most people I know implement data structure searches quite often.

If you're writing scripts, or JS code for web pages or something like that, then maybe you don't use CS stuff, but ... are you able to write a web browser if you had to? Are you able to write an operating system or navigational software for a spacecraft? If not, then maybe just see this as revealing sectors of your skill set that could be beefed up, rather than presuming that none of that stuff is important.

> Maybe you're just not doing serious programming. Most people I know implement data structure searches quite often.

Wow. Really? Most serious people I know use other people's implementations that have already been highly optimized and well tested because they have better shit to do than reinvent the wheel.

I suppose if you want to write your own red-black tree from scratch, that's your prerogative. The last time I did was 20 years ago and not only will I never do that again, I will laugh at anyone who does it without a damn good reason.

> Wow. Really? Most serious people I know use other people's implementations that have already been highly optimized and well tested because they have better shit to do than reinvent the wheel.

Ditto. Those who decided to reinvent even basic data structure stuff left me a huge string of bugs to fix, which I eventually got so fed up with, that I started replacing their code wholesale with off the shelf solutions to stem the flow at my last job.

Aside from fixing an untold number of implementation bugs, the replacement caught several usage bugs as well, due to actually having some error checking built in.

We had just plain broken hashtables, "lock free queues" that didn't use memory barriers... or interlocked intrinsics... or even volatile, if my memory is correct - and not a debug visualizer to be seen before I got my hands on them, of course.

> I suppose if you want to write your own red-black tree from scratch, that's your prerogative. The last time I did was 20 years ago and not only will I never do that again, I will laugh at anyone who does it without a damn good reason.

Besides laughing, I'll tend to -1 the code review as well.

Nobody's advocating rewriting your own red-black tree from scratch, for no reason. People applying data structures talent and skill aren't copying down algorithms they have in the standard library.

In many performance-programming situations you are subject to constraints that prevent use of a general solution or else makes use of a general solution massively inefficient.

For example, your data structure is on the GPU and your data is in a texture in a certain specific format because of other reasons.

If you wrote the above reply without considering this kind of case, it probably means you haven't been exposed to very much of this kind of case ... ... which was my original point.

The question isn't whether you should reinvent the wheel, it's whether you can if need be. It is important for companies to weed out candidates that can talk a good game but are useless when it comes to actual programming. So maybe in the process good candidates fall through the cracks, but then again, nobody has invented a perfect way to interview candidates.

In any case, how would you even go about knowing whether a certain piece of existing code that you blindly pulled in from some random place is optimized for your particular use case without first being able to conceptually understand it - which is all an interview is. Nobody expects candidates to create production ready code on a whiteboard.

I think a more fundamental skill these days is figuring things out. For instance, a test where you actually have to google for the docs to something and figure out how to use it might make more sense.

The idea that "serious programming" means abstract data structures or coding in assembly is weird to me. I would consider a lot of people serious programmers who, while they may know how to do those things, don't actually do them almost ever.

If you are trying to get a job straight out of college and you didn't have many relevant internships, there really isn't much to judge you on other than what you learned in college. This isn't a fault with the interview process.

Some companies give take-home assignments (small projects that can gauge how well you learn). I tend to find that these are smaller companies. You can always try there.

Also, the most important thing that they don't teach you in school is that getting a job is all about connections. Email some people that you've interacted with to see if they know of anything that might be suited for you.

I guess it depends on where you're interviewing and what their expectations are of you. Since you've just graduated they may expect you to be very junior and just want to make sure you have a good CS foundation. They should ask problem solving questions but it wouldn't be weird if they just focused on what they think you know.

Reply on news.ycombinator.com