Hacker News Reader

> There's a significant backlash at least in the startup space to "whiteboard coding"

Good.

Whiteboard coding is probably one of the least useful methods I have ever seen to evaluate candidates. It tells me nothing about the persons actual qualification and can be gamed.

While I agree that it won't tell you if a candidate is good, it will often show very quickly that a candidate is absolutely terrible.

My warm-up questions are usually something like "reverse a singly-linked-list" or "check if a string is a palindrome", and you would be surprised at how many people have just no clue on how to do it, even with a lot of help (and I work in a FAANG so we should be getting decent candidates).

Don't hire me, this version cons a lot )): (defun palindrome(str) (string= str (coerce (reverse (coerce str 'list)) 'string))

I would ask you to implement reverse and coerce yourself.

I haven't worked with a linked list since first or second year university, more than 10 years ago, nor have I had much of a reason to do character by character string analysis.

I could probably work these problems out, but I might not seem too confident about it.

It’s a basic data structure. I have been able to pass these questions without a formal University education just on logic alone. It’s just basic usage of objects in the case of a JavaScript implementation.

20 years of software development, I don't remember the last time that I actually encountered a linked list in the wild.

> It’s just basic usage of objects in the case of a JavaScript implementation.

Just because you would make a linked list via objects doesn't mean that anyone would actually do it.

> I don't remember the last time that I actually encountered a linked list in the wild

Probably many times a day actually, whenever you use an ArrayList or the equivalent in the language of your choice.

>I have been able to pass these questions without a formal University education just on logic alone.

So you'd be great for a job whose task is doing coding interviews then!

I'm fine with providing a basic Node class for the linked-list if they struggle to start, but that's it. With that anybody should be able to figure it out, no matter how long ago were their classes on that (or if they had any).

> My warm-up questions are usually something like "reverse a singly-linked-list" or "check if a string is a palindrome", and you would be surprised at how many people have just no clue on how to do it,

I don’t know how to do it. I would need dictionary.com to find out what a palindrome means and stackoverflow for the rest, but I’ve used and evaluated five different JavaScript frameworks in building full scale web apps. Would you hire me?

An interview is not a quiz. You're allowed to ask clarifying questions. I'm sure most interviewers won't discount you for being unfamiliar with a fairly obscure word.

Needing stackoverflow to check for palindrome-ness would probably be a bigger problem though. Of course during your day-to-day you'll be allowed to google all sorts of things, but checking if something is a palindrome is so basic that all google could possibly provide you is the exact answer to the question.

That's exactly the point and in response to the sibling comment as well - using StackOverFlow to find solutions to simple problems is the smart thing to do. Developers on SO compete for the best solutions. You're job as a developer is to curate and pick up new modern day conventions in doing so. The reason I don't waste time on reversing a palindrome is because frankly I'd rather spend time doing more important things for my products, and because its such a fundamental knowledge then how to reverse a palindrome is an answer that is available as fast as my brain could think about it. There are more important and more interesting problems to solve.

I would explain you and give you an example of what a palindrome is.

And if you need stackoverflow to reverse a linked list, no, I would not hire you.

Many people have used many technologies. I started programming when I was 12, and I had no idea of what I was doing beyond copy-pasting code from tutorials and putting them together, but if "how many technologies did this dude work with" is your criteria, you would have hired 12 years old me.

> My warm-up questions are usually something like "reverse a singly-linked-list" or "check if a string is a palindrome"

I've written sites, apps, ORMs, enterprise tools, code generators, FAAS platforms from scratch, exporters for DOCX and EPUB, etc etc for decades. I've been junior, mid, senior, lead of two teams. I've transitioned companies to cloud, created data warehouses, built BI universes. All sorts of stuff over the years.

Sounds like your hiring techniques would pass on me, as those whiteboard exercises would have me saying no thanks and ending the interview. Utterly pointless.

(and FYI that's from experience on both sides of the table as I've also been the recruiter interviewing from junior devs to team leads)

Those are pretty basic algorithmic questions, even if somebody's never heard of a linked list or a palindrome, anyone with even a minimal understanding of algorithms should be able to describe in pseudo code how to solve them.

