Hacker News Reader

> What's wrong with "I'd use a library" or "I'd Google it"?

Saying "I'd use a library" isn't a reliable signal. If you hire based on it, everyone will just parrot it. On the other hand, being able to solve programming/math problems is a reliable signal. Linus and Jeff Dean are very good at such problems and it's not a coincidence.

> Saying "I'd use a library" isn't a reliable signal.

True. That's why you shouldn't be asking a question where that's a good answer in the first place.

> Linus and Jeff Dean are very good at such problems and it's not a coincidence.

Sure. But being good at these problems also isn't what makes Jeff Dean or Linus good programmers. Being good at solving novel problems is. The problem with the linked list question is that half of your interviewees will have seen it before and half of them wont, thus giving you quite a biased view on them.

> half of your interviewees will have seen it before and half of them wont

That's just not true at all. There's a huge supply of algorithmic problems and it's easy to invent new ones, so a typical problem given in an interview will be novel to pretty much all interviewees.

> That's why you shouldn't be asking a question where that's a good answer in the first place.

I’d like a better question, but time is limited and spending lots of time on explaining the context behind a real example is harder. Although it’s not like I’m married to these questions and would gladly replace them with some generic question that tries to address threading, resource management, and whatever linked lists are supposed to test.

Disagree. The guy who built the system I am now maintaining reinvented the wheel many times. So now we have a lot of undocumented buggy code. Most people aren't programming the linux kernel, they are writing a variation on web based CRUD.

> What's wrong with "I'd use a library" or "I'd Google it"?

I meant if that’s their only answer and they aren’t able to design something like a linked list from scratch.

Usually the answer went like “I’d of course use the built in class Foo, but for purposes of this answer, yadda yadda yadda”

Sometimes I would get someone who would argue over wherever it’s a dumb question or try to explain how they don’t know how to make getters and setters because they would just Google the answer. So that’s a bad sign for culture, teamwork.

IRL you don’t want people making their own linkedlists, just like no one should actually write FizzBuzz.

But it’s helpful to filter out the number of non-programmers who apply for programmer jobs.

>But it’s helpful to filter out the number of non-programmers who apply for programmer jobs.

I keep hearing about these people, but I have never met one in 20 years.

May I ask if the approach you describe here was what you applied in the FAANG interview? I would be pleasantly surprised if it worked! :)

They asked no Linked-List questions (I was prepared for them, the only time I have ever used linked-lists was in interview prep).

I also think the FAANG interview was pretty bad overall (took 6 months to go through), the last question was great. It required no algorithms, but a difficult problem to solve that required me to think on my feet rather than apply a known algorithm.

I can also tell you that my current team leads have both emphasized the importance of being able to find information, less importance being able to do it off the cuff (which I agree with).

> the last question was great

What was the question?

They have pretty strict words around not sharing problems unfortunately, and while it's unlikely it would be traced back to me the potential isn't worth my job.

Damn, that sounds almost draconian. Well, thanks for sharing what you could!

Exactly. If I have a new problem to solve, I may have an idea how to solve it, but I might as well see how others have solved it as there may be a better solution.

> What's wrong with "I'd use a library" or "I'd Google it"?

The point of the question is to solve a problem in ~15 minutes. Algorithms and Data Structures are used for these because everyone knows them.

Thats the problem, they _don't_ know them and are expected to study beforehand because they're not used often in many roles

Any serious intro to CS course will have them as part of the curriculum (at least for linked list).

Even when not teaching about memory, it's used to teach recursion.

Not everyone who is a programmer starts with undergrad CS. Why not ask them to build a basic web app in their preferred framework, or read and process a basic text file, or any number of things that are more practical than implementing a low-level data structure?

Right I expect anyone that just graduated 1 or 2 years ago to be able to write it in 15 minutes.

But someone who is an expert in machine learning or SQL ... and have not used data-structure for the past 20 year would need to study for it. Do you want to hire the programmer that have 0 deep knowledge of the specific thing you are working on but can quickly tell you the content of CS 101 books or do you want someone that have skill set, experience and knowledge that complement your current team?

That's fine for assessing graduates, but good developers with a lot of experience won't be as familiar with writing algorithms from scratch. They'll have to do a lot of revision for technical tests just to memorise reels of information they'd google in 10 seconds in real life.

