Hacker News Reader

> One is "do you know what's going on under the hood?" On another post I just saw a comment in which someone advocated counting the number of occurrences of something in a list by filtering it and then getting the length of the result. This is almost certainly a terrible solution as it allocates memory (which has to be freed) in what can be done in a single quick pass. By asking you such a question the interviewer can learn if you have some idea of the tradeoffs and why something might be a good or bad idea.

> These are the kinds of decisions that can have order of magnitude impacts on runtime, which can have huge impact on the company's costs.

Then the questions should be more like: What data structure, library, method, steps, would you use to solve this problem and why. What are the tradeoffs of your choices, etc?

All of this can be answered in fairly high level pseudocode too and still show that they understand the concepts etc.

> Sure, those statements (just use an existing library) are what you'll do in practice especially as a beginner

The more code you write, the more you have to maintain. Sure, of course there are times where you need to re-implement something from scratch. But those times are rare (or should be). Making something from scratch without strong justification is a strong signal, just not a positive one.

Now, as you point out, "when would you write x from scratch" is a great question to ask someone. I am vary wary of people that are willing to overspend innovation tokens. But thats a design/systems/culture question, not a coding question.

the signal I want from a coding test is the following:

o Can they demonstrate and understanding of the programming language?

o Do they create readable code?

o Do they ask questions?

o Do they follow the style of the programme they are modifying?

o Do they say "I don't know"?

o Do they push back on weird or silly requirements?

all of those things make working with someone much easier. None of those questions require "implement algorithm that only exist in Computer Science courses". They can all be answered by something like:

"here is a program that fetches a json document, but it breaks often, please make it more reliable"

That is far more realistic, and more likely to what they'll be doing.

The dirty little secret about most coding jobs is that actually, the important thing is getting something functional and stable for the business, so it can make money. Then after that its responding to feature/bug requests. As a programmer, your job is to convert business logic into computer logic. 99% of the time, this doesn't mean making artisan libraries that improve some tiny metric by 20x.

> o Do they ask questions?

I find I get 90% of the insight from simple questions like "write a function to shuffle a deck of cards. Don't worry about simple typos like forgetting a semicolon."

You learn a lot from how they set things up (make a suit class, and a vector of card classes? Or just use the integers 1-52?) and talking about that. Do they think about the problem (and, as you say, ask a couple of "requirement" questions) before diving in?

One of the best hires I remember was someone who got this problem wrong (went to a lot of work to leave the deck unshuffled). We gently asked if it did what was required. Hi smacked himself on the forehead and said, "I'm a fucking idiot" (in front of us in his interview!) and quickly corrected the bug. Great guy.

If you ask me a question that boils down to “write a card shuffling algorithm”, I’m going to do less well because I’m being taxed by the thought of “Why is this person asking me to shuffle a deck of virtual cards?” During the interview, I’d probably just google “best algorithm for shuffling deck of cards in <language>”, and I’d tell you I was looking it up. If you tasked me with shuffling cards on the job, that’s what I’d do.

You could just ask, and we'd answer "it's just a simple problem so both of us can see what it's like to work together." You'd be surprised how many people show up who don't actually know how to write a for loop.

And if you didn't like the experience you wouldn't want to work for us so the interview would be a success too.

> don't actually know how to write a for loop

My god, yes. We had a two-part problem that we used for the "work skills" part of the interview. Part 1 boiled down to writing a two-level nested for loop that was simpler than fizzbuzz. Part 2 was using that loop to solve the rest of the problem, which was far more complex. I lost track of how many candidates spent 40 of the 50 minutes just writing that loop.

Come up with better problems, please.

What would you recommend?

you don't actually believe that "work together" crap do you? You realize you're dangling a job over their head, right? There is a power imbalance. You'll never see "work together" in an interview because you're not colleagues on equal footing.

Often candidates already have a job and are looking to see if they want a change. There's parity in such situations.

I’m not sure that’s a great interview question; the right answer to google the appropriate algorithm (e.g. Fisher–Yates), make sure you understand implementation errors that will lead to bias, and implement it over any arbitrary sequence.

> The more code you write, the more you have to maintain. Sure, of course there are times where you need to re-implement something from scratch. But those times are rare (or should be). Making something from scratch without strong justification is a strong signal, just not a positive one.

It really depends on what you're working on. A package to manage a dentist's office should be as off the shelf as possible. I don't care about I/O and try to do as little as possible, using whatever's off the shelf, but my HFT buddies are bumming the hell out of it, customizing the kernel, and whatnot. You may use elastic search to save you time and money, but the folks working on it have probably run over it so much there's nothing but custom code left.

