Hacker News Reader

Comment by wheaties | Hacker News Reader

When I had less than 5yrs experience I used to ask these types of questions, thinking they showed the ability of a developer to reason out critical software issues. Then I met a guy who had practically memorized everything I could ask. He spit out answers so fast it was appallingly clear he was regurgitating answers from a book. This proved nothing about him and everything about me.

Today, I recognize that good software development owes nothing to data structure knowledge or obscure algorithms. This knowledge can't hurt but very few jobs or languages require you build a skip list from scratch. Instead, writing good software requires the ability to maintain a system, to debug problems, and to give constructive code review. That's it.

View on HN

For functional purposes, I consider myself to know something if I could page in the details well enough to implement it in 5 minutes with Wikipedia or less.

How this plays in interviews is interesting for just how inconsistent it is. Sometimes I win the algorithm lottery and have had reason to implement the obvious solution myself at least once, and the interviewer learns my memory works. Sometimes I don't know what they're going for but come up with a reasonable answer anyway and the interviewer is thrilled I managed to have an independent thought. Sometimes I lose and the interviewer is clearly trying to guide me to the answer they want to see and I have no idea what they're getting at.

Though not quite as bad as a friend failing an interview for not using a hash table, even though the answer he described was a hash table—just with the identity function as the hash.

(Though maybe about as absurd as one interviewer digging for any formal training I might have had in C++. Like you can teach that language in a semester—please. There are maybe 4 proper experts on the planet.)

I think there might be a happy medium. Knowing how to implement a specific algorithm is not necessary. Knowing of algorithms and picking the right one is important. For example, a junior developer apparently forgot about hash sets. He used a list for lookup. Worked fine in his local tests. Fail miserably when we had to load millions of records. A more seasoned programmer should be able to explain why a hash would work well here.

Accidentally quadratic is good for a chuckle too

https://accidentallyquadratic.tumblr.com

I used to do interviews in one company I worked for and we had this online test, which consisted of four tasks very similar to those in the list.

There was this one candidate who, by mistake, was given the test twice. Apparently he took offence to that. He found that his friend did the exact same tasks so he copied them.

The designers of that test tout that their system is able to detect plagiarism, but that was not the case here.

Anyway eventually we hired him because even though his first attempt wasn't particularly impressive and he cheated a face-to-face interview revealed that he was a skillful programmer.

One thing I learned from this experience is most of the time these test simply confirm that the candidate went to college - sometimes a particular one.

I agree 100%. I'm hoping that Disseminating these practice materials will eventually topple the whiteboard interview by exposing it's futility.

>Today, I recognize that good software development owes nothing to data structure knowledge or obscure algorithms. This knowledge can't hurt but very few jobs or languages require you build a skip list from scratch. Instead, writing good software requires the ability to maintain a system, to debug problems, and to give constructive code review. That's it.

While I don't think that the current state of interviewing is perfect, this statement is pretty out there. Good software development owes NOTHING to data structure knowledge? Choosing the right data structure is critical for software that performs well (or performs at all once you get to a certain scale), and demonstrating knowledge of various data structures shows at least that a candidate knows a bit about which tools they have available to them on the job.

Of course not many people are implementing skip lists from scratch in their everyday job, that's why in the list of 500 questions none of them are "Implement a skip list". Data structure questions rarely ask you to implement some data structure from scratch, they ask you to look at a problem and figure out which data structure best lends itself to the solution.

I won't argue that asking questions about obscure algorithms isn't a problem, but good interviewers aren't asking questions that need obscure algorithms, they are asking questions that need algorithms like DFS, basic variations of sorting, and basic DP problems.

Yeah, the strange "data structures and algorithms are either everything or nothing" polarization in the opinions on tech interviewing is strange.

You're focusing too much on a particular phrase and not enough on the overall meaning. Read this again:

> Instead, writing good software requires the ability to maintain a system, to debug problems, and to give constructive code review. That's it.

Code review is the best time to talk about data structures and algorithms as they are a time to apply theoretical knowledge to real world problems. Good, constructive code reviews are about education and maintaining a quality code base.

Interview questions about data structures and algorithms rewards memorization and classroom knowledge. I've worked with way too many mediocre developers who are great at whiteboarding interview questions but who couldn't build a maintainable system if their lives depended on it. Consequently, I don't give a damn about a candidate's performance on these types of questions. Instead, I'd rather learn about some projects they've built, problems they've experienced and their experience with code reviews.