> Any serious intro to CS course will have them as part of the curriculum (at least for linked list).

Your implied assertion is that a CS degree is required for programming. That's a good way to select for people like you, which is one of the strongest biases in hiring. One should also take survivor's bias into account, increasing the likelihood that if you're a programmer and did a CS degree, you think a CS degree is required.

Whether a "serious intro" to CS should include recursion and linked lists depends on whether you think:

a. a CS degree should prepare for a programming job

b. it should only prepare for a programming job

c. a CS degree actually prepares for a programming job

d. data structure knowledge is fundamental to programming in general

My personal answers are it should prepare for a programming job, but not exclusively, and that it doesn't usually (adequately) prepare for a programming job. In that context, it should include data structures, general computer architecture and similar historic/foundational topics. I wouldn't go so far as to call them fundamental, because that implies they're must haves. I also wouldn't go so far as to say any CS course that doesn't offer them isn't serious. Maybe that school has a greater focus on preparing for the job, or maybe someone's major is more akin to IT project management than technical.

In the end, a degree is:

* a proxy for general intelligence

* a basis for your social network

* a status symbol (school pedigree)

* an introduction to the topics covered

* an authority argument

* an indication of how well that person does at tests in an academic setting

That's it. If you're lucky, someone with a degree remembers most of what they covered in classes. At best, a CS degree is correlated to someone being able do fill a programming role.

What programming may require is:

* General intelligence

* Systems thinking (e.g. abstraction, information flows, decision trees)

* Programming language skills

* Patterns (architecture, design, OO/FP)

* Knowledge of data structures

* General IT knowledge (DevOps)

* Domain knowledge

* Framework familiarity

* Math skills

* Solving novel problems

* Absorbing new knowledge

* Communication skills (requirements gathering, expectation management, reporting, etc)

One could arrive at these skills through passion and dedication to the hobby, learning on the job, vocational training, a bootcamp, a CS degree, a PhD and more. Of these skills, the ones least likely to be required for the vast majority of positions are math skills and data structures - beyond the absolute basics.

I think it's important not to get our Ps and Qs reversed, don't you?

You forgot a crucial variable: Signal to Noise.

Sure, a bootcamp grad might have the required skills, if I'm lucky. But most won't and interviewing over and over has a non-negligible cost (I'm wasting everyone's time)

A serious CS degree provides a better signal to noise ratio. And should cover most of the points you listed as potentially required to program anyways.

> interviewing over and over has a non-negligible cost

I would say, specifically in the US where this type of question is asked, it is negligible compared to a dev's yearly salary. What one should consider is the time spent interviewing all candidates versus the cost of making a bad hire and doing it all over again. The only thing you're limiting when interviewing fewer people is the short-term cost of "hours spent doing interviews". That's a myopic metric.

Another thing I didn't mention in my list is churn or employee retention. Another aspect is if your domain/application might be more appealing to someone who doesn't have a degree and might stay interested and on board longer.

> A serious CS degree provides a better signal to noise ratio.

For one, noise is subjective. And in filtering out the noise, you're filtering out outliers - both good and bad. Even assuming you're right, that would only mainly apply to juniors.

> And should cover most of the points you listed as potentially required to program anyways.

The question is if you're selecting for the right criteria, since some of my points can only be arrived at through experience and general maturity.

The simple fact is: an education is only one aspect of someone's CV, a start and a depreciating asset over time. There is no sense in ignoring the candidate's job experience, general life path, public repos, etc.

> I would say, specifically in the US where this type of question is asked, it is negligible compared to a dev's yearly salary. What one should consider is the time spent interviewing all candidates versus the cost of making a bad hire and doing it all over again. The only thing you're limiting when interviewing fewer people is the short-term cost of "hours spent doing interviews". That's a myopic metric.

You are right, most of the cost is in the bad hire.

> For one, noise is subjective. And in filtering out the noise, you're filtering out outliers - both good and bad. Even assuming you're right, that would only mainly apply to juniors.

True and true. A bad hire is extremely costly.

I would argue that's a bad "point of the question" -- also, many of them are in 50 minute interviews.

Call me crazy, I think an interview question should test for one's ability to program well, not test their memorization knowledge.

My argument is precisely that linked-list questions are a poor proxy for programming well. It's testing the wrong thing(s).