Live data from Hacker News

Code Interviews

alaiacano.github.io

41–50 of 98 posts

Re: Code Interviews

#41
post #39
post #32

Earlier quoted context omitted.

You are proving exactly why we need a standardized way to judge whether a candidate is hirable. All the candidates I see have almost zero history of contributing to OSS or maintaining side projects. Their work history usually consists of some run of the mill experience. I have to rely on that and absolutely do not expect them to have a green GitHub. I would hate for that to become the norm. That is why we need to asc…

this is exactly the issue - if you cannot take a moment to look at a candidate’s work but can waste 10 hours in leetcode zoom bullshit calls your system is broken, sorry

People making non-trivial contributions to open source projects or coding in their free time are an exception. Most candidates (>99%) have no work you could actually look at.

Re: Code Interviews

#42

I won't bother with coding interviews. I consider them to be "hazing rituals"; not actual qualification assessment. I am very, very fortunate, in that I don't have to deal with them. I am not looking for work, and plan to never look for work, ever again. I have a giant portfolio[0]. It has links to 40 or so repos, with tens of thousands of lines of code, spanning decades. Just about every project can be cloned, built…

On the flip side, an interview where you're doing relevant work with another engineer is a way to evaluate whether you're a decent person to work with. I've hard-passed on candidates with immaculate resumes and huge open source portfolios because they were rude and insufferable. When you're hiring, you're building a team, you're not hiring individuals who work in isolation.

In a previous life, I was forced to work under a very senior engineer who was/is a well-known thought leader with a handful of books published. His leadership was nothing short of abysmal: he had no people skills, answering questions with links to e-books he'd written for O'Reilly in lieu of responses. The best engineers got tired of being micromanaged and nit-picked and left. It doesn't matter how smart you are if the other people at the company hate working with you.

There are many coding interview objectives (and I won't defend interviews which try really hard to ensure you know how to code) but pair programming and systems design questions are absolutely necessary to understand whether the person you're hiring isn't just qualified, but rather the kind of person who will make the team better overall.

Re: Code Interviews

#43
post #41
post #39

Earlier quoted context omitted.

this is exactly the issue - if you cannot take a moment to look at a candidate’s work but can waste 10 hours in leetcode zoom bullshit calls your system is broken, sorry

People making non-trivial contributions to open source projects or coding in their free time are an exception. Most candidates (>99%) have no work you could actually look at.

that’s too bad then. anyone can work on a simple project. how about a simple CRUD app for kitchen recipes?

Re: Code Interviews

#44
post #41
post #39

Earlier quoted context omitted.

this is exactly the issue - if you cannot take a moment to look at a candidate’s work but can waste 10 hours in leetcode zoom bullshit calls your system is broken, sorry

People making non-trivial contributions to open source projects or coding in their free time are an exception. Most candidates (>99%) have no work you could actually look at.

> Most candidates (>99%) have no work you could actually look at.

Most inexperienced candidates...

One of my favorite pastimes, is following up on GitHub, with people from this joint, or others, that pique my interest.

There's a lot of really awesome stuff out there! You guys rock!

Of course, many of these folks, are...chronologically challenged, let's say. If you've already decided that you will only be hiring folks right out of school, then I can see the problem.

And...to answer the inevitable "You're likely an insufferable bastard" canard, that the conversation ends up at, after we've worked through the other things, I have a LinkedIn profile, packed with testimonials, from managers, former employees, and project partners.

Turns out, I'm actually a really decent human being, and play well with others.

I also worked for decades, for a Japanese company. You won't last long at a Japanese company, if you don't "team" well.

Re: Code Interviews

#45
The problem is that however distasteful or lacking the current situation is, it’s been adopted by most large companies and is seen as standard now so nobody has any incentive to improve it and it self perpetuates akin to hazing rituals at fraternities . Google got us into the current mess with their claim to have found the only difference between good performance and bad performance at Google was the ability to do algorithmic problems. If only they published that research! Before Google was Microsoft. The only thing that would incentivize employers to change now would be engineers refusing these interviews en masse or a small company becoming an influentially big one that has a different hiring scheme altogether.

Re: Code Interviews

#46
Agree that 99% of the leetcode interviews are divorced from everyday coding work.

However, this article goes in the wrong direction in trying to keep the LinkedList premise - how often do programmers see a raw linkedlist anyways?

Directly ask coding questions from your everyday work, and skip the linkedlist stuff as 3rd level detail questions; the signal that the candidate can do the job is much higher then. Ex: here’s an API and it’s json response: write some code to parse it. Add extensions like paging, network failures, etc. Let the candidate google everything, and if your question is good, it can’t be copypasta from StackOverflow.

Re: Code Interviews

#47

Earlier quoted context omitted.

“He actually did well” - how would he know that? He also wasn’t hired.

It's possible they told him but given that he admits he didn't know what a binary tree is it seems unlikely he did well at a Google coding interview, where I assume 90% of people know. > But ultimately, should Google have hired me? Yes, absolutely yes. I am often a dick, I am often difficult, I often don’t know computer science, but. BUT. I make really good things, maybe they aren't perfect, but people really like th…

MacPorts is Mac focused. People liked Homebrew because it didn't take lots of time compiling its own copies of libraries the OS had already. But MacPorts got binary packages. And Homebrew gave up using OS libraries.

Re: Code Interviews

#48
post #35

Max Howell's tweet gets pasted on every article talking about code interviews as some kind of exemplification of the problem of whiteboard/algorithmic interviews. What some people might not know is that he reflected on that tweet two years later (3 years ago), in this Quora question: https://www.quora.com/Whats-the-logic-behind-Google-rejectin... He even explains how he actually did well in the software engineering i…

The tweet comes up every so often, but it has two problems: (1) Most of Google's engineers didn't even know Homebrew - it just wasn't something Google used on its notebooks. (2) There's no such thing as "inverting a binary tree." At least I haven't heard about it anywhere else. Maybe Google's interview process is broken, but the tweet isn't really explaining much. It's just a nice soundbite.

Knowing Homebrew could have given them reasons not to hire him. He made bad engineering decisions and brushed off feedback. And even he said he's a dick.

Re: Code Interviews

#49
post #46

Agree that 99% of the leetcode interviews are divorced from everyday coding work. However, this article goes in the wrong direction in trying to keep the LinkedList premise - how often do programmers see a raw linkedlist anyways? Directly ask coding questions from your everyday work, and skip the linkedlist stuff as 3rd level detail questions; the signal that the candidate can do the job is much higher then. Ex: here…

that sounds like a takehome and should be paid for.

Re: Code Interviews

#50
> There are a few questions that people like to use as punching bags. Invert a binary tree. Reverse a linked list. Perform breadth-first and/or depth-first tree traversals. Anything to do with heaps.

None of these are hard. Should be pretty much covered by any good algorithm class.

Post reply on HN