91–100 of 625 posts
All the talk about diversity, but no diversity of thought. Only LC chasers. I genuinely believe this decreases innovation massively.
Earlier quoted context omitted.
I use this https://github.com/emilybache/GildedRose-Refactoring-Kata in their favorite language. Has been a very effective filter
I'd give a bit of guidance. This can go so many ways. I can see many right but totally different answers. In any interview, I kind of presume that the interviewer has a "perfect answer" in mind and is playing some game where I basically need to guess what number they're thinking of. I'd make it clear that anything is ok. Just go some direction
And the problem can be scaled to any complexity. Distributed/Design/Data Storage
The last few interviews I've run, I've shown the candidate sample code and asked them to review it. We have samples that have at least one bug / problem per line. Then some modeling task (whiteboard). We have some simple exercises (fizzbuzz style) to figure out if juniors actually can junior and as a springboard into discussing topics like runtime complexity, memory layout and stuff. This is all highly interactive, d…
I use this https://github.com/emilybache/GildedRose-Refactoring-Kata in their favorite language. Has been a very effective filter
When I make interviews I also come with the code, normally a few line snippet and have the person tell me what it does or whether there might be a bug and talk about it.
Reviews are also great. They take away the show-cooking aspect where many people feel nervous and makes it more conversational. It is also very easy to evaluate as well because everybody debugs code at some point.
I personally dislike even fizzbuzz because there are always clever ways to go around it that are totally irrelevant.
I was once asked to implement sort a list in python, so I just took the list and passed them to sort. But no the interviewer wanted me to implement a specific type of sort…this was for a distribution maintainer job and I almost failed it because of that. Fortunately the other stages were actually technology related and I aced them.
The last few interviews I've run, I've shown the candidate sample code and asked them to review it. We have samples that have at least one bug / problem per line. Then some modeling task (whiteboard). We have some simple exercises (fizzbuzz style) to figure out if juniors actually can junior and as a springboard into discussing topics like runtime complexity, memory layout and stuff. This is all highly interactive, d…
The (best) seniors just use a library. The good candidates roll their own, but can explain the tradeoffs. The juniors get the test to pass and stop.
Another interesting point about Leetcode-style interviews I've not seen raised: it's a form of intellectual hazing. It's been proven many times that the severity of an initiation ceremony significantly boosts the commitment of those admitted to the group.
What is a better capitalistic company hiring programmers:
>Lots of smart similar people who believe in correct answers
>Lots of random skilled people
If you said the latter, you are idealistic and your opinion genuinely doesnt matter. Nature will replace you with someone smarter and realistic.
Leetcode style interviews probably serve two functions: 1) A way to suppress wages and job mobility for SWE. Who wants to switch jobs when it means studying for a month or two? Also, if you get unlucky and some try hard drops an atomic LC hard bomb on you now you have an entire company you can no longer apply to for a year. 2) A way to mask bias in the process while claiming that it’s a fair process because everyone…
I understand the frustration, but at the end of the day I think they do serve a purpose. They're not great at that purpose, but they're good enough and they generally produce false negatives (smart people fail) rather than false positives (you hire an idiot). And this makes sense, because a false negative is low cost (maybe you spend 50% longer interviewing candidates) but a false positive is high cost (you hire an i…
But it's entirely pointless.
Earlier quoted context omitted.
Question banks that are too big: huge variance, and OP's point stands. Question banks that are too small: leaked on eastern forums immediately, candidates show up reading answers out to you (some of the guides include guidance on when to pretend to think, I am not kidding). The idealized version of "question banks" might work. The real one does not; you'd require employees constantly scouring forums in every language…
I agree with you, but I don't really see how this invalidates the style of interviews where you're presented with some timeboxed coding problem (of reasonably scaled difficulty) and are asked to solve it. There will be bad actors regardless of the interview style, thats why companies have multiple interview types/styles/rounds to sus out a candidate, as you probably know. If they BSed their way through a leetcode int…
I think this is where our different opinions come from, while we agree on the other aspects.
In my personal experience, I have never felt that the hire/no-hire decision relied exclusively on my ability of solving the presented problem; I have passed interviews where I did not solve the LC-style problem optimally but I communicated clearly, picked up on hints, was aware of when I hit "walls" and provided working but less than ideal alternatives when I could not figure out the neat tricks.
Reading through the thread it seems that my experience is not universal, and the majority here have had less pleasant interviews, so I understand where you are coming from.