Hacker News Reader

Comment by friedman23 | Hacker News Reader

> Stop accepting shitty interviews

Why should I stop? My personal experience is that many of the best companies to work for have shitty interviews. All I need to do is to study a bit and go through a 5 hour interview and I have a cushy high paying job? Sign me up. Complaining about interviews is missing the forest from the trees, I don't spend the majority of my working life interviewing, I spend it working. So if preparing a lot for interviews and getting my ego bruised a little means I get a good job so be it.

View on HN

What a strangely adversarial comment. In my experience, I can gather more information about a candidate's ability in just 15 minutes talking 1 on 1 with them rather than hours of Leetcode busywork. Funneling candidates through an annoying, needlessly rigid, and blatantly time consuming process is not a good thing, and probably leads to perfectly qualified people being denied; a system that optimizes for 'signals' that should not exist in the first place.

To be fair the parent commenter's post doesn't claim that this process is even remotely efficient, only that it's reality and they find it easy to game.

Also more meta-level commentary, I find the word "should" interesting, as in general I have found that comments on HN which contain this word reflect a level of frustration that X is X instead of Y, because "X should be Y". Someone else may come along and say "X should be Z", and all the meanwhile, X is X.

The problem comes when a majority of us agree that X is not fit for purpose as it is, but we still get people saying "X is X, why are we talking about Y and Z?"

What does adversarial mean in this context? That I disagree with the original poster?

> In my experience, I can gather more information about a candidate's ability in just 15 minutes talking 1 on 1 with them rather than hours of Leetcode busywork

This is your perspective as someone doing hiring. My perspective is from someone being hired. I really don't think leetcode is that difficult all things considered so a system based on leetcode is just not that bad in my opinion. It's really not that difficult, there is a set of 15 or so algorithms that are all 40 or so lines long and you just need to memorize them to the point of instant recall. Now you can get hired almost anywhere.

Even if you're correct about your ability to sniff out talent you don't scale, and you can't be implemented by someone with eight hours of training, or replaced by automated testing, or a pencil and paper test. Legible processes that are known to work to within some tolerance are great for large organisations.

If you can tell if someone's good within fifteen minutes of talking to them you should be able to get rich by setting up a software consulting company or startup with other people's false negative rejects. That's equivalent to being able to take mine tailings and spit out gold.

Aren't these shitty interview processes just gates and proxies for commitment and a dark pattern per se? If someone is willing to do the work and endure the shitty process to get the job then they must be committed to get the job and will likely be committed to keep the job.

That commitment can be exploited.

It's like Nigerian Prince scams, those willing to jump through the hoops are more easily to convince and get jumping through future hoops.

It's also likely they will rationalize that their job is great because they had to do all this shit to get it. The employer could think "if we can get their foot in the door and convince them to fully enter the room even though we make it difficult to fully open the door, they're less likely to leave and more likely to fight to stay in the room." It keeps uncommitted folks out, but doesn't necessarily filter for competent people, just committed people.

Cognitive dissonance is a powerful thing.

So in those 15 minutes, how do you know this person is able to write good code? How do you know they are not just riding on the success of their former colleagues, and bullshitting you with high level responses they heard their colleages talk about?

How many people did you interview and hire?

Just asking since I interview and hire a lot of people, and find it very hard to asses someones capabilities.

That question works both ways:

In those few LC questions, how do I know the person can write good, maintainable, reliable software with a team of engineers and didn't just learn for the test?

Yes, interviews are hard. Assessing a persons capabilities is a difficult job.

> In my experience, I can gather more information about a candidate's ability in just 15 minutes talking 1 on 1 with them rather than hours of Leetcode busywork.

You think you can gather more information. I doubt that your decision is more accurate than leetcode interviews on average.

I've done over 800 interviews, and I call bullshit on this.

I've spent 30min talking to candidates about their projects, experience, tech they used, choices made, etc. and been super excited and positive about them.

Then I ask them to find the intersection of two lists in better than O(n^2) and they completely fail to write functional code in their preferred language in the next 30 minutes. This isn't even "leetcode" level of challenge.

If I'm hiring you to be a professional software engineer for 6 figures income to spend 8-10 hours a day designing, writing, and debugging code, you need to be able to write code.

The disparity between the conversation and the coding performance can be significant, and both need to be evaluated.

If there's a better way to evaluate if someone can write code, I'm open to try it. But take home tests, portfolios, pair-programming, "a day in the life", etc. all have their problems and disadvantage different groups.

I don't see anything adversarial, it is just someone describing how they play the interview game.

