Comment by throwaway2016a | Hacker News Reader

Comment by throwaway2016a | Hacker News Reader

In a way I prefer this to "how many ping pong balls can fit in a school bus" that was all the rage in the 90s and early 2000s. But... man...

I have a computer science degree, I've been coding for 20 years, and I've held (and kept) a CTO role at two mid-sized startup companies. Currently I'm considering looking for a job at a larger company (where I wouldn't be CTO but I'd be hopefully paid more) and these kind of questions make me think I need to almost go back to school before I can start interviewing.

When did it get to the point where we need to read thick books on programming interviews and spend hundreds of hours on HackerRank practicing algorithms to get a job where we probably won't use any of those day-to-day?

Edit:

For fun the other day I decided to code a linked-list from scratch in C and it took me a half-hour plus... and I have known that data structure for decades. I can't imagine doing a harder problem under the pressure of being an interview.

Keep in mind that, because the number of programmers is increasing, the majority of them are fresh out of school or close to it. Algorithms interviews are largely designed for interviewing people who don't have much experience, so they're skewed toward testing what people learned in school.

If after 2 CTO roles you interview for a job and they ask you to write a linked list algorithm, then would you want to work there? I mean you might, but that alone should at least beg the question. If they're not asking you how you'd manage a team of smart but stubborn coders or structure their company's software architecture and services to be more reliable, then they certainly aren't paying much attention to you or what your strengths and experience are. Or they simply don't know how to hire an experienced person, which signals that they don't know what to do with an experienced person once hired.

Also, it would take the vast majority of great coders at least a half hour to code a linked-list from scratch in C and get it right, depending on what you're doing.

So don't worry.

>Keep in mind that, because the number of programmers is increasing, the majority of them are fresh out of school or close to it.

But the number of unfilled positions is also increasing, so we are not closing the gap, right?

So the gap is widening, but the requirements to get a position are also going up. That just makes no sense to continue for a long period of time.

If the number of unfilled positions is increasing, that would tend to lower the requirements, not raise them. If the number of filled positions is growing at the same rate as the number of unfilled positions, that would be evidence that the requirements are staying roughly the same on average. (Except I'm sure there some small amount of average improvement and widespread knowledge increase every year that everyone benefits from.)

In any case, it still makes sense for companies to come up with interview strategies for inexperienced devs, and the article at the top is once such way. It doesn't mean companies will interview experienced devs the same way, and in my experience, they don't.

(EDIT I had written some other junk based on me misreading your comment, apologies if you had to spend any time on that.)

I agree. To find out if one is actually competent, open questions that allow the candidate to elaborate on his previous problem solving experience are much more useful.

Some examples:

1) Explain how and why you would implement authentication on a HTTP API. What other authentication methods do you know and why would you not use them?

2) Tell us about a scaling-up challenge/problem you had on your last application and how you solved it.

3) What technology stack would you use for a browser-based P2P file sharing application?

4) Name a library you recently discovered. What problem did it solve?

5) What mobile app on your phone right now has a bad user experience in your opinion? How would you make it better?

Personal opinion but I think "how many ping pong balls can fit in a school bus" is not that bad.

I've asked HR people why they ask that question, and it was not to have a correct answer but to demonstrate your train of thought.

When I give a coding interview, I will use more development oriented questions but I want to see HOW they get to the answer, not the fact they memorized an algorithm that just so happened to be on the coding test.

If you've got that much experience and someone asks you how to impliment a linked list, I'd say you should politely leave the interview. Graduate questions like that are insulting once you've got past the junior levels, as companies asking them are either too lazy to put a proper interview together for more senior levels, or not senior enough to know the difference.

That's not to say they can't ask you about data structures, but they shouldn't be asking you to code them up from first principles if it's something the language can do for you.

I find it much more fruitful to have a technical chat with candidates instead of being dogmatic about asking toy questions. It's pretty obvious when someone doesn't know what a linked list is with a 30 second chat. Heck, even drawing a few boxes and arrows on a napkin will suffice.

Reply on news.ycombinator.com