| ▲ | serial_dev 2 days ago |
| In a small company, you can tell your buddy “just have a chat with the candidate and if you like them and you think they can do the job, hire them”. If the person interviewing your candidates messes up, you’ll know soon enough. In a large company, the bad people will take over and your company is dying a slow death. That approach doesn’t work on a large scale. Some interviewers are too nitpicky, elitist, others approve anyone who uses the same language as them for side projects. Some are racists, sexist, or have other kinds of biases. Some might have a crush on the candidate. Sometimes the interviewer thinks about their own task while they squeeze in an interview. In some countries, “undoing” a bad hire is hard, so they need to make sure that the candidate can work on any team (or at least on multiple teams reasonably well). IMO for large companies it makes sense to standardize the interview process. Also, in my opinion grinding leetcode is also a good personality check for FAANG hires: it shows the candidate can suck it up, study hundreds of hours, and do whatever they need to do to pass an arbitrary test, even if they themselves think it’s a broken process. The larger the company, the more this quality matters in candidates as they will need to deal with a lot of things they will probably not like. |
|
| ▲ | hirvi74 a day ago | parent | next [-] |
| I'm quite conflicted on this. While I do not think one needs to remember/memorize a bunch of brainteasers or past computer scientists'/mathematician's PhD discoveries in order to build CRUD applications. However, I do feel like there is perhaps some amount of truth to the thought behind the interview questions, no? As in, I would imagine someone that could invert a binary tree in 15 minutes on a whiteboard could probably learn React. However, I am not sure everyone that can learn React can invert a binary tree in 15 minutes on a whiteboard. However, maybe I am projecting my own insecurities because I wish I could invert a binary tree in 15 minutes on a whiteboard as well as being able to solve all those other problems. |
| |
| ▲ | swatcoder a day ago | parent [-] | | No, it's not actually about mastery of binary trees or other abstract computer science concepts. leetcode is really a culture fit test and success points to the combination of "smarts", diligence, and conformity to some acceptable degree. It shows you have some baseline of familiarity with computing, can focus on an arbitrary task to pursue a goal, and will conform to an arbitrary process when it's asked of you. Those are genuinely essential skills in an organization with 1000's of white collar professional workers. More precise insight is gained when the test covers a binary tree inversion than that were it just some contrived logic puzzle like the LSAT or a critical reading exercise. The computer science bit does provide some signal and isn't completely arbitrary, but it's only a small part of what's being evaluated. Among otherwise strong engineers, it tends to filter out the especially willful, prideful, independent, meandering, creative, and pragmatic ones. These personality types can be extremely valuable in some work environments and can still sometimes in through leetcode challenges, but spoil big bureuacratic systems like FAANG's when they're overrepresented. | | |
| ▲ | grandempire a day ago | parent | next [-] | | The culture thing is huge. If you can’t find a few good leet code problems to enjoy, I don’t know if we are interested in the same field. Having done a lot of interviews at least 70% of the time it’s filtering candidates who just aren’t very technical and haven’t studied computer science. The kind of people who hate reversing a linked list are the kind of people who haven’t touched a polynomial since high school. It’s not unreasonable for a junior tech interview to expect you studied something like CS or EE. It’s a blessing that our field is open to all to give it a shot, but if that doesn’t describe you - you need to recognize that there is effort and study to fill that background. | |
| ▲ | rightbyte 21 hours ago | parent | prev [-] | | "Leetcode" style tests were probably good when almost no one did it. Now it selects for the very very very bad trait of high ambition and knowing to play the system. |
|
|
|
| ▲ | rightbyte 21 hours ago | parent | prev | next [-] |
| > In a large company, the bad people will take over and your company is dying a slow death. Why is this the assumption. I would rather say any big org. is converging towards the average talentwise by necessity. It is like Hawaii can't have 100 olympic level swimmers no matter the recruiting proces. |
|
| ▲ | Dylan16807 2 days ago | parent | prev [-] |
| But I'm talking about the idea of pair programming for an hour or two. Why can't the standardized test still involve that? What doesn't "scale" about it? |
| |
| ▲ | serial_dev 2 days ago | parent [-] | | I think it’s easier to compare candidates who might have been interviewed by different people possibly weeks apart if you have a coding challenge… could they solve the problem we gave them, if yes how quickly and how well. Interviewers can write their notes, the session can be recorded and the committee can compare candidates relatively fairly. Comparing candidates based on how they “vibe” with the interviewer during a pair programming session is a recipe for lawsuits and bad hires. I’m just speculating here, I don’t have any significant hiring and interviewing experience | | |
| ▲ | Dylan16807 a day ago | parent [-] | | If you're worried about interviews weeks apart and cross-team testing, then the most that can hurt efficiency is making you do the test with the team they'll be imminently hired into, which means you're on par with the small company, nothing lost nothing gained. Avoiding pair programming for the reason you listed sounds like lawyers getting in the way, not scaling. But yeah we'd need to hear someone say if that's actually happening. |
|
|
