Hacker News Reader

Comment by strict9 | Hacker News Reader

I think this phenomena is at least partly responsible for why so many devs stay in the same position and why they are difficult to find/hire.

Before a tech interview, good candidates will spend a large amount of time doing 'homework' which is just practicing answering the asinine questions that tech interviewers give that is usually barely relevant to the position, if at all.

Equally, if not more important, is the candidate's experience or ability to navigate legacy code, testing philosophy, handling incomplete/inconsistent requirements, and attention to detail, among other traits. Of course these won't merit the same attention in an interview.

On the one hand firms have difficulty finding good candidates, on the other hand they are giving ridiculous tech interviews that aren't a great judge of what kind of employee they will be.

View on HN

>>partly responsible for why so many devs stay in the same position

That is why I am staying put for the time being; hate the interview process, hate being asked stupid questions about solving problems that I will never have to solve in real life.

Ask me about projects I have worked on, ask me about code I have developed ask about my experience etc - but I am still looking for the development job where I will be required to solve Hanoi's tower problem....

In fact, for the current job I am in got thru the initial interviews and then was told I needed to take online 'skills assessment' test to move forward - I told the interviewer (nicely) 'forget it, I don't want the job if I have to take the test; if my resume and track record isn't enough then maybe this isn't right for me.' (keeping in mind that I have a 30 year track record, not a recent college grad)

Guess the hiring manager agreed, because they hired me anyway (still haven't taken the test).

I have a very talented SWE friend who only left a now-public unicorn because they were recruited by a former colleague at a startup they knew wouldn't involve leetcode in the interview process.

I have another very talented SWE friend who has been doing leetcode exercises off and on for months and is struggling to start doing applications even though they do not like their current work and are undercompensated.

They fear they will fail algo / data structures and yet this person has an excellent public track record of quality contributions and comms in FOSS.

From what I've observed leetcode screens are problematic enough that they are causing market inefficiency.

> From what I've observed leetcode screens are problematic enough that they are causing market inefficiency.

Totally agreed, I know of many similar situations like this.. however at the same time the question is whether there’s any other system that’s better in practice.

“Capitalism is the worst system, except for all the others” etc.

You want a controlled trial or natural experiment where two large successful software companies experiment with two different approaches to hiring over a number of years holding all other factors equal. That’s hard but may happen at some point in our lifetimes.

leetcode difficulty is vastly exaggerated. people study 4 whole years of their lives in college to increase their chances of making money, why not spend around 5 months on leetcode which can perhaps get you much farther than anything from college?

i'm not particularly smart, in fact i struggle at work routinely, but i know what i have to do clear interviews, so i do the grind and it has worked well for me. (to a certain definition of "well")

now that i think of it, it has only worked well for me because actual talented swe's don't put effort into interviews the way people like me do.

People who are good at the grind are good at the grind. These are also often the people who succeed in life; intelligence is vastly overrated.

I suspect some people want to make time but have family or other obligations.

Adding new project that must be executed on as a prerequisite to being seriously considered for a job when you are obviously capable can be a hard sell.

Especially given programming challenges are not that fun for people used to delivering features.

I know that for talented SWEs, having a leetcode interview sink an interview process it can be invalidating.

Companies that rely on single algo/ds interviews also discourage potentially great employees when they totally ignore evidence of capability.

The company wants candidates to grind ds/algos, but it won't compel its own employees to look at public contributions.

It is possible to ask non-asinine coding questions in interviews, though, and it seems to be a good idea to do so if you want to ensure that you're hiring somebody that can program a computer. Simple five-minute loop-free "write an expression" problems are effective filters.

Interesting interview questions might be

- download this OSS project - explain to me where / how this API works, how deep does the call stack go. What tests exist for it?

- write me the spec for that call. discuss.

Why would you ask someone to do something absolutely trivial?

Why is it trivial to take a unfamiliar code base and dive into it, hunting down calls, working through the stack to understand what / how a particular function works. This is a hugely important part of familiarising oneself with a codebase - it leads to many useful discussions. Who should you talk to if there is problem in a function halfway down. If I want to add a parameter to the top function, what might have to change down the stack?

I am not sure why thats trivial

You could see it as a modern FizzBuzz. Many candidates will fail at such a triviality.

This is the #1 cause for me staying in my current position that I hate.

Reply on news.ycombinator.com