Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stop Interviewing with Leet Code

fev.al

Post reply on HN
Print view View original

481–490 of 675 posts

Re: Stop Interviewing with Leet Code

#481

Post by dekhn »

cadr wrote: post #408
dekhn wrote: post #397

Earlier quoted context omitted.

To be honest? every programmer needs to be able to pass FizzBuzz. Beyond that, I add some more basic work around byte representations of data (I have 4 symbols... how many bits do I need to encode a symbol?). I will typpically also include one major bug in a piece of code and ask the user to identify it (with hints). I once interviewed a guy- a CTO at a biotech- and he wouldn't answer the question "I have a million D…

I agree liking to ask simpler stuff first. But what about this more complicated stuff? My problem is that when we talk about stuff having more "signal" - how are we determining if those questions are giving us more signal?

My question is fairly open and allows me to continue asking significantly more complicated questions. So far, nobody has (for example) asked enough clarifying questions to determine that a bloom counting filter could potentially solve the problem- most people just store ASCII string keys in a hash table, which wastes tons of memory and requires a lookup for every string.

So usually I end up after 45 minutes finding that the candidate has more or less tapped themselves out at "make a hash table of string keys, use it to store counts" (OK for a very junior programmer) or "make a perfect minimal hash" (I help them get there if they don't know what those are) or "use a probabilistic counting filter". This is about all I need to make a determination.

Re: Stop Interviewing with Leet Code

#482

Post by smilekzs »

goodpoint wrote: post #121
Dowwie wrote: post #75

Someone who builds a truly novel technology solution involving hundreds of hours of effort gets filtered out of an interview involving contrived scenarios. You may have built the next generation X, but given an array of strings and a fixed width, can you format the text such that each line has exactly maxWidth characters and is fully justified -- in the next 30 minutes? Maybe you should have cultivated that skillset…

Asking contrived algorithmic puzzles might prove nothing, but the examples in TFA are actually pretty basic programming: “I have an array with positive numbers, find the n^th largest”

Not only is it basic, it's included in the C++ standard library (since '17):

https://en.cppreference.com/w/cpp/algorithm/nth_element

Re: Stop Interviewing with Leet Code

#483

Post by yonaguska »

Koshkin wrote: post #214
yonaguska wrote: post #179

Earlier quoted context omitted.

In your opinion, what's the difference between a leetcoder and a real engineer? In my mind, a real engineer really shines in the non technical aspect of things, like coordination, communication, prioritization, and getting hard questions answered. But that's just me, I'm curious what everyone else's experiences are.

I don't know about that, the best engineers I have met were introverts. (They preferred reading to "communicating.")

I mean, I'm an introvert and I prefer working with code, not people, but I've found my own productivity has skyrocketed now that I'm making an effort to reach out more and raise questions about bigger issues than just the immediate technical issue I'm facing.

I've worked with many people much smarter than me. And I've watched smart, very technical engineers silo themselves off. And then I've watch smart technical engineers that make an effort to communicate and lead initiatives to improve the codebase, make arguments to management for tackling tech debt, and speak up during technical grooming to propose better solutions. And while the siloed off introvert might be able to write better code faster, the engineer that is looking at the whole picture makes an entire team move faster.

Re: Stop Interviewing with Leet Code

#484

Post by dekhn »

UncleMeat wrote: post #416
dekhn wrote: post #369

Earlier quoted context omitted.

Google uses git. I used to sit next to Junio Hamano, the primary developer of git, and lots of teams that used my team's services were using git. Lots and lots of teams. There was even an extension to use git with google3, which was really nice, but was replaced with a system that used hg instead.

I was very imprecise. Git is used both for OSS stuff as well as some other stuff. But the norm is development in google3 and even if you've got a layer of git commands on top of that, the actual source and change management is being done by citc/piper.

