DEV Community

loading...

Discussion on: Let's face it, we have a broken technical interview process in our industry

Collapse
190245 profile image
Dave

I'm a hiring manager.

Yes, I need to know candidates skills - to the level of "do you know the core language?"

I don't care for most frameworks, they're transient, but if you can't spot a compile error glowing bright red at you in an IDE, please don't waste my time.

I agree with you that I have to measure how a candidate can adapt, but as the author of the article talks about performance anxiety - how do we measure adaptability without risking performance anxiety?

Trial periods, even a day, are terrible, in my opinion. I don't care about paying the candidate for it, I care about the costs to the rest of the team, starting onboarding for someone who simply may not be there tomorrow because they don't like it, or they had a better offer etc.

Your point on take home tests - I use one (for senior candidates). It's very clearly spelled out that we won't be using it for anything other than the recruitment process, and that a passable solution can be done in an hour, but feel free to take a week if you like.

Every submission of it that I've had, I've not even run a build against it - I literally don't care if it fulfills the requirements given, it's just too give talking points in the interview.

Thread Thread
phantas0s profile image
Matthieu Cneude • Edited

I would argue that you can see if a candidate "can spot a compile error" when the IDE turns to red by only asking question. I'm always mesmerized of the crazy answers I have to "what's an interface? What's the purpose of it"? It does already A LOT of sorting.

For the trial days, it depends on your on boarding. I know what you mean though; once, we invited a candidate for a trial day. Only running our project on his laptop took 4 hours. Not because trial days are terrible, but because our documentation was bad and our set up too complicated. We fixed that, and it was not a problem anymore. The good side of the experience: it showed us a big problem we had.

This is the only kind of on boarding you need, I think. You need to explain quickly the goal of the application as well, and then let he candidate implementing little stuff or fix small bugs. Some open source projects are very good at that, to have more contributors. I take the inspiration from them.

For the home tests, you can't guarantee that it will only be used in the frame of the recruitment. If you read it and learn something from it, your candidate already gave his knowledge against nothing. We are knowledge worker, our worth is (partly) our knowledge.

That being said, your process seems focusing on what's important, which bring me to the eternal conclusion that the tools themselves are not bad, but the way you use them can be bad. I saw too many recruiters / hiring managers being so picky on the way to do stuff (if it's not their way, it's the wrong way), or on the knowledge somebody should have on a precise framework, or not judging enough the soft skills, that I prefer not spending time on tests and such. Especially since, in my experience, they precede any form of discussion.

Another thing: the problem to me as well is that the interview process is often going in one way, judging the candidate. The candidate should have an idea about the company as well, the culture, how people like it. It's very difficult to have most of the time and it's essential, because if your candidate is not motivated to work in your company, everybody will regret it.

Tests don't really show you how the candidate will be in your team either, and it's very important too. If you look at the research done on the subject, it's even more important than the skills of a single developer. So why focusing on that?

These are just thoughts. It's an interesting subject, which is unfortunately too often "space vs tab" kind of discussion. I think your process is quite good, but I think as well there is always room to improvement.

Thread Thread
190245 profile image
Dave

Oh don't get me wrong, we have lots of room for improvement - and to a large degree, that's why I can't even think about trial periods at the moment. Though, we had 2 juniors start recently that were pointed at a repository and nothing more, and they had 3 of our 27 components running within a day, and a day later were confident enough to start estimating tickets. One of those juniors is fresh out of university, never worked as a developer.

Ultimately, I only really care for juniors "do you know the language, and how quickly will you tell me that you're stuck on a problem?" The latter being a very fine line, obviously. For seniors, all I care about is "can you learn quickly, and can you communicate well both up & down the ladder."

I get your point on giving free knowledge away, but really, we're talking about things that you could search online & find out. Case in point here, I spoke to a Senior candidate yesterday, and during his code-review stage, I mentioned he had a lot of getters & setters, so I asked if he'd used Lombok before (we are a Java "shop"), with a view to branching the discussion towards AOP vs readability. He made a quick note on some paper he had at the side, and admitted he hasn't. There were a number of times this happened, with various technologies - and he scored better with me because not only did he admitted his gaps quickly, he made a note and genuinely seemed interested to check it out regardless of the outcome of the interview. I don't know yet if I'll hire him or not, but if not, he's learnt some things for free and I really don't mind sharing them.

Tests don't really show you how the candidate will be in your team either

I know, which is why the tests that I give (other than "spot the missing semi-colon" stuff for juniors - which is done in an IDE and the IDE is screaming at you to tell you where it should be) - are geared towards discussion points. I'd rather try to work out how a candidate thinks rather than what they currently know/think.

the tools themselves are not bad, but the way you use them can be bad.

I couldn't agree more - I've seen my fair share of poor recruitment processes. Ours used to be horrendous, and I had to answer maybe 20 or so Java "riddles" using pen & paper for my interview here! So when I moved into a more managerial position, I immediately moved the process to one that I'd like to go through as a candidate. Juniors get one Skype call and a decision, Seniors get a take-home test, one Skype call, and a decision.

I highly doubt I have it right for every candidate, but I'll tweak as I go, and my whole point for reading all the comments on this article, was to see if others had better ideas that I could "steal" (and in some cases, there have been, and I have).

Thread Thread
phantas0s profile image
Matthieu Cneude • Edited

Interesting. I like your approach. Thanks for that!