DEV Community

loading...

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

Collapse
190245 profile image
Dave • Edited

I'm interested in this too.

I'm in a "position of power" - our old process was using pen & paper to answer pre-set riddles. So I changed it to a take-home code sample (use your own setup, fulfill these vague 7 requirements to write a CRUD application with 3 data entities, acceptable answers can be done in an hour, but take a week if you like).

That's just for seniors, juniors get "tell me how to fix these two bugs, and optimise this one algorithm." The bugs are just missing colons, and the algorithm is designed so that you CAN'T get it right - because for a junior, I only care "do you know the language, and how quickly do you ask for help?"

So, how can my hiring process be improved? Genuine answers will be IMMEDIATELY implemented (and I'll give the next few days of candidates as much notice as I can).

@deepu105 , any thoughts?

Collapse
deepu105 profile image
Deepu K Sasidharan Author

I like the first part (for senior as you said) maybe you can add a step where you discuss the solution with the candidate to understand the approach s/he took if you are not doing already.

For the second part, it depends on how you do it. If you are doing this on the spot or if you are asking them to do this in front of you or someone else, I still think it will just create performance anxiety, especially for juniors. You wouldn't supervise someone working for you when they are solving a problem right. But if you are sending the question and ask them to work on it unsupervised I guess it would be fine.

Thread Thread
190245 profile image
Dave

For the seniors, the whole point of the test is to talk it through with them afterwards, even if based on their submission, I'm rejecting them. They took the time to write it, so I take the time to talk to them about it.

Mostly, I'm querying them about why they made decisions, what else they thought of etc. If I know it's a rejection, I'll also tell them how, in my opinion, it could have been better.

For juniors, I'm mostly testing their communication skills. The code samples are on my screen and they don't have control of the mouse or keyboard. They have to talk me through their thoughts, and discuss the code (and solution) with me. Kind of like a code review/merge request.

Absolutely anything they want to change, we can change. I've talked to people who didn't like intelliJ, so I opened Eclipse. I've talked to people that didn't like the variable names, so I asked them for better names & refactored on the spot. I've talked to people who didn't like my dark theme, so I switched it.

I recently hired 2 juniors, using this process. The deciding factor over & above their communication, was that they asked if we could change the requirements of Test 2 (the impossible answer test). So on the spot, I changed the requirements for them. Everything about the junior test can be changed on the fly, including how much help I give, all they have to do, is ask.

Less than a week after employment, both the new guys are fixing bugs in our production code, and I very nearly rejected one of the bugs based on infrequency Vs effort to fix. But the junior I hired wanted to look at it from a different angle... and found an easy fix.

Thread Thread
deepu105 profile image
Deepu K Sasidharan Author

Maybe you can ask them first if they are comfortable to do the test that way and give an option to either do it together with you or look at the sample alone first and then talk together with you it will ensure you are not scaring away a potential candidate who might just be afraid of being wrong

Thread Thread
190245 profile image
Dave

If they are afraid of being wrong, to the point that they can't ask questions, I don't think I'd be hiring them.

There comes a point, in all jobs, when you have to do as the boss asks, just because the boss asks.

In our office, there are times of pressure, from lots of different sources, there are times when we get asked to do the impossible, or to shortcut process to get a win for the business. I would be doing candidates a disservice if I couldn't work out in an interview/application how they might handle those times.

If, under pressure, a junior developer can at least say "it's not my role to sign off on that, who approved it? Or better "should we do it that way? Isn't there some compromise that works for everyone?" - they're more likely to get hired.

If they sit at their keyboard being afraid to say what's on their mind, the whole team suffers in many ways.

Thread Thread
deepu105 profile image
Deepu K Sasidharan Author

Like many others you are confusing work pressure with performance anxiety. Please read the other comments on the blog. I'm honestly tired of answering the same thing again.

Thread Thread
190245 profile image
Dave • Edited

I'm not confusing the terms at all. I'm trying to find a way that works for everyone in the process, genuinely.

I need to, at least hazard a guess, at how a candidate (at any level) might cope with work pressure. How am I to do that, without risking some performance anxiety?

Would you suggest, instead, that I focus on removing work pressure? (We already have very little of it)

Further, if they have performance anxiety in an interview, are they not likely to have the same (and suffer imposter syndrome etc) while working? Unfortunately, even with juniors, I don't have the budget to help improve their confidence over the next (as an example) 6-12 months.

I completely understand that some people suffer panic attacks etc, and I wish them well with their health & their career - but I'd much rather know about that up front, and take it into account. Who knows, for the PERFECT candidate in every other way, I could probably spend the time to shield them from sources of anxiety in the office. I've just never talked to the PERFECT candidate.

As another point of topic, I worked with a senior once who didn't realise what he was feeling was imposter syndrome. He could do the job perfectly well, but group meetings made him anxious. So we changed things up for him, and made more of a point of showing him his successes. The point being, he communicated, and essentially asked questions. Apparently, him talking to me, putting a label on it, and him researching about it helped him in his personal life, and he's spotted the same in other people.

If people cannot ask questions, for whatever reason, then we're going to have problems.

Thread Thread
deepu105 profile image
Deepu K Sasidharan Author

Asking questions have nothing to do with live coding or whiteboarding. I don't think people suffering with anxiety or imposter syndrome have problems asking questions. They will ask questions if they have any. Problem is unable to code or solve a problem (which they will be able to do perfectly fine in a normal work situation, even with time based pressure or some other work pressure) when they know that there is a person watching their every move and evaluating it (doesn't matter how nice or comforting you sound, its hard to control how a brain works) from what you said it seems like you care about people you hire, so just switch to take home assignments or worst case, something like codility, then have a review session to talk through what they did. It will give you more insight into the candidate and they will feel much more at ease and perform much better.

Thread Thread
190245 profile image
Dave

Asking questions have nothing to do with live coding or whiteboarding.

Specifically whiteboarding, I probably don't do the way that most people do. I use a whiteboard for the very purpose of them drawing something they know (or should know, if they've been paying attention in their previous/last role), in order to generate the questions I ask.

I think that probably differentiates on that key principle, other than the candidates history, I don't come into an interview with a pre-set list of questions. It's much more akin to a conversation, and if it's not a two way conversation, with the candidate asking me (sometimes very tricky) questions, they probably won't get the job.

That's probably why I (probably incorrectly) jumped from "performance anxiety" to "debilitating anxiety" - while they have commonalities, it's most definitely not the same thing.

Back to whiteboards, the best one I had, was an interviewer asked me to "draw the testing triangle" - nothing more, just wanted to know if I knew it. It's the kind of thing that as a developer, we never really bother thinking about, but should definitely be aware of.

Problem is unable to code or solve a problem (which they will be able to do perfectly fine in a normal work situation, even with time based pressure or some other work pressure)

In any situation, interview, daily work, shopping - if someone can't tell me there's a problem, there's nothing I can do. However, tell me there's a problem, and we'll move mountains (hopefully together) to put it right.

switch to take home assignments

Seniors get a take home assignment, juniors don't. For a little better context with what I do with juniors, check my post (and please feel free to give feedback, knowing the context better): dev.to/190245/we-re-hiring-new-jun...

Off-topic (for this conversation) - I didn't see your job title until today, when I decided to read the thread fully on my laptop, instead of my phone. It was actually a junior developer (in the job, not in an ineterview) that introduced me to jHipster, and while it doesn't quite work well for us, we do make use of it where sensible. So kudos on working on something that other dev teams use (our work is all internal only, very specific domain knowledge etc).