Hacker News Reader

Comment by moonshinefe | Hacker News Reader

They actually got you to build a linked list from scratch? That's somewhat hilarious, considering you can get a book within 10 minutes that'll show you how to do it, not to mention unless you're a terrible programmer who reinvents the wheel and doesn't know how to google, that situation isn't realistic at all.

View on HN

Think of it as a slightly less insulting form of FizzBuzz.

I regularily used a similar exercise to weed out bad candidates. The task was to build a stack with based on a double linked. Looking up stuff was okay, but straight copy paste was not. I gave them half a day and told them to write the best code they can.

There where many discussions how that exercise is relevant to the junior PHP dev position we were hiring for (spoiler: it's not). But it gives you a good idea what the candidate considers good code (consistent code style, documentation, tests,...)

I'm curious about the stats (if you have them): how many of the candidates added documentation ? because one could argue that documentation by itself is not DRY since now you have both the code and the description of the code (the docs). if the code changes - you MUST change the docs as well (otherwise the docs and the code are not overlapping, which is much worse than not having docs in the first place).

I might be completely wrong about documentation not being DRY, but this by itself could be a good conversation with a candidate .

OK since I'm being down voted for this post, let me clarify: if you read the context which the OP mentions in the blog post, he/she was given a take-home assignment.

I agree, rooting out people who can't do basic things like linked lists is desirable, however, if you're going to send a take home assignment, my point was, you're not going to get a very honest measurement of their capabilities on one that they can google in a few seconds. That's all I meant.

My interview at other $BIGNAMECO was "fix" an existing Linked-list implementation on site. That was pretty fun, IMHO.

That does sound fun! I think figuring out bugs is a good way to find out if someone knows what they're doing at all. My main objection was "implement a LL from scratch in X language!" -> googled in 5 seconds and slightly modified, done as a work-from-home and hand in assignment.

I'd enjoy a good debugging question for sure.

People complain a lot about basic CS assignments in interviews. Just thinking out loud: it's an important skill to be able to put together libraries and existing code to get a working product. But a lot of software is crap, and I think often one of the contributing factors is a lack of knowledge about data structures, design patterns, algorithms... in other words, the stuff that a CS education might actually teach you about. You can't look something up if you don't know enough to look for it (and to understand the answer) in the first place. So the "irrelevant" basic CS problem interview questions might be a way to check not only if you can build a product, but if you can do it well?

I think the irrelevant CS problems are an okay test to see someone's style and thought process where they shouldn't be too worried about solving the problem (they should have at least a meager basis of understanding to begin with) and can spend time cleaning up, and preparing their thoughts for presentation. I think this is fine as one of multiple measures.

I graduated from CS, and the only reason I knew anything at all about how to handle multi-tier architecture is because I was employed previous to my graduation. How do you keep configuration from being a mess? Hard coded values all over the place, etc. CS courses give you the theory needed for getting started down a path of understanding, but it does not make you understand, nor does it actually prepare you for the real world. Data structures are one thing, micro services, unit testing, configuration management, dependency injection, and persistent storage are beasts all unto themselves.

Nearly every interview is not realistic at all. At least it's better than whiteboarding.

Fair point, but I'd at least expect an original assignment to be submitted later that isn't like in thousands of data structure programming book out there. Well, maybe expect isn't the right word, but I'd never run my interviews with such trivial requests that don't reflect what the actual work will be (hopefully they aren't writing LLs from scratch, anyway).

Do you have an example what would you ask on an interview ? I am just curious.

Sure. If it's say a web application, I'd invite them to install the framework(s) / libs used and to implement a basic feature that could actually be used in an application they'd be working on. Nothing super complicated, but something that wasn't "reinvent the wheel that's googled easily". I'm not aware of many major programming languages these days that are missing linked lists or similar data structs.

I'd also pay them for their time, regardless if they got the job.

The best interviews are those that make an attempt to be realistic rather than assuming correlation between ability and knowledge of some of the more rarely used textbook knowledge.

You are a terrible programmer if you can't implement a linked list. It's so basic that not being able to cope with it means you don't understand indirection, which is the fundamental of all programming. Is it a good interview question? Depends on the language: its perfectly valid to ask for a C programming position, but makes little sense for a JavaScript role (as in there are more meaningful problems for assessing their knowledge).

Reply on news.ycombinator.com