It's all context.

Yep I absolutely agree with this.

I’ve spent about the last year optimising text CRDTs so they’re actually usable in practice. A few years ago, 800mb of ram usage and 5 minutes processing was common to open a document. Now we’re talking 2mb of ram and 20ms. That is the difference between something not being viable and something being usable everywhere. And yes: my code involved a lot of custom data structures and algorithms. There were no libraries in cargo which did exactly what I needed.

This thread is full of people bemoaning “leetcode problems” for being irrelevant in software jobs. But I use them all the time in my work. Software engineering is far more varied than any of our individual careers.

I'm happy for you that you've found a job where the things Leetcode emphasizes has merit and importance and value in your day to day work.

Everyone who's on the other side of the Leetcode debate from you wants the exact same thing - an interview process that is representative of the actual day-to-day work.

As a Web developer, inverting a binary tree is not a thing an employer has ever asked me to do.

Yes. You, me and the GP commenter seem to all be vigorously agreeing with one another. Job interviews should be based on what the role entails. If that includes data structures and algorithms, so be it. If not, leave them out!

As the GP commenter said:

> It really depends on what you're working on. ... It's all context.

I brought it up because many (most) commenters in this thread seem to be claiming that this knowledge and skill is never useful. That its ridiculous to ask about this stuff in any job interviews, except as a ritualistic hazing ritual. This is also absurd.

> As a Web developer, inverting a binary tree is not a thing an employer has ever asked me to do.

I've never had an employer name any data structures explicitly. Its our job as the software experts to know which tools and technologies are relevant. But with that said, I can't remember ever using custom data structures in frontend website code either. If I were hiring a web developer, there are so many things I'd rather spend time talking about in an interview. (HTML & CSS knowledge, web frameworks, design skills, raw programming skill, etc.)

> many (most) commenters in this thread seem to be claiming that this knowledge and skill is never useful.

Those commenters are making generalizations because many (most) jobs in the industry do not find that knowledge and skill useful. Certainly specialized edge positions exist.

I believe Google at least at that time was trying to hire engineers who could theoretically be put to work on any team, potentially being asked to create TensorFlow or MapReduce or contributing to the Linux kernel in service of Android, not people who have pigeonholed themselves into only being considered web developers.

If pure CRUD companies only looking for JavaScript specialists are also using leetcode screening, they're missing the point.

Here's the difference: I bet you had time to think through the novel problems and didn't have someone hovering over your shoulder, demanding you come up with solutions within 20 - 30 minutes -or else-.

> Sure, those statements (just use an existing library) are what you'll do in practice especially as a beginner.

I think it's really not about "beginner" vs. "expert", but moreso about the specificity of your role. If you're tasked with making general cloud services, it's probably fine. As your role gets closer to core systems/algorithms engineering, obviously that changes.

> But there is value in asking these kinds of questions.

There is value knowing, but the dynamic of an interview make things like this harder to ask/harder to answer.

> One is "do you know what's going on under the hood?" On another post I just saw a comment in which someone advocated counting the number of occurrences of something in a list by filtering it and then getting the length of the result. This is almost certainly a terrible solution as it allocates memory (which has to be freed) in what can be done in a single quick pass.

In the real world the validity of this solution depends on its input and use. Also in the real world, especially if you're not on one of the above-mentioned specialist teams, it's usually more important to be readable and maintainable instead of just purely performance oriented. So a single pass solution that's harder to grasp at a glance becomes less desirable than multiple passes as long as your performance requirements can afford it.

> By asking you such a question the interviewer can learn if you have some idea of the tradeoffs and why something might be a good or bad idea.

Totally, but the issue becomes "Can you figure out an algorithm on a whiteboard", instead of the (as you've already agreed) correct path of "Can you work through tradeoffs of one implementation vs. another". I think this question could pretty easily be presented in a way that isn't a quiz and also allows the programmer to demonstrate their problemsolving ability without seeming adversarial.

> One is "do you know what's going on under the hood?"

Why should I need to? Let's take Microsoft's .Net sort implemtation.

It will intelligently determine which is the optimized sort given the conditions it's facing.

Heapsort? Mergesort? Quicksort? Radix Sort.

And the most-possibility optimized versions of each.

This is what data scientists do. We don't need programmers standing at whiteboards writting BubbleShort and being told it's wrong. In the real world, you call .Sort() and get on with real work.

Sure, you can hand-roll your own sort for hot-path cases but that's likely been taken into account anyway!

Uh oh. You realize you just stated you actually know sorting algorithms and even know enough to be able to decide to roll your own if needed?