Mastodawn

Anders Borch Dec 23, 2023

I have interviewed 100s of candidates for software engineering positions.

I’ve done take-home tests, in person challenges, pair programming with the candidates.

All of them were awful experiences for me and especially for the candidate.

I can only think of a single instance where a code challenge exposed a poor software engineer and I could definitely have made the same assessment just by talking to them.

Lately I’ve stopped doing any software or mental puzzles.

I don’t do any of that when I interview designers or QA people or HR people, so why would I be particularly toxic towards software engineers during the hiring process?

Instead, I actually read their resumes (which is significantly quicker than doing interviews, asking them to repeat the same information), and then I ask them questions like:

- Where do you get your tech news?
- How do you learn about new technologies?
- What do you most appreciate in your coworkers today?
- What is a perfect workday like for you?

I specifically avoid trap-style questions like “what is your greatest weakness?” or “why are you leaving your current job?”

I recommend that you make a plan for what you want to learn about the candidate, e.g. “are they good at acquiring new skills?” or “do they share the same values as the team?” and then structure the interview around that.

Be a non-toxic manager. Make your company look good during the interview process. Get better candidates.

#jobs

Show thread

Chip Unicorn Dec 23, 2023

@anders

@OctaviaConAmore

Interesting.

I don't like software traps for interviewing, either, but I need to know how good or bad of a programmer someone is.

I give them a straightforward problem with three steps in order, plenty of time to do it in, and I'm there for the whole time to answer questions. I emphasize that they should be writing code as if it's going to be code reviewed. Yes, there is a tricky part of the question, but there's an obvious O(n3) solution, and no one gets points taken off if they do the O(n3) solution.

And this technique has done well for me. And I've gotten praise for this way to handle coding.

Show thread

Benjamin Reed Dec 24, 2023

@Chip_Unicorn @anders @OctaviaConAmore I suspect whether or not this works depends very much on the type of person you’re interviewing, and you’ve been lucky so far.

My particular neurodivergence means I’m terrible at that style of coding test. Not having my normal work environment, coupled with anxiety at being watched while I work, means I do not in any way end up working like I do in the real world.

You never get to “see how I think” you just get to watch my brain chemistry be a jerk to me.

Show thread

Raven667 Dec 24, 2023

@RangerRick @Chip_Unicorn @anders @OctaviaConAmore I have found some value in having a _very_ simple practical test as part of the interview process, not some sort of gotcha but just to see if they are *grossly* overestimating themselves and how they work under pressure, as we do operations. I understand how nervous this can make some people, as I myself have totally screwed up an interview when my mind went blank, but you can see the difference between stress and lack of fundamental knowledge.

Show thread

Benjamin Reed

@raven667 @Chip_Unicorn @anders @OctaviaConAmore when I have my own tools I work quite well under pressure, but “interview test” is an entirely different artificial kind of pressure.