There's a whole leetcode culture on sites like teamblind.com. A lot of people are happy to play the game.

Not my cup of tea either, but to each their own.

I get your point, but if every good/senior developer stopped accepting "shitty interviews" the companies would be forced to change their methods and you would be surrounded by better engineers instead of people who studied a bit to go through a 5 hour interview.

Exactly. Nothing is more valuable than a coworker who can implement a half-ass hashtable with a linked list even though there are state-of-the-art implementations available in nearly every programming language.

I’ve got a sickness, and the only prescription is more bloom filters, baby

Depends on where you sit, I'd take a half assed hash table if it consumes 1/10th of memory and code space of a reference library implementation.

Embedded space sadly suffers from a dearth of good implementations for different parameters than CPU cycles.

You venn diagram of engineering talent has good engineers in the side that don't understand the value proposition I posted above? It feels silly saying this but the idea that people working at these tech companies are shitty programmers that only know competitive programming is wrong.

Engineering skill is orthogonal to willingness to put oneself through meaningless bullshit to get a job.

> people who studied a bit

Most of the population couldn't do 200 leetcode problems if they were given two months full time one on one tuition and told they'd get $100,000 in cash at the end. That would probably hold true even if you restricted it to college graduates and definitely would for high school graduates. Most people are really, really bad at mathematical thinking. It's more than just a bit of study.

>Most of the population couldn't do 200 leetcode problems

Most of the population are not programmers.

For someone who already knows a PL or 2, the picture is very different: There are maybe 32-50 questions that get repeated in almost every "code puzzle"-style interview. Which ones these are is actively monitored and curated in several communities.

A person intelligent enough to know a PL, can simply memorize these questions. "Learning for the test" is a standard, and successful, strategy to game predictable test environments. We see it in educational systems using standardized multiple choice tests, why would it be different in bad code interviews?

I was asked the stupid implement a calculator question at least five times.

Lol, given this market, by the time they solved 40 they'd be ready to get a 50K hiring bonus and 300K a year job at the FAANG. You need to offer 500K or more to even motivate someone to solve 200 leetcodes.

In my experience, a broken HR indicates a broken organization. Yes, you can hunker down and focus on your field and move on in a while but I can’t, usually.

As to shitty interviews. I was approached by Google for a non-programmer role a few years back. Failed the coding part as I’ve not been a professional programmer for a 20 years, despite being able to write all the code that I need for my research. Was told they’d be in touch for a development program as I’d apparently aced the rest of the interview. Never heard anything. Was approached again after a while and I agreed under the condition that there was no coding interview - I knew I had failed that and was going to fail again. Was assured there’d be no coding interview. Only to have one scheduled immediately.

So an organization that manages what’s probably the largest information system on the planet cannot for the love of their life implement a simple sales lead process? Why? Because they fundamentally do not care about you.

Yes, if you know the job is good go for it, it's a minor hurdle

Otherwise you might not just bother, because it's usually a reflection of what the company values and how it thinks

Funny enough, I was looking for jobs relatively recently and decided to apply to cruise but didn't bother because they wanted a cover letter.

Yes, it’s easy to forget we are in of the highest paying industry. But yeah interviews should skip some redtape and HR bs.

Still, it's not like any other field of engineering has something equivalent to leetcode. You don't make someone with a civil engineering degree and a resume of bridge building go up to a whiteboard and work out an irrelevant physics problem like it's undergrad again. You don't have an M.D. talk you through a hypothetical surgery. Only in computer science is there this metagame that you have to dedicate unpaid time toward, yet is hardly ever relevant to the tasks outlined in the job description. I feel like it's been pushed onto recruiters by companies that specialize in creating this crap like most other Enterprise software sold to HR teams, and now there is this expectation that this is how you are supposed to do these interviews because it's been going on for years now. Snake oil salesmen and lemmings in HR brought this upon us, not technical leadership demanding competency.

Civil Engineers and Doctors have professional boards that certify they meet a minimum level of competency.

I've done an EE "leetcode" phone interview with a non-technical HR person asking scripted problems. Didn't get to a real interview, then they foolishly called me back a year later where I just told them not again. This is for a company in the hinterlands of Oregon where you're making a sacrifice to work for the only viable employer in the area.

Is this Intel? The people of Hillsboro would resent you referring to their Portland suburb as "the hinterlands of Oregon"

And other fields of engineering don’t pay nearly as well.

I’d choose a much higher pay over a reasonable interview.

Reply on news.ycombinator.com