They're not guaranteeing that an applicant is necessarily right for the job, but they do separate the chaff from the wheat proverbially speaking.

> they do separate the chaff from the wheat

This is where we differ. What they separate isn’t chaff from wheat, but those who can do a specific type of interview from those who can’t. The latter aren’t chaff and the former aren’t wheat.

The only time these kinds of questions/tasks are suitable is if they genuinely represent the work being hired for.

Our opinions on this differ, and that’s fine, so whatever works for you.

This is the problem with this interviews and FANGs shit. They separate nothing. But because ppl in these companies did this doing interviews, and they have such a fucking high opinnion of themselves, they think the only good people are the ones that are like them. `I can do this and I'm the greatest (their own opinion reinforced by other idiots in the company) so anyone that can't aren't worthy of my time/welcomed here`.

But then you work with these idiots that can reverse a linked list in other companies and they can't organize code to save their lives. They use patterns and shit they used in facebook everywhere, even when they shouldn't because they always so smart and right.

(yes, after cleaning up code for shitty ex facebookers and ex netflixers, my opinion of the 'wheat' boils down to they may be wheat, but they infested with parasites and bugs and rotten at the core, but hey, what do I know, just been doing sw development for 25+ years, published author and worked on stuff that most here use daily, I'm just chaf because I don't want to work for FANGs)

> those whiteboard exercises would have me saying no thanks and ending the interview

Then I saved 45 minutes of my life, great. The point is, if you want to join the company I work for (and many people want to), you have to jump through the hoops of this company.

You should re-read the start of my comment, because I don't think those whiteboard questions are a great way to hire people. I just don't think there's a way that's more respectful of the candidate while being time efficient and providing good data points.

The truth is that the achievements that you claim can have been done by others. I'm in a top 1% company, and yet I see many people that are just utterly shit at being software engineers. There are parasites like this everywhere and they can just coast and claim the achievements of others for themselves (especially when applying to another company that has no way to verify their claims), so whiteboarding exercises and others crap is 100% necessary, no matter your level.

Totally get that you can't just believe the claims. I just disagree that whiteboards are in any way a good solution.

But fair enough, if it works for you it works for you.

FAANG recruiters usually prep you for the interview so that’s kind of crazy so many fail.

On the other hand, usage of linked lists in the wild can be rather limited outside c/c++. Only languages I’ve used them a lot and then only when I was teaching algorithms and data structures.

I think I used a linked list for a MRU list in a menu someplace ages ago in c# winforms app.

> On the other hand, usage of linked lists in the wild can be rather limited

You use linked lists in pretty much all languages, they're just hidden behind the flavor that you prefer, List in C#, LinkedList or ArrayList in Java, etc.

> it will often show very quickly that a candidate is absolutely terrible.

It CAN show that.

Problem is; even a terrible candidate can prepare, knowing the kinds of things that will likely be tested, by memorizing the solutions to these very specific problems.

“I think I’d respect your opinion more, if you could write some code to evaluate all possible tic tac toe games in c++ on that whiteboard over there in around 45 minutes. Sound ok?” - whiteboard hiring managers probably

You're not wrong. I mentor some juniors and the ability to talk to a specific target audience about a topic is the most important skill a dev can have. I can teach you the tech stack, but i cant teach you how to talk to the business people or the finance department. "I need budget to rewrite that app in rust" will get you a no from the finance guys most of the time. Tell them that it would reduce your current infrastructure cost by 10% (or whatever you want to achieve) and they might say yes.

> I mentor some juniors and the ability to talk to a specific target audience about a topic is the most important skill a dev can have.

Sure, it comes with experience and lessons learnt. But, I don't think a junior dev would straight talk to finance guys for money. They would have support from his own tribe in some form (PM/Manager/Director). Nonetheless, you are making a good point. In sprint demos, I make sure my team members do not bring up any tech jargon.

finance was just a example. replace it with the stakeholder, the PM of another team or an external partner.

> In sprint demos, I make sure my team members do not bring up any tech jargon

thats exactly what i mean. the audience does not care about the tech, they care that their problems are solved and money is made.

I wonder if it works that way in other fields.

