this post was submitted on 19 Jan 2024
42 points (97.7% liked)

Ask Experienced Devs

1235 readers
2 users here now

Icon base by Delapouite under CC BY 3.0 with modifications to add a gradient

founded 1 year ago
MODERATORS
 

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?

you are viewing a single comment's thread
view the rest of the comments
[–] d13 6 points 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.