I’ve interviewed for and been interviewed by companies large and small. We all know software engineer job interviews suck. But it’s hard on the other side of the table too.

One of the better places I worked for had a lightweight process of one phone screen and a four hour on-site. The company also prepared offers before the on-site interview round.

When you finished interviewing, you got a same-day yes or no answer, and if it was yes, you had the offer in your inbox within an hour.

What interview practices have you found effective?

… And by what metric?

  • mozz@mbin.grits.dev
    link
    fedilink
    arrow-up
    14
    ·
    edit-2
    10 months ago

    Google’s interview process was at least twice as good as any other place I’ve ever interviewed. They do a phone screen where you solve not-very-complex problems on a screen share, just to make sure you have some baseline level of coding ability, and then they do one full-day tech interview.

    They share with you way beforehand a video that explains exactly what the interview process is, and recommends that you practice at it so you’ll be getting tested on your actual ability level and not unnecessarily put on the spot. For the interview day, five different people will stand you in front of a whiteboard for one hour each, ask you to solve a programming problem on the whiteboard, and then give different further augmentations to the problem or ask questions about it. Some of the problems are straightforward, some are exceedingly difficult (I told one guy, I don’t think I can actually give you a good solution to this problem, and he said, oh I know you won’t be able to solve it completely and correctly, I just want to see how you approach it and what you come up with). With the exception of lunch which is more of an open chitchat type “interview,” it’s no bullshit, no brainteasers, just here, write some code, let’s see what you do.

    The thing I appreciated most about it was the applicability to what you’ll be doing on the job. Now with AI tools, things are a little different in terms of what makes a “productive” programmer, but I’d imagine it’s still pretty similar and still effective.

    When I was part of giving interviews for a company I used to work for, we actually used a pretty similar thing, but used a written test and gave people time to sit down with it. We found that standing people up in front of a whiteboard would sometimes make them super nervous (probably why Google does it one-on-one and tells you what to expect and has you prep beforehand). But I’ve never found anything that works as well as simply asking people to write code and then seeing what they come up with.

    Hope this is useful.

    Edit: Other random things which are helpful: Having a single point-of-contact who’s your “advocate” within the company is useful, so for logistical things you’re not just some random person on the phone with someone who doesn’t know what’s going on with you. Obviously the interview people being on time, being respectful of your time and effort to the interview, being upfront about salary, letting you know the answer quickly and directly whether yes or no, all that stuff is key too.

  • corytheboyd@kbin.social
    link
    fedilink
    arrow-up
    11
    ·
    edit-2
    10 months ago

    Bar is on the floor. This is easily my best interview experience:

    • My prospective manager was clearly present and engaged in the process
    • All other interviewers were also prospective team members, and very engaged
    • I can’t state this enough, nobody didn’t want to be there. This is my absolute biggest peeve when interviewing, and I will leave if you clearly don’t give a shit. If you don’t care, you’re either just bad at interviewing and should not do it, or you know the role doesn’t really matter. You get an hour to judge me, perhaps erroneously, I’m going to do the same
    • The questions were deep, offering plenty of ways to express my experience. I get that I need to do some coding because even very tenured engineers can be very bad at it, but making me do 3 leetcode questions is fucking dumb for a Rails interview, and they clearly knew that
    • There was no punishment for answering with few words when it was warranted— the interviewers were good enough to riff off that to make the questions deeper. You can’t just put any random junior on an interview panel (do have them shadow if they are interested though), it’s a skill, and if you don’t respect that I won’t respect you
    • My point of contact was attentive and helpful
  • cosmicrose@lemmy.world
    link
    fedilink
    English
    arrow-up
    10
    ·
    10 months ago

    My current company had two phone interviews with the people who’d become my bosses, and they gave me a take-home programming problem that was practical enough to show I could do the job and work in the language they use, but simple enough that I got it done in an hour or two. And without feeling like I was doing work for free. That was it.

  • d13@programming.dev
    link
    fedilink
    arrow-up
    6
    ·
    10 months ago

    tl;dr: The right people, the right exercises, the right atmosphere.

    I started by sitting down to a pair programming session with a member of the team that was hiring. We did some minor work directly in their code base, and he showed me some of the interesting things in their stack. It was great.

    Then we had a panel interview with other team members and the CTO (not a giant company, but there’s over 1500 employees, so I was impressed.) We discussed some of my previous work, the designs involved, tradeoffs, etc. There were a couple white-boarding conversations. We talked about leadership and various people topics.

    Then most of the panel and my referrer took me out to lunch, and we had a good informal chat.

    Finally, we went back and I did another pair programming session with a different member of the team where we did code kata problems for a while. We discussed pros and cons of pair programming and mob programming.

    Why did I like this so much?

    1. The two programming sections were with senior developers on the team they were hiring for. Also, pair programming is great because you see how somebody collaborates as well as how they can solve problems.
    2. The panel mostly consisted of people I would be working directly with. The questions in the panel were very relevant and you could tell they were looking for my strengths.
    3. The atmosphere in general was great.
    4. What I saw of their codebase looked really good.

    I was very impressed with this company. They made a competitive offer. I ended up declining, mostly for external reasons like a long commute, but I still wonder to this day if I should have given it a shot.

  • ursakhiin@beehaw.org
    link
    fedilink
    arrow-up
    4
    ·
    10 months ago

    Started with an at home exercise that was rooted in the actual work the company does rather than code kata type problems. The exercise was critically reviewed on organization, testing, and documentation in addition to solving the actual problem. It also included a debugging component.

    The hiring manager was extremely personable. So much so that he’s the entire reason I took that job over other offers.

    The interviews were broken into small groups, each focused on particular skills. After starting I found out that they actually had a training series to teach people interview skills before they actually ran interviews.

    One interview was a coding based and was a consistent series of problems that were real world and built on each other that demonstrate coding skills. One was a design interview that was explicitly meant to highlight high level thinking. One was a culture fit interview broken down into a series is conversational questions.

    The recruiter was provided with enough info to give the expectations in how they wanted answers structured as well.

  • finestnothing@lemmy.world
    link
    fedilink
    arrow-up
    3
    ·
    10 months ago

    My current job as a data engineer at a law firm. Phone interview on a Monday, second interview Thursday, offer letter Friday morning. The main technical question was describing the three main kinds of sql joins (left, inner, outer), besides that mainly talked about my schooling, projects, etc. Nothing super intense, just making sure I wasn’t completely bullshitting about my experience and skills.

    The SQL question was apparently a really good metric because a lot of people were applying for the job and couldn’t do it, and the previous person was fired after a couple months when it became clear they had never used sql and weren’t that good at programming in general (lots of lying on their resume). I found some of the garbage they made and it’s… Really rough.

    Been here a year and a half now as my first job out of college, chill remote job, good pay, and I love my coworkers

  • curiousaur@reddthat.com
    link
    fedilink
    arrow-up
    3
    ·
    10 months ago

    Genuinely fun coding exercise split up over 4 interviews. The first was the initial interview, 3 of the onsite interviews were expanding on the same project, with PM and CTO interview mixed in. Got an offer same day.

  • vojel@discuss.tchncs.de
    link
    fedilink
    arrow-up
    3
    ·
    10 months ago

    Besides that I start to thinkig about quitting my actual job, it was indeed the interview process for the job where I am atm. My boss is a cool dude, like a good buddy you can talk openly to. No shit show, no buzz words, just straigt "that’s the job, take it or leave it’ - I took it and it was fine for a good time. Worst I got was 3 (THREE!!) interviews for a position as a DevOps Engineer for a big company, people were nice but it took them about 6 to 7 weeks to make me an offer, I refused because they were sooooo slow.