Do the suits at Boeing get upset that the engineer they hired keeps talking about things like thrust, lift and control surfaces instead of what EBITDA will be this quarter? Actually maybe... That might be the reason airplanes are throwing themselves at the ground and why all your personal information is now public knowledge.

That culture has definitely taken root in some ways, but I wouldn't count on it during a downturn. The idea is what will the hiring/candidate pools look like in a tech recession, so a premise is that many people who can presently get an engineering job then cannot. There are so many software programming jobs right now that the market created bootcamps to fill the demand, but it's not like mature engineers necessarily have fewer interpersonal skills, and suddenly there are many more of them all trying to get jobs.

We are in the middle of interviewing for our first ever intake of graduates/juniors and this describes what we are looking for to a T. We are far more interested in problem solving, reasoning about systems and constraints, and an ability to work well with others, and most importantly a strong desire to learn new stuff. We will have a small code related test, but it's short and relatively simple but of but fixing/changing existing code.

"Brush up on CS fundamentals" means "grind leetcode" which is already table stakes for getting a job, and about to become more important. In a recession, companies will crack down on candidates with interpersonal skills and confidence but no competence.

Interpersonal skills and confidence are deciding factors after you've filtered out the candidates with low technical skill, as determined by leetcode, whiteboard, online coding exercises, etc.

Once again, I've seen enough candidates talk the talk, and then get caught typing in answers verbatim from Google or SO, to know that eliminating coding exercises in the interview process is folly -- it's opening the door for bad hires who can't code and who waste everyone's time.

Honestly to me the most important piece is the willingness and ability to try new things and work under certainty. I have seen first hand time and time again that it is easier for someone who is good at this to learn how to code when the rubber hits the road than it is for someone who knows how to code but isn't comfortable learning on the fly to learn a new python library fast enough to work with the team.

On a super short timescale with no testing feedback loop, 99% of "algorithms" questions are "Have you encountered this thing before" shit tests in practice, rather than meaningful tests of problem-solving skills, and do not effectively test whether someone will be effective. This is to me a classic Goodhart's Law + policy problem: One can easily assess the answer to an algorithm problem, so it's popular as an assessment and becomes pervasive. Goodhart's Law predicts the next part

Some startups are still requiring weird whiteboard questions sadly. Interviewed for a role recently and was asked to navigate a maze of obstacles and teleports with possible infinite loops, saying the minimum number of steps to leave the maze if it’s possible. That was for a test engineering role so… WTF.

I assume they wanted more than a DFS or BFS or similar with loop detection? The teleports sound like a fun twist, although I'm not sure they change that much since from a graph perspective presumably they're just another edge?

Yeah, but does that kind of problem really exist on a regular basis for a test engineer on that team? I doubt it.

It's probably not that relevant to the job, but as far as weird questions go it's not too bad. It's presumably not leetcode hard, basically.

Actually it was literally a hard leetcode question! The other 3 were 2 medium and 1 easy. I can work out easy and medium leetcode answers from first principles in an interview setting, usually. I can't with hard ones tbh.

But ultimately it seems very divorced from reality of what I do, which is TestOps (building out CI pipelines, reporting, test infra, etc...).

Simple BFS from the starting position should do the trick.

They wanted to know if you can traverse a graph, which is something pretty simple.

I don't see a need for outrage here.

I'm sure it's simple if you know it! But having not taking an algorithm class before, and having completed three other Algorithm questions within the 90 min total allotted time, I crashed pretty hard. I solved it afterwards when I had time to really think, but didn't know it off the top of my head.

> try stuff you don't already know how to do

I've seen this used as justification for implementation of shiny third-party things that were both a fundamentally unfit solution and permitted those pushing it to avoid understanding the root cause of their current problems.

There’s a fine line, but I don’t think that is what GP is talking about. Chasing the new shiny unnecessarily vs learning a new tool when required/necessary. Plenty of people do the former, and plenty of people also resist the latter (vehemently so, in many cases).

I see this more of the quality where you can dive into something you don’t already know how to do with confidence that you can come out the other side.

A lot of people are just really scared of what they don’t know, and don’t even give themselves a chance to self-teach or expand their skills