How would you improve SWE interviews?
To all my software engineers out there: How would you change the interview process to make it better? I've done my best to listen to feedback over the years and want to be part of the solution by collecting data to present to my engineering leadership. Currently the industry standard is to have some sort of combination of coding, system design, in domain technical, and behavioral rounds. Specifically for the "leetcode" coding rounds, I've heard that they don't accurately assess whether people are actually good software engineers or not. Do you agree? Are there any other pain points? How would you suggest solving for those challenges? Thanks Blind community!
Ok, it's Friday afternoon, I'll bite. The fundamental problem with FAANG type software interviews is they assume all developers are basically interchangeable, so to interview, you ask them the same questions and pick whoever answers best. But of course that's ridiculous, and it requires you to only use questions that are widely applicable, which are the least predictive kinds of questions. The current system is basically fine for new grads, since none of them have any experience anyway and there's often an up or out policy that cleans up mistakes (and lets you take more risks when hiring). But for people with experience, the goal shouldn't be that you hire the best algorithm folks, the goal should be that you hire the people best at X, for each major kind of skill you need. Sometimes people try to excuse the coding portions by saying it's important to hire people who can code, and while that's true, you don't need to ask questions that are algorithmically hard to do it - you just need to ask coding questions that are hard enough to show they can code at the minimum level, and then you have another interview where they go deep into an area, which might be algorithms but can also be databases or distributed systems or debugging or what have you. There's your pitch, give me a cut when you're VP of HR.
Thanks for the thoughtful response (and for the bonus data point that Friday afternoons are a good time to ask questions on Blind 😂). So would it be fair to say that you're suggesting that once a company interviews someone for more senior levels (L5+) it'd be a better idea to lean more heavily on "in domain technical" rounds? Perhaps 1 coding, 1 system design, 2 in domain, 1 behavioral? I'll come back to this post and find you when I'm smoking cigars with the fat cats!
I don't think a bot can become a VP, at least not yet. Maybe after the bot wars of 2038.
I actually had some great non-leetcode questions on interviews in Google. Just ask real problems instead of LC bullshit. I would like questions to be evaluated by experienced engineers from next point of view: would I like to see such thing in project I own (example: I wouldn't like to own fucking trapping rainwater algorithm, I'm ok to own simple scheduler).
1. Tailor the interview based on experience. 2. For experienced people, eliminate LC/hackerrank crap and do more role-focussed/targetted hiring. Focus more on which companies they have worked on/ what projects they have done (cause thats real than LC) / what motivates them to join your company. 3. For freshmen, do 1-2 rounds of LC medium (atmost) and check general problem solving skills. 4. Dont let fresh grads (or less experienced folks) more experienced folks. 5. Make sure the interview process dont go beyond a certain time period (say 1 month)
My favorite style my previous company utilized is as follows: We would have pair programming and TDD (test-driven development) sessions with the candidate. In each one, we would present a software project and through the process, we would explain requirements and write a failing test for them. The candidate would write the code to make it pass. This exercise was great as we had a handful of pre-canned software projects with a set of tests. We could assess the candidates coding ability in an actual project as well as their communication skills on explaining what they are doing in a typical pairing environment. Also, our sessions focused more on object-oriented design and clean coding habits over algos. Our team successfully recruited a lot of great engineers that were awesome to work with.
Nobody has time for that.
My last company was a smaller company. Sure, there’s an upfront cost to building a set of sample projects and test cases but it was a far more accurate way of assessing a candidate over algo interviews. At the same time, it did frustrate our candidates who spent all their time focusing on just algos and struggled to read the project code of only a couple classes and handful of functions.
Ask realistic questions related to the role, not CS 101 memorization questions. The interview should closer mirror what they would have to do in the role. Give them a fictional ticket, have them code it, then code review it. Give them a fictional PR and have them review it.
Don't make it like SAT. If people keep on solving those 50 minute or 1 or 2 hour problems in 10 minutes, give them penalty. Ask them how they arrive at this solution? Why didn't they try the usual and non-optimal way to begin with. If a problem took the original solver years or month to solve, and the candidate apparently haven't seen this problem and can't solve it in the optimal way, but is getting pretty close or is getting the second best solution in 10 minutes, give them credit. I am the type that didn't know LeetCode problems and didn't go through "past interview questions and solutions", and I often arrive at a company wondering why my coworkers didn't know how to think and not know some basic concept of CS and yet they got in. Some might even appeared defensive as if, "how I got in, don't question me. Now I am one of the workers and don't you know I am already friend with the manager".
You heard? You guys created this mess
Yeah, I'll own up to that fact. There needs to be change though. Any constructive ideas?
Don’t ask lc hard or medium questions. Train interviewers not to expect people solve hard coding problems. It’s not natural. Train interviewers to assess people better. There should be coding problems. But even a simple node delete problem can reveal so much about people, leveling etc. Thing is young people who are interviewers don’t know how to evaluate people. They just memorize a couple of lc hard problems, making themselves feeling superior. These kids are not old enough or trained enough to judge technical abilities. They only know one thing. How to code. Unfortunately that’s a very small part of being a software engineer.