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.
I am sick of LeetCode-style interviews
481–490 of 625 posts
Re: I am sick of LeetCode-style interviews
#482Re: I am sick of LeetCode-style interviews
#483Earlier quoted context omitted.
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…
> We had one candidate who insisted that parsing a string and returning an integer was an unreasonable question because there was already a library function for it. “But what if you have an embedded system and no library?” (an actual situation for us, for part of our system). He was adamant — honestly that was a failure of the phone screen: had it been caught it would have saved us, and him, from wasting time. Trying…
if the interviewee pushes back and find they don't like the answer, then it's a good signal to both parties.
Re: I am sick of LeetCode-style interviews
#484Such 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.
I know what you're saying but I don't think there is any kind of nefarious backroom discussion that goes on to this purpose. I think more likely though are the accidental favoritism in the industry where engineers submit resumes of other engineers they know who are looking for a job who, surprise, are also white males. I don't believe it is either racist or sexist however. It's just "who people know". Nonetheless, yo…
80% of my colleagues are Chinese and Indian. This is usually the case at most of my jobs that aren’t early stage startups.
Re: I am sick of LeetCode-style interviews
#485Earlier quoted context omitted.
You’ve set up a false dichotomy here; for any given position, there is typically a way to conduct an assessment-based interview that doesn’t require too much preparation for qualified candidates. For example, at my current job, we hire web developers with Rails experience. Our technical interview process consists of either a pair programming session or an async/take-home task (candidate’s choice) which requires the c…
This may work out great if you happen to have worked on Rails for your last job. However, I doubt that everyone you interview is actually that familiar with Rails but rather is pursuing any sort of opportunity that they can get. In that case, they would actually more time to brush up multiple different tech stacks than simply on algorithms.
If you happen to have Rails experience but it was several jobs ago, the task we give you is basic enough that you should be able to Google what you need during the task to refresh your memory fairly quickly. In fact, I did this when I applied, having not worked with Rails in a number of years.
Edit: My main point is, even if you technically do have to "study" (really, just Google a few basic Rails concepts) if you're rusty, everything you do is preparing you for the actual job. Studying how to implement a hashmap, or computing the longest palindrome from a string of characters, or whatever other harebrained problem FAANG etc want to ask, is 99% of the time not really helping you prepare for those jobs.
Re: I am sick of LeetCode-style interviews
#4865 years later, I still refuse to do them and I don't want to put myself through that process ever again. I got bullied, harassed, laughed at and taunted by people who use this as a one-hour game of kicking people around and I'm not interested in entertaining them any more. I have the following disclaimer both on my LinkedIn [1] and GitHub [2] profiles because I had plenty of surprise-leetcode interviews, so I want to…
I like the idea of your approach. Can you share anything about how well it's worked out for you? My main concern is that with the allegedly rampant cheating on take-home assignments, the number of employers willing to use them may drop precipitously.
PS: What this approach gives me is piece of mind since I know I won't get a surprise-Leetcode if I go through an interview. It has happened to me in the past, where the recruiter wasn't really aware what the process is and I haven't told them up front what I'm not OK with. Once I'm there in front of people, it's very awkward and frustrating for me to have to get up and walk out and I'd very much rather avoid that situation. Also, it's a waste of my time.
Re: I am sick of LeetCode-style interviews
#487Earlier quoted context omitted.
> Coming from Real Engineering One related problem I see is that Computer Science tends to be under-estimated by other engineering fields. A ton of software engineers did not study software. They learned to program as part of their engineering studies, and they believe that they learned both Computer Science and their engineering topic at the same time. I may be biased, but I see fewer computer scientists pretend to…
>One related problem I see is that Computer Science tends to be under-estimated by other engineering fields. If Bachelor of Science computer science grads were that much more extraordinary, they wouldnt be working side by side with non-degreed programmers. Chem Engineer here, I wrote random forest once. My coworker with a CS degree, all front end work.
Re: I am sick of LeetCode-style interviews
#488Earlier quoted context omitted.
> 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). I've seen this reasoning, but I'm wondering if this is actually true, especially if you also believe the other myth in hiring: most people applying are not qualified for the job. Since most hiring actually requires you to fill the position in the…
In my years of hiring experience, it doesn't hold up. I've hired folks who could leet code all day long, but couldn't develop a feature from scratch, or figure things out without enormous hand holding. I want to hire problem solvers who also know how to code. I stopped doing leet-code interviews about 7 years ago. By all means have people code in interviews, but don’t do leet code.
Someone who does well on leetcode is usually easy to teach so they will become good/great in a year or two, but if you don't have that time then go for leetcode+experience just like everyone else is.
Re: I am sick of LeetCode-style interviews
#489Earlier quoted context omitted.
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…
I have come to like this approach reasonably well. My current company uses a similarly simple problem to evaluate candidates. For me, it was a breeze, and I thought we’d be hiring slouches left and right. Once I started administering the interview, I realized that the majority of candidates absolutely bomb this simple question for one reason or another. It seems that “able to code a simple problem well” is a far less…
Re: I am sick of LeetCode-style interviews
#490Earlier quoted context omitted.
In my years of hiring experience, it doesn't hold up. I've hired folks who could leet code all day long, but couldn't develop a feature from scratch, or figure things out without enormous hand holding. I want to hire problem solvers who also know how to code. I stopped doing leet-code interviews about 7 years ago. By all means have people code in interviews, but don’t do leet code.
How do you test whether they're problem solvers that also know how to code, without leet-code interviews?