3 ms·
Not a widely shared opinion here, but this process will make you a better engineer. Keep at it.
by martythemaniak 4y ago
Not a widely shared opinion here, but this process will make you a better engineer. Keep at it.
- carlmr 4y agoI see this all the time, "coding interviews suck", "leetcode doesn't test if you're a good coder", but in the end it's better than nothing, and having worked at places without coding interviews there's almost no bottom to people's abilities. So a low, but existing, floor is a good thing.
- vsareto 4y agoThe biggest issue IMO is lack of flexibility. Leetcode is a specific format with specific questions, but is not necessarily the work you'll do day-to-day. What would be great is if companies offered multiple formats including leetcode, take home, pair programming, Github review, project review, just talking, etc.
- shagie 4y agoThere are several issues that leetcode solves that the other ones don't work as well with or have flaws that prevent their use in some hiring processes. Leetcode has a single rubric. The same questions and the same answers. Conducting it has minimal additional effort on the employer's side. It does have false negatives, but it has fewer false positives. Take homes are often similar to leetcode, but some less scrupulous companies have used them for unpaid work (note that this becomes more and more of an issue as the take home becomes more and more relevant to hiring company) the and unless the interviewer has done the take home themselves to benchmark it (this should take between 1-2 hours), it is possible that the request be "do this thing that will take 20 hours." GitHub review requires that the person have a GitHub project of sufficient size, that it isn't just copied from someone else and that they have time to work on it. There's a joke in /r/adventofcode that shows a GH repo that only has activity in December. With pair programming, project review, and just talking the lack of a rubic becomes an issue and it becomes more likely that biases get into the interviewing process and leads to possible issues of discrimination. When mixing any of these so that some people do leetcode, others do pair programming then it becomes an issue that not everyone is considered using the same scale and those biases and discrimination issues become even more something that legal starts wondering about if they'll have to deal with a lawsuit. If one person can do the interview with "just talking", then that should be the same criteria that everyone uses (no leetcode) and "just talking" has an abysmal false positive rate.
- throwawaysleep 4y agoMemorizing decks of leetcode problems improved your engineering skills?
- the_doctah 4y agoShockingly, sometimes Software Engineers are asked to write algorithms for their job.
- TedDoesntTalk 4y agoAnd you don’t resort to memorized algorithms when that happens. You research.
- awa 4y agoFrankly, Leetcode seems like a more objective test to me than a panel of interviewer grinding me on behavioral questions checklist.
- throwawaysleep 4y agoAnd you would never plunk down a memorized verbatim fix in such a scenario.
- the_doctah 4y agoNo, but I'd be far more likely to choose the appropriate data structure or canned algo since I know how they all work
- amusedcyclist 4y agoWho said anything about memorizing
- eulers_secret 4y agoYou're definitely correct, I've learned a lot while practicing leetcode. Especially about my chosen language (Python). I do feel I'm a better engineer because of it. I don't think much of what I've learned will be useful in the day-to-day SWE grind. It's really quite interesting, but I cannot recall ever having to remember the skeleton of an iterative DFS before now. I've taken away more useful lessons from system design studying. If I had my way, I'd spend more timing finishing "Designing Data Intensive Applications" (AWESOME book), instead of figuring out why my oranges aren't rotting correctly or trying to remember how to solve the coin problem using dynamic programming instead of a greedy algo. On the plus side, once I've got a good memory base and can solve random Mediums and some Hards, I should be OK to pass basically any technical interview - barring random chance. Right now I took a break for xmas and need to go back to it, and that is the hardest part :)