4 ms·
I've recently been studying leetcode (for reasons) and went through an interview process. It was, by far, the most boring interview I've ever had to participat
by CharlieDigital 2y ago
I've recently been studying leetcode (for reasons) and went through an interview process.
It was, by far, the most boring interview I've ever had to participate in. The leetcode problem was easy (detect if two strings are anagrams; solved with O(n) solution in < 10 LOC; then aggregate sets of anagrams). System design was easy because it is to the point that it is largely "formulaic". It feels like those rhythm games where you need to know when the trigger is coming and the pattern to hit those triggers (talk about functional requirements -> talk about non-functional requirements -> write some API routes -> draw a load balancer (because of course, there's always a load balancer) -> draw a service -> draw Redis/Memcached -> draw a database). It's comically laughable how it's just like a rhythm game at this point.
What I don't understand is why teams don't just "get to the point". A lot of times, the assessment is looking for specific notes. Why not just ask about those notes directly? A friend recently went through an interview where he was docked for not using C# `yield` when implementing an `IEnumerable`. But had the interviewer asked "What is `yield` and why would you use it?", the interviewer would have gained the same exact insight in 15 seconds with one question.
I think what's also striking is how slow orgs are to adapt their interview process to account for AI. There's a distinct lack of focus on code reviews as part of the assessment. If the future of coding is AIs for productivity, then teams should be adding code reviews into their process (check for correctness, check for defects, check for performance, check for security, etc).
- emseetech 2y ago| distinct lack of focus on code reviews as part of the assessment "Writing code is easy, reading code is hard" An interview based on reading, explaining and critiquing complicated code would give a better window into a candidate's skills than having them solve the kind of coding challenge that can be completed in a short interview. Also, being able to identify which algorithms would be useful in solving a unique problem and explain what the pros & cons are would go further than implementing an algorithm abstractly.
- BurningFrog 2y agoThat was my favorite interview ever. The guy gave me 30 lines of code, and asked questions about it. Including finding the questionable constructs in it.
- CharlieDigital 2y agoIt was also my favorite interview format as well. Interviewer had a small API. Found missing error handling, missing validations, poor choice of ID column type, missing index for a high volume read query, possible XSS vector. Loved the format so much I ended up making a small FOSS tool for code review as interview: https://coderev.app https://coderev.app
- olvy0 2y agoThis looks great, I might use it next time I'm interviewing.
- Rustwerks 2y agoI tried this and found that there are a set of potentially good candidates who simply cannot bring themselves to criticize anything in front of an interviewer due to the power dynamics of the interviewer/interviewee relationship.
- whimsicalism 2y agoi would argue that isn’t a good trait in an employee either
- __turbobrew__ 2y agoThose are the same people who will know the project is heading off a cliff and not tell you before it is too late.
- CharlieDigital 2y agoYou have to set them up for it. "Imagine that this code was written by a junior dev; review it and tell me how it can be improved, where the problems are, and other feedback". Or "We just hired a new intern and he pushed this PR. I need you to help me review this code for issues and make sure it's production ready".
- pintxo 2y agoIt’s my personal interview approach, I have a some 60 lines of code example I will ask questions about. What does it do, if I wanted to change x, where would I need to do this, etc. Seniors will take 30 seconds for the first two questions. I‘ve had junior applicants where I had to stop after 15 minutes of trying.
- CharlieDigital 2y agoI think this format is very conducive to leveling because there are some tells that are really obvious. Like input validation, error handling, database indices, database column types, race conditions, etc. You can't fake these easily, but with experience, they surface quickly.
- whimsicalism 2y agosounds like you interviewed for too easy a job, the anagram question you described would be significantly easier than interviews i have or give
- CharlieDigital 2y agoIt was exceedingly easy but it was for probably one of the highest level IC positions at a large, public BNPL. The entire technical part of the interview could only be described as "boring" and un-engaging.
- BeFlatXIII 2y agofrom collections import Counter if not Counter(str1) - Counter(str2): # success, they are anagrams
- xigoi 2y agostr1 = "a" str2 = "ab"
- BeFlatXIII 2y agoGood catch. Counter(str1) - Counter(str2) | Counter(str2) - Counter(str1) That ought to work. I'd hope Python's caching doesn't recompute the Counter for long strings.
- tetraodonpuffer 2y agoAs somebody that gives systems design interviews most weeks, you’d be surprised how many candidates don’t put the api gateway but magically go from the TCP load balancer to the services inside the cluster, or how basically nobody is ever able to explain how a CDN works (as in, put the CDN behind the API gateway, note I have seen this in a company in production too). Or how some candidates will have redis and Postgres and do magical cross storage transactions. And these are all candidates with 5+ years experience, sometimes 10+. I hate the leetcode gauntlet, but I also am really surprised how much worse candidates are now on average that they used to be (I’ve been around for about 25 years now), and how the minute you try to dig a little deeper to see if they know how things really work, the more it seems that they have no understanding whatsoever of the basics and somehow treat computers as magical black boxes. I do understand I am privileged by having grown with the technology, starting in the 8-bit era, through an electronic engineering degree, and now in k8s etc. but with so much educational material available for free you’d think that even people in their 20s/30s now should be able to have a better idea of how things work.
- jazzypants 2y agoI think a big part of the problem is that if you search for most tech subjects, you're more likely to find terrible medium and geeksforgeeks articles written by amateurs than something real written by someone knowledgeable.