How would you improve SWE interviews?

Nov 22, 2019 17 Comments

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!


Want to comment? LOG IN or SIGN UP
TOP 17 Comments
  • Oracle ggppkk
    You heard? You guys created this mess
    Nov 22, 2019 4
    • Google tcme
      Oracle, you don’t seem to understand what we are looking for. We extend offers all the time to people who don’t solve the problems.

      We aren’t looking for you to know the answers. We expect you to know data structure fundamentals, have an educated dialogue with us as we give you hints along the way, and make some form of progress.

      If you regurgitate the ideal tabulated solution to a dynamic programming problem. That’s a no hire.

      If you optimally solve the solution but your code is not clean/demonstrate good design, that’s a no hire.

      If you solve it but you don’t communicate well with us. That’s a no hire. We want to work with people that collaborate well with us to come up with a solution.

      If you come off as rude or lacking emotional intelligence, that alone is a big no hire, even if you excel technically.

      That’s the general guideline but isn’t always successful. But we do have consistent training everyone goes through to try to keep to these guidelines.
      Nov 22, 2019
    • Oracle bittorrent
      You are asking dynamic programming? Well, you are one of the problems.
      Nov 22, 2019
  • Facebook / Eng UnND55
    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.
    Nov 22, 2019 2
    • Google / HR RecruitBot
      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!
      Nov 22, 2019
    • T-Mobile


      looking for new opportunities...
      I don't think a bot can become a VP, at least not yet. Maybe after the bot wars of 2038.
      Nov 22, 2019
  • Google tcme
    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.
    Nov 22, 2019 3
    • Google tcme
      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.
      Nov 22, 2019
    • Google tcme
      Plus, the OP is a Googler. We are the ones that are coming up with all the new algo questions for everyone else to copy and use at their companies.

      Trust me, at Google, we definitely have the time to create sample projects with test cases using our 20% time and 40-hour work week.
      Nov 22, 2019
  • OpenTable Meliodas
    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.
    Nov 22, 2019 0
  • Fastmail RywL56
    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)
    Nov 22, 2019 0
  • Dropbox / Eng brumdb
    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).
    Nov 22, 2019 0
  • 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".
    Nov 23, 2019 0
  • T-Mobile


    looking for new opportunities...
    Nov 22, 2019 0


    Real time salary information from verified employees