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?

  • American_Badass [none/use name]
    ·
    9 months ago

    My interview for an internship that became my first developer job, for sure. It wasn't a traditionally "technical" interview, meaning it wasn't the latest trivia ever. They looked over my resume, and asked me technical questions about what I had done, decisions I made for projects, etc. The team just didn't believe in staring at people trying to code on a whiteboard.

    Got the offer within about an hour and didn't have to interview to sign on permanently. I have subsequently always refused interviews where salary range wasn't disclosed up front, and if I talk to a recruiter, I have always asked for contact information for a dev on the team.

    But, that's the advantage of having a job I don't need to leave, and having experience. I've heard much worse from others.

  • d13@programming.dev
    ·
    8 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.

  • vojel@discuss.tchncs.de
    ·
    9 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.

  • curiousaur@reddthat.com
    ·
    9 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.