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

Martijn Vos Dec 23, 2023

I got my first take-home software test in 2004, and at the time I thought it was genius. It also included presenting the result to all the developers of the company, who'd ask questions.

But very few jobs do that these days, and I wouldn't do it for most jobs. My CV should speak for itself, and often a single interview is enough. I have done one take-home a couple of years ago, but that was a very interesting one: in React (which I had no experience in) make an interface to make a maze, and write an algorithm that finds the shortest route through the maze. There were wormholes. So that was just fun and very educational, but also a very rare case.

Generally an interview is enough. Also when I'm on the other side of the table.

My favourite question, both to ask and answer, is: tell me about the most interesting project you've worked on. That usually leads to an interesting discussion.

Also, when interviewing candidates from TCS, I want to hear them say "I don't know" at least once. Admitting they don't know something seems to be a weak spot for them.

Show thread

Riley S. Faelan

@mcv Ironically, some hiring managers are unhappy about people who "too readily" admit that they don't know, and don't have the "courage to speculate" when they don't know.

Historically, studies have shown that this sort of "courage to speculate" correlates strongly with being a white man. (The history of the research of intelligence and intelligence tests is full of many, many, interesting ways in which the tests that were tried were later found to be screwed up, often in ways that advantaged white men.) The correlation has become somewhat dampened now that it's become widely known, and experienced interviewees learn to use constructs like "I don't know, but if I were to speculate ...", but it can still be an issue, especially when hiring people out of school, or from a significantly different business culture.

Show thread

Martijn Vos Dec 24, 2023

@riley

There's a difference between speculating and bluffing. If you say "I don't know, but..." that's great, but if you pretend to know but you're just bullshitting, I'd rather just hear "I have no idea".

Show thread

Riley S. Faelan Dec 24, 2023

@mcv In the literature, the "value-neutral" term used for this is "guessing". It's particularly effective if whatever is being tested is administered as a "standardised test", which commonly have small counts of possible answers, and so high likelihood of getting an answer "right", even if guessing entirely randomly, and more so if one can exclude a couple of obviously wrong options first.