Comment by PJDK | Hacker News Reader

Comment by PJDK | Hacker News Reader

In the last set of interviews I've conducted (for junior/midlevel C#/vue.js devs - still hiring if anyone wants to experience this for themselves and is in London - link at the bottom) I've settled on a list that more or less all start with "can you tell me about a time when...", or some other variation on asking about experience. One's I've had a some success with...

- A bug that was particularly difficult to track down? (What did you learn? What would you do differently?)

- A time you disagreed with your manager/lead? (And a time when in retrospect you think you were right/wrong/got your way/didn't get your way?)

- a piece of work took much longer than you anticipated? (what did you/would you do to prevent it happening again?)

- you had to quickly learn a new thing?

For more specific technical stuff I like to try and find questions that allows someone to show off, rather than tests if they know just one thing. We're using Typescript, C# and TDD...

- what new or upcoming features in C# do you most like using/would like to get the chance to use/really wish were out already?

- what parts of Typescript do you find most useful vs Javascript?

- what makes a good test?

- what makes a bad test?

I don't see why anyone wants to ask anything of the what does using `ref int foo` mean, especially when there's lots of competition in the job market at the moment!

https://www.linkedin.com/jobs/view/full-stack-c%23-vuejs-typ...

That style of question is perhaps the most horrible one to subject someone to.

Instead of focusing on the task of talking to someone, you end up trying to recollect instances of each kind of event, evaluate them on whether you can talk about them openly, whether they can sound impressive even if they actually are, whether they will sound plausible, whether you can recall enough details to avoid being called out as a bullshitter etc.

The people who can appear to answer these questions best are either a) prepared for them specifically or b) psychopaths who can comfortably lie and twist stories with a smile on their face on the spot.

Well I'm very happy if people have prepared for these questions beforehand, and I try and give people hints and nudges to help get good answers out of people (I want people to do the best they can!).

Do you think there are any style of questions that do work well?

I think a healthy mix of open-ended questions (such as those in your post) and closed-ended questions is key. Open-ended questions are useful for getting at how an engineer goes about solving a problem. Closed-ended questions reveal whether that engineer has the tools to solve the problem to begin with.

Interesting thoughts. What would you think of as a good closed ended question? I always worry that if I'm to specific I'll get false negatives (do they really not know what protected means or have they had a brain fade under pressure?)

The goal of the individual interview should be answering: "I have some particular problems I need to solve soon, and some undefined future problems to solve later, can hiring this person help solve the immediate problems and do I think they'll be an asset in solving future problems?"

Once you've got some questions in mind that should answer that for an individual, you need to reformulate the questions so that most of them are at least semi-objective and have a scoring criteria that you can use to rank multiple people who passed "yes" on the overall question -- and perhaps a threshold too if you think you can afford "yes, but let's wait to see if we can find someone even better".

In this light, 'tell me about a time when' types of questions aren't often very useful unless they're directly related to an issue you're currently facing and you've precommitted to some sort of score for types of answers. e.g. "time when you've disagreed with boss (or coworker)" might be relevant because your team currently has some drama dynamics. So 0 points for "Oh I never have disagreements", 1 point for "some story that makes me think they won't get eaten alive here and/or be a total pushover, the story details don't really matter", 0 points (or negative) for anything that raises a total asshole flag. The question about new C# features might be useful as a proxy for answering whether they'll be helpful in the future, i.e. do they keep up-to-date about things and keep learning, so maybe that's worth a point if they can name something and maybe you can ask a different question as another proxy to normalize across interests (they might not care about PL features but something else). And depending on the real concern being proxied, sometimes you can just ask about the real concern directly.

If you can, make a work-sample test: https://sockpuppet.org/blog/2015/03/06/the-hiring-post/

Are you recruiting public speakers or software engineers?

Those are junior level?

How much experience must someone have to be a junior developer in your opinion?

The people I've been interviewing have had between 1-4 years experience. For people with effectively zero experience these questions have limited value, and I try to tailor the questions to the level of person I'm interviewing.

  - what makes a good test?
  - what makes a bad test?

I'm curious what you consider are possible correct/incorrect answers to these. I don't expect widespread agreement.

So I don't have a fixed good answer for any of these - what I'd like to see is that it's something the interviewee has thought about/read about. I'm also interested in how deep the knowledge goes, can they discuss these things? Have they tried other approaches and so on. That sort of thing is quite experience dependant, of course.

Possible good test answers (I'd expect maybe one or two - bonus points if you can talk about them as lived experience rather than text book)

Tests one thing/clear what causes a failure

Documents the code well

Describes the purpose of the code

Something about naming

Something about BDD

Something about arrange act assert

Something about how quickly it runs

Discussion of relative merits of unit, integration, e2e etc.

What's a Bad test answers...

Brittle (bonus if you mention this in relation to refactoring)

Asserting multiple things

Tautological

Very slow to run (with which I'd follow up with "any exceptions to this)

Plus you'll get lots of points if you bring up something I've not thought of before.

Reply on news.ycombinator.com