Could you explain your reasoning? Someone doing really well doesn't seem like a reason to stop asking other people algorithms questions.

Because he understood that this data point falsified the general theory that answering questions about algorithms and data structures implies an understanding of algorithms and data structures.

Check for understanding by not asking book questions and expecting book answers. Ask variations on book questions.

For example, in junior math the prof went carefully through deriving the Fourier Transform. On the final exam, the question was to derive the Hyperbolic Transform. This was straightforward if you understood the FT, but not if all you could do was parrot it.

So that said how do you vet talent? Ask them to tell you stories about maintaining systems, debugging, etc?

Personally, yes - I like asking about high-level run-downs of a project on their resume. I then choose points to stop them (either randomly or if I know a lot about the subtopic) and dig deeper and see where their comfort level lies.

There are a lot of benefits to this approach:

1. Keeps the topic on something they are presumably comfortable with.

2. Gauges their seniority level: more senior folks can talk deeply about a wider variety of topics.

3. Tests their communication and explanation skills, again about a topic they should be comfortable with.

Some potential pitfalls:

1. Makes it harder to objectively compare candidates. I think this is impossible anyway, so I don't consider it a big deal.

2. Some candidates, especially junior ones, simply don't have many projects on their resume to talk about. In this case I'll often ask them to explain a skill or technology they are experienced with.

3. It's harder to conduct these interviews. Giving a problem and passively watching and helping as needed is a lot easier than keeping up an active dynamic conversation.

I've seen (from both sides) two things that seem to work.

Firstly, write actual code to solve a simple but real, or at least realistic, problem. That could be a take-home exercise, or it could be on-site pair programming, or some other format. Memorable examples: a stock exchange (submit orders, get trades); a Tetris engine (submit blocks, get rows filled); an auction house (submit bids, get winners); an uploader for the Azure blobstore (submit blocks, get files); an online metric summarizer (submit samples, get summaries). This tests someone's ability to actually write code.

Secondly, suggest an algorithm for a real, or realistic, problem that doesn't have a well-known good solution. Memorable examples: subset-sum, but on an ordered set, where the solution must be contiguous; placing primers for PCR [1]; online k-anonymisation [2]. This tests someone's ability to think on their feet, and synthesize facts they've learnt into something new.

I'm a bit dubious about the "tell me about something you worked on" question. Firstly, because it requires the candidate to have worked on something chewy, and there are lots of capable people out there who are unfortunate enough to have had crummy jobs where they don't get to do that. Secondly, because it attempts to evaluate the judgement of an individual by looking at the work of a team. Too often, as a candidate, i've had to answer "why did you do it that way?" with "because the client specifically asked for it" or "because my colleagues who were working on it at the time decided so", which isn't useful for me or the interviewer.

[1] http://wiki.c2.com/?StridingAcrossSteppingStones

[2] https://en.wikipedia.org/wiki/K-anonymity

But an easy comeback from the interviewer would have been "What other ways could you have done it? What are the advantages and/or disadvantages compared to the way the client or your colleagues mandated?"

True. But now you're talking about ideas, rather than about experience, so you're testing something a bit different.

The best way to memorise hundreds of different algorithms (or anything else for that matter) is to understand the few underlying principles beneath them. I would be surprised if he knew them all and couldn't come up with intelligent ways of mixing them for achieving a new task.

The best way sure, not the only or even most popular way though.

> Instead, writing good software requires the ability to maintain a system, to debug problems, and to give constructive code review. That's it.

What do you mean by "maintain a system"?

I guess I need to elaborate, since I am getting down voted.

I have only heard of maintaining systems in contexts where it means keeping a system running. I don't see what that has to do with the ability to WRITE software (good or otherwise). Hence, my question.

Bit late to the party but this is a valid question. There's a lot of focus on writing the code, but the system includes the non code components. Can the developer keep the code relevant to the organisation.

Does your company have current openings? I think I can prove myself better in your metrics.

We do, check out MediaMath. We will ask you design, debug and like the questions. Well also do a take hone problem.

Speak the truth. I'd hire you again, man. <3

Yeah and you'd be the first guy I'd think of in an early stage start up. You're a gets shit done kind of guy.

Thank you!

Reply on news.ycombinator.com