Just for one anecdote, three years ago my then-dentist (who was a part of a franchise practice and probably under pressure to bill) told me that I had 12 (!!) cavities across all quadrants of my mouth that needed to be filled immediately.
I went to another dentist in the area, they took some x-rays themselves, and told me that there was nothing that needed immediate work - maybe one pre-cavity that would eventually turn in to something but certainly not worth doing anything with now.
Three years later (and sticking with that new dentist) I still haven't needed to have anything done (and certainly don't have any pain in my mouth anywhere either).
Here's the difference: I bet you had time to think through the novel problems and didn't have someone hovering over your shoulder, demanding you come up with solutions within 20 - 30 minutes -or else-.
Not at Microsoft, but have been at a company for a very long time being underpaid. I haven't left simply due to one issue: I refuse to do leetcode interviews. I've dipped my toes into the waters every once in a while and even the companies that swear to me up and down before interviews that they don't do leetcode, well, guess what I discover during the interview loop...
> I haven't left simply due to one issue: I refuse to do leetcode interviews.
If it helps any to know this, I get compensated at least as well as Microsoft (or equivalent) companies provide and have never had to do a single leetcode interview. I've never even been asked.
As near as I can tell, leetcode is used by a certain subset of the industry. But the industry as a whole is much larger than those companies.
Is there a particular subset of the industry you specialize in? Curious where the leetcode-lite/free areas might be (unfortunately I'm not in one of them).
Hmm. It’s more like you want to hear the musician play first, but you don’t ask him to play something he is comfortable with to learn how skilled he is, nor do you ask him to play a known challenging piece of work. Instead you just start pulling out short “gotcha” songs with obscure key shifts and speed changes to test them. Like, sure a great musician will be able to handle it if they are a great musician, but it’s just annoying for the musician and there should be better ways to determine if they meet your expectations.
The example I always give people is imagine that you're a civil engineer and you walk into the interview and they have a bunch of Popsicle sticks, sticky tack, and a bowling ball.
They inform you that your interview is to build a bridge with the sticks and tack that can support the bowling ball rolling across it.
(Yes, I know the age-old argument that 'real' Engineers are accredited and all that, but I still think the example shows how ridiculous it all is)
Of course, but this is like if the whole interview were they have you sight read 10 bars of music, and then 8 bars of a different genre, then 18 bars of another harder one. Then they just spam those at you for the duration of the audition. That is the whole thing. Like, yes. It is “a” way to do it, but it is understandable that there would be musicians who aren’t fond of that interview style.
Would you be willing to share your story of how you made the switch? CS major here considering going into medicine (despite your best efforts to convince otherwise :) ) but the general coursework wasn't something I targeted in school all those many years ago.
Anecdotal on my part, but I interviewed with them earlier this year. I was told by the recruiter (an internal recruiter, to be clear, not a third-party), in no uncertain terms, that their interview process did not involve "leetcode-style problems" and would, instead, be a "real world problem" close to what an engineer might be expected to solve normally.
I was told (and this was reflected in the interview prep materials they provided) that bringing my own IDE and screen-sharing was the norm, although they would be prepared with a collaborative online editor as backup. It would be a collaborative session where the interviewer would work through the problem with me (obviously with myself in the driver's seat).
I was reasonably excited. Finally, a tech firm that didn't cargo-cult leetcode hazing.
And then came the interview.
I leave it to the reader to guess at the nature of the problem (hint: it starts with 'l'). The interviewer also seemed entirely unprepared and surprised that I was prepared with my own IDE. They were also unwilling to collaborate, and unwilling to accept how I approached solving the problem (I like to write experimental pseudo-code out first as I think through things, especially when in an environment where drawing things out isn't easy. I let them know that was what I was doing and explained my thought process as I wrote it, and yet they kept interrupting and explaining that I could clean that code up... code that was not meant to be "final" or "complete"...)
It was just a terrible experience from beginning to end. From the recruiter presenting an interview plan that was clearly not in line with reality, to the interviewer being unprepared for what their own interview prep materials described (BYOIDE!), to the interviewer's unprofessional and very unhelpful demeanor (if day-to-day engineering at Stripe involves being berated at every step as you prototype a solution to solve a leetcode problem before preparing to write the actual solution...well, maybe they should fix that)
> They were also unwilling to collaborate, and unwilling to accept how I approached solving the problem
Wow. Similar thing happened to me with Stripe. It was a system design interview. I had already seen a very similar problem and aced it with Amazon. This person just kept saying "we don't have time for this, we need to get through this whole system" - wouldn't even let me finish my thought. It was arbitrary whether they wanted me to dive into a section of the system more or if I was boring them (and they did not seem excited/engaged to present this interview) and taking too long explaining my decision.
Stripe was the only company I didn't pass (and I passed multiple FAANG interviews) and it was the only company who told me twice that the role I was applying for either was filled or "shifted priorities" and they would scramble to find me another role with another hiring manager. And I am certain it was because of this one system design interview that we just did not click on.
Your comment and the parent comment smell like a company utilizing the hiring process to abuse potential candidates to actually solve the company's problems without paying them.
Facebook was like "do you have experience using coderpad" "yes, I do... I've given interviews in it". Come time for the interview, I spend a considerable amount of time commenting out the stuff that the interviewer posted (could tell that she was looking at me like "why the hell is he doing that") into the coderpad, only to find out they had execution disabled. Fuck you, Facebook.
I feel like that's pretty common? In most interviews I've had/given you are not expected to write runnable code, and having to fix typos or library function names tends to be a stress-inducing distraction.
Sure. Every whiteboard interview I have had has been like that, but the expectation with coderpad is that you write executable code. I've never taken or given an interview on coderpad that was otherwise, which is why I was shocked that was even possible as a feature on the platform.
Otherwise you might as well use Google docs.
Anyways there was a tooling communication problem. Clearly Facebook was new to the coderpad thing, they should have come out and said so, they should have communicated that you won't be able to execute, etc.
Never used coderpad, but my experience holding (online/remote) code interviews is that even using an IDE with standard error highlighting and color coding is just a waste of time - people start concentrating on fixing typos and adding keywords, as they are conditioned by the red squigglies, and that just detracts from the point of the problem. Having people actually try to make the code runnable would make things so much worse...
After experimenting with BYOIDE, we've stuck with online code style platforms (monotype fonts, no language-based Word-style auto-correct). This helps people focus on the problem, not the code itself, in my experience.
> Having people actually try to make the code runnable would make things so much worse...
I’m not sure I follow here. For me, programming is an iterative process: write a small chunk, test it out, write the next bit, and so on. Not being able to execute code seems like it would make that process harder, and force interviewee to essentially come up with the code “fully formed” all at once, which is hardly a useful or realistic skill.
I've never run into this as a hirer. I don't test to see if a candidate can implement an algorithm from memory. In my test, I describe the steps for the algorithm and see if they can "follow the spec". I find most candidates (even seniors) can't, they can't help but make it 'more complicated than the spec asks for'.
Neither do I. I want to see how they work through the problem, focusing on the problem. The IDE takes their focus away in my experience, they start correcting the squiqlies and adding extra bits of syntax that don't matter in a pseudo-code setting (such as adding closing brackets they forgot earlier) to avoid auto-spacing issues and so on.
It may take a bit of extra time but one other positive of coderpad I found is that because it offers library-level auto-complete I noticed people relax a bit since they are not afraid I will ding them for not knowing some common method name or syntax.
To me that's exactly the problem: I don't care if they call it sort or orderBy and so on, and I make this abundantly clear. Them spending time and mental energy to change the order of params or other things like that distracts from the core issues we are trying to solve together.
I give coderpad interviews all the time and absolutely do not expect them to be executable. If you write me executable code, great, but you’re probably wasting your time. We also have execution disabled in my org. It’s just a notepad that we both can see that kinda half-ass supports code highlighting and formatting. I hope I’m never asked to write executable code in it because as an editor, it’s terrible.
IMO You should really reconsider disabling execution and just tell the candidate that executable is not expected. Writing tests and executing them is an extremely important part of my programming flow, and when I am presented with a tool that I expect to be able to actively test with, if I am unable to do so... it's "fuck you Facebook"-level frustrating.
I guess it's yours hiring process, so whatever, but you could probably be filtering out people with very good and desirable programming habits.
I've also had some serious problems with (senior) coworkers who "assert their code works" when it's riddled with bugs or flat out doesn't work, so maybe it's my trauma refected here
> I hope I’m never asked to write executable code in it because as an editor, it’s terrible.
Well, I typically offer coderpad for anyone who would rather not share their screen.
Strong disagree; every coderpad interview I've given or received specifically did _not_ write executable code, and that was either explicitly communicated or just assumed by everyone involved.
> Otherwise you might as well use Google docs.
Coderpad has other useful features like syntax highlight, autocomplete (I think?), and the private interviewer notepad with timestamps.
Whenever I use coderpad I make sure to mention the code execution to my applicants and give them a choice of using it vs. just pseudocode and collaborative editing. But most of the time people appreciate the feature and like using it.
In an industry that is deadset on focusing on worthless leetcode puzzles as the major gating factor for a hire decision, I struggle to understand how someone "banging away hopelessly" is decidedly unqualified.
There are literally people applying for SWE jobs who couldn’t write FizzBuzz or a function to sum a non-overflowing array of ints in a language of their choosing. That’s tablestakecode, not leetcode, IMO.
That is fair. I have not encountered them myself, nor ever been an interviewee where "tablestakes" is the bar and not "hard leetcode haha I know the answer and you don't~~", but I absolutely acknowledge, recognize, and understand that this is a real occurrence as well. In those cases, I wholeheartedly agree with the label.
> All of them consider themselves extremely lucky that they landed a job at a great company and believe that if they had to re-interview for the same position, odds are much more likely they'd utterly fail it.
I expect we'd see this absolute disaster of an interview "process" fixed overnight if every company required their employees to re-interview for their position yearly (through some blind process so the interviewer isn't aware they're interviewing someone who already works there - yes I'm aware this won't work for small companies... it's not going to happen to begin with so let's just pretend :P).
Every company would immediately start a "task force" to fix their interview process once they reject (and then fire) 90% of their staff after the first re-interview.
I've taken to simply waste interviewer's time at this point. I'll schedule an interview, find out it's a leetcode one, and still plan to attend. With everything remote now, I can just completely check out. Watch a video on another screen while just completely wasting the person on the other end's time.
Even better if I can somehow get to a "virtual onsite" where I likely get to waste 4+ people's time.
If there was a viable solution to pushing for real change in the industry, I'd do that. But there really isn't.
Hah, I don't mean to be rude but, this is what everyone claims they do, but no-one actually practices it.
The simple fact of the matter is, is that if you can't 100% solve the problem, in 30 minutes or less, without asking questions related to how to construct a solution, and cover all edge cases, and come up with the absolute top-tier optimal solution, you're getting rejected.
That is why it's worthless as an interview technique. Everyone plays this whole song-and-dance about how they "just want to see how you approach a problem you might not know how to solve" but, in the end, the only thing that matters is regurgitating the top leetcode solution to the problem.
This is so true, most top companies expect folks to write flawless bug free code of problem in 20 minutes or less now. Some expect two problems in 45 minutes now (if you are unlucky really one medium and one hard). If you write a sub-optimal solution you are rejected for sure. If you haven't grinded leetcode/hackerrank and haven't seen it before there is no way you are going to solve a hard problem in 20 minutes - lets say 10 minutes to think and 10 minutes to write the code for a hard leetcode question.
Obviously, since large companies _have_ lots of employees, either their tests aren't crazy hard, or there are lots of people way smarter than you for whom the same tests are manageable.
I share the same experiences. Only around half of your (temporal) experience and every conversation with a recruiter ends the same way: "When can we schedule you for a technical screening? You'll probably want some time to brush up on leetcode as well".
My experience doesn't matter. The fact that I've now worked at (and currently work at) 3 of the big tech firms, doesn't matter (to be fair, I only got jobs at these places back when I was willing to grind out leetcode and memorize as many problems as I could - a task which I refuse to do today). The fact that I have a history of leading teams, areas, and spend at least 50% of my time also "writing code" for high performance, high reliability, global services, --and-- can speak in depth regarding my accomplishments, design decisions, technical decisions, collaboration, etc. doesn't matter.
The only thing that matters is: Can I pretend like I've never seen this toy leetcode problem before during an interview, and magically come up with a perfect solution in 30 minutes or less. (and if I haven't happened to memorize it, and dare legitimately appear to struggle, well... game over).
Leetcode and equivalent seems to come out of an intersection of a technical interviewer's "I don't want to take the time to interview you" and HR's "I don't know how to interview you."
Everyone knows that something very serious must be done at an interview. Nobody cares about it enough to actually put in the time or trust for a bespoke solution.
Consequently, you end up with everyone sub'ing algorithms in for due diligence, then because they made that choice, defending the choice and pretending like it's meaningful.
Hiring is hard. Hiring technical, non-standardized talent is even harder.
I went to another dentist in the area, they took some x-rays themselves, and told me that there was nothing that needed immediate work - maybe one pre-cavity that would eventually turn in to something but certainly not worth doing anything with now.
Three years later (and sticking with that new dentist) I still haven't needed to have anything done (and certainly don't have any pain in my mouth anywhere either).