291–300 of 625 posts
Such interviews are made to legally discriminate against old developers. A freshly graduate student has more chance to still know this or that algorithm, and prepare for that. An old/experienced developer has dealt with plenty of real world complex problems. So much that his attention is absorbed by them, not by what is the best way to search for an element in a tree.
Earlier quoted context omitted.
Out of curiosity, can you share some examples from eastern Europe? Where does one find such websites? Also, IMHO, blanket generalizations like "Asia" and "Eastern Europe" in such contexts can actually be more offensive than just mentioning the one country where the thing happens since you're basically painting with tar a whole sub-continent with dozens of different countries, just for the things happening in one coun…
No, because I feel like mentioning previous employers AND mentioning the languages I speak would get quite specific. You are interested in Eastern Europe, so you should be familiar with olympiads; ask around any circle of ex-olympiad participants and you are bound to find something. I am not sorry if you took offense; you're either from one of these countries and are clueless to the circles that exist next to you, or…
Obviously I'm not a golfer.
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…
At all the companies I’ve run we’ve used a simple whiteboard example for this reason. Don’t worry about typos; how does the person think. “Trick” questions are dumb, but you want to get an idea of if the candidate knows their stuff (and let the candidate know what we’re like — interviewing is a sales process in both directions). If someone asks a question like “is it ok to modify the argument” (or says “I’ll assume I…
It seems that “able to code a simple problem well” is a far less ridiculous proxy for good software engineer than “able to code a hard problem at all”. Much to my surprise.
Earlier quoted context omitted.
That’s not true. In any discipline when confronted with a test there are two strategies: brute memorization of the question/answers, or developing the skills to tackle the problem dynamically. You cannot categorically claim that LC tests are largely memorization tests rather than raw problem-solving skills. That is just the approach you are capable of taking. Not being able to see up the mountain doesn’t imply there…
> You cannot categorically claim that LC tests are largely memorization tests rather than raw problem-solving skills If that were the case then a normal, well accomplished software engineer shouldn't need to "grind" leetcode to pass an interview. its just a cargo cult. Getting someone to do a code review is a much much better test of skill: Do they ask questions? are they kind in their assertions? At what point do th…
No, what this shows is that the skill range for accomplished professional software devs is absolutely massive. What these companies want is to find the tail end of this very wide distribution. Leetcode interviews do a decent job at this. If you have been coding for a decade and can't do leetcode mediums with almost no prep, and hards with a moderate refresher on data structures, then you're simply not the in the right tail of the skill distribution and they don't want you. This is what so many in our industry can't accept: you're just not talented enough to earn a FAANG job.
Earlier quoted context omitted.
I've also used FizzBuzz at several companies, and the insane amount of people it filters out continues to boggle my mind.
Do you tell them what the "mod" operator is before giving it? The failure rate of FizzBuzz has always struck me as depending on the idea that you can do a lot of programming and just never need that operator.
At least for me it would be sufficient if the person used a function like IsMultipleOf(x, m), or Remainder(x, n). This would at least make it clear what the function did even if they didn't get the exact operator.
The other thing to note is that the mod operator works differently on different languages and platforms.
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…
At all the companies I’ve run we’ve used a simple whiteboard example for this reason. Don’t worry about typos; how does the person think. “Trick” questions are dumb, but you want to get an idea of if the candidate knows their stuff (and let the candidate know what we’re like — interviewing is a sales process in both directions). If someone asks a question like “is it ok to modify the argument” (or says “I’ll assume I…
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…
However, we do require a base level of competency. We give out a 40-ish minute assessment. Two multiple choice and three coding problems.
And they’re easy. One of them is essentially “John has a 5 gallon bucket and 3 gallon bucket, how many buckets does he have?”. All you have to do is rewrite the clearly labeled circuit diagram as a Boolean expression.
Not a single person this round has passed. Several have failed the simple ones.
So while grilling people on the minutiae of a language or asking them to solve the traveling salesman is not beneficial, neither is nothing.
We should be testing floors, not ceilings
Earlier quoted context omitted.
Do you tell them what the "mod" operator is before giving it? The failure rate of FizzBuzz has always struck me as depending on the idea that you can do a lot of programming and just never need that operator.
I once worked with a guy who was an incredibly good developer and I was surprised when he didn't see anything special about the number 64 (i.e. a power of two) - turns out that he'd never done any bit fiddling type work so he hadn't had to think in those terms. It wouldn't surprise me if a lot of people hadn't heard of "mod" either....