True, although I predated citc and piper and we definitely built apps locally on machines with source code (from perforce). I was strongly advocating that more people switch to abseil and build their code like open source in the cloud (the vast majority of compiled code doesn't have interesting secrets that could be used to game ranking, or make money from ads).

Re: Stop Interviewing with Leet Code

#485

Post by tsimionescu »

closeparen wrote: post #435
hiq wrote: post #88

Earlier quoted context omitted.

> Someone who builds a truly novel technology solution involving hundreds of hours of effort This person should already have enough of a reputation to get a job at many companies, if their work is public enough. What do you suggest for the 99%+ other candidates?

>This person should already have enough of a reputation to get a job at many companies, if their work is public enough. You can't just hire someone based on their reputation at a company of any maturity. That's a legal and HR nightmare. There has to be a process with a semblance of objectivity, and that process has to demonstrably apply to everyone equally, always.

I can't at all imagine why this would be the case. Why would a company have any kind of liability for hiring biases such as reputation (except for systematically refusing candidates from protected groups, of course)?

Re: Stop Interviewing with Leet Code

#486

Post by superfrank »

brhsagain wrote: post #148

All of these supposed "flaws" of leetcode are by design. Big companies want people who are smart enough to do the work, but obedient enough to put up with all the bullshit that comes with working at a big company. What person better matches that than someone who's able and willing to study for and pass a tech version of the SAT? Every anti-leetcode article I read is some version of "leetcode is bad because it measure…

I don't know man. I think you're going against Hanlon's razor with this belief. LeetCode type problems may do the things you're saying, but I'm not sure that's the intent.

Personally, I believe the reason companies do LeetCode type questions is because everyone else is doing them and no one can agree on a better way. Large companies want a hiring process that scales and is relatively uniform and LeetCode questions meet that criteria. Is there a better way? Probably, but figuring out what that is takes time, effort, and investment and most companies don't want make that investment for something they may get wrong.

Basically, most everyone knows LeetCode is shit, but as long as everyone else is doing it, there's little incentive to change. If everyone is doing the same stupid thing, at least your company isn't falling behind. If you decide to do something different, there's a real possibility you could spend a bunch of time and effort only to make things worse.

Re: Stop Interviewing with Leet Code

#487

Post by [deleted] »

deckard1 wrote: post #461
synergy20 wrote: post #424

Earlier quoted context omitted.

IQ does not tell determination/hard-working-attitude at all, in fact many with high IQ ended up being nobody, as high IQ makes learning relatively easier, most got used to that and just let the 'grit' go. leetcode is the SAT for coding, not perfect, but at least it's close to fair play.

> IQ does not tell determination/hard-working-attitude this is what everyone said a college degree was for. Or experience. Neither of which matter when a senior dev with 10 years of experience and two kids still has to find an hour or two a day for three months in a row to grind out textbook algorithms to fake problems. Just to switch their fucking job. Thanks to cargo-cult insanity, god help those stuck in miserable…

[deleted]

Re: Stop Interviewing with Leet Code

#488

Post by galdosdi »

BatteryMountain wrote: post #128
throwaddzuzxd wrote: post #96

In my team we do technical interviews in three steps: - an algorithmic challenge. It's related to what we do day to day. I work in domain names so we ask to parse a domain name. There are oddities with domain names so we check multiple things: does the candidate know what basic string manipulation functions exist? do they ask questions to get more info? how do they react when we give additional info that break the co…

This is great, I would totally like to interview like this. The best one I had was a task where you have to basically brute force an api endpoint that uses a semi known password (you have to generate all permutations of a string with alterate spellings ex "pA$Sw0rD" and one of them will match), if you succeed the endpoint returns a url & token to upload your zipped solution. So you end up with a console application t…

This kind of exercise is underrated. A similar one from a former job: the takehome assignment was something like "Here are some CSV files with sanitized real data from our business. It needs to be converted to XML. Use Java (the language our team mostly used then and there) and expect to be judged on your code readability" IIRC there may have been something along the lines of "Bonus: Now we want to be able to convert to/from JSON and perhaps other unknown as yet formats. Refactor your code accordingly"

Other than not using a library, nobody can complain it's unrealistic. Real enterprise devs spend a fair amount of time munging data from one format to another or otherwise "gluing" pieces together. And the kind of person I'd want to hire should be able to complete it to quickly to complain about a "time consuming take home assignment"

And it provides plenty enough opportunity to make sure you're hiring someone who writes code that is pleasant for their teammates to work with.

IIRC the process before that was just the usual 5min recruiter chat and after it was a single on site panel interview before offer.

Re: Stop Interviewing with Leet Code

#489

Post by abirch »

phailhaus wrote: post #427
brhsagain wrote: post #148

All of these supposed "flaws" of leetcode are by design. Big companies want people who are smart enough to do the work, but obedient enough to put up with all the bullshit that comes with working at a big company. What person better matches that than someone who's able and willing to study for and pass a tech version of the SAT? Every anti-leetcode article I read is some version of "leetcode is bad because it measure…

This is ridiculous. You yourself admitted that conspiracy theory doesn't explain startups. The answer is simple: leetcode interviews are stupid easy to give. There is no "nefarious conspiracy to keep workers obedient." It is simply the path of least effort.

You could use the ancient Microsoft logic questions. They are equivalent as easy. Leetcode is sticky for a reason even if it's not the intended reason.

Re: Stop Interviewing with Leet Code

#490

Post by Apocryphon »

deckard1 wrote: post #475
Apocryphon wrote: post #422

Earlier quoted context omitted.

At least with those professions you have one test you pass, and maybe you retake it once every few years to renew your credentials. With Leetcode, you have to retake the test multiple times every few years when you change jobs for each company you apply to. Leetcode would be a lot more tolerable if it was administered more like the bar exam or like medical exams. Whatever happened to DRY?

yep. And you typically do change jobs every few years just to get a raise or promotion. Which means... Always. Be. Leetcoding. Do the bare minimum at your job and then do LC the rest of the time. Because your job is just your job, but your career is LC. These companies don't yet realize they are optimizing for mercenaries that have no loyalty to the code nor the company. On a slight tangent, some of the people over o…

It's what happens when an industry is awash in dumb money. Startups are seen as either half-baked schemes trying to get a cut of the VC funding pie, or cheap R&D labs for the big tech companies in search for inevitable acquisitions. The big tech companies who originally made their money delivering goods or services of real value, squander that goodwill through oligopolistic rent-seeking, engaging in shady anti-competitive or anti-consumer behavior, and endlessly building derivative, short-lived products that users don't actually want in hopes of inflating their moats. In a milieu such as this, engineers become mercenaries because "making the world a better place" has become a tired old cliche, both false and naive. Just a lot of cynicism all around.
Post reply on HN