My regular readers (both of them) know that hiring and developer evaluation are some of my favorite topics. Or perhaps more accurately, they are t...
For further actions, you may consider blocking this person and/or reporting abuse
Been there, said that. :-)
Nice to see you again on these pages!
What did they say? I am curious..
First of all I would not suggest anyone to be so cheeky, especially early in their career.
Second, I do my homework before interviews and always research the position and the company. It is unprofessional and dumb not to do so.
Third, I always said that with a charming smile. Just before showing them that I know why I applied.
But the point is, and this is the reason I say that, is that, really, they called me, I am happy where I am, and their recruiter teased me, so the question is dumb and inappropriate and they should adjust their interviews accordingly.
Same goes for coding challenges. If I applied you can ask me a 2h take home challenge, if you chase me because I look great for you... Well.. No freaking way.
But I am spoilt, arrogant and kinda settled. Don't do like me :-)
This is a great response. And yes, in case it's not clear to anyone reading, my "approach" is def influenced by the fact that I'm typically lucky enough (at this point in my career) to have companies/recruiters pursuing me. Obviously, if you feel that you really need the job, or if you are in the very-early stages of your career, you're prob stuck jumping through every single hoop they put in front of you. However, most employers aren't looking for "those" people. They're looking for the extremely-experienced, supremely-skilled coders. And when they're looking for that kinda coder, they're doing themselves a disservice by thinking that they can put up a huge set of obstacles for all of the candidates to jump through. Cuz the ones with options won't be bothered.
LOL, yeah... It's been a minute. Thanks!
I am wondering: do you have experience hiring people?
We do have a take home assessments, one for more UX oriented developers and one for more function (or technical) developers. These are extremely simple assessments that allow the developer to spend more time on it if they wish to do so. We allow it to be written using any programming language.
Our primary goal is to filter out people that don't actually know how to program. Our secondary goal is to see the developers 'handwriting' and style of programming. This allows us to determine how much time we will likely spend on educating the developer in the style of coding for our company.
We use this same assessment for freelancers. Here the secondary goal for new hires becomes the primary goal. This allows us to determine what role in which type of project they should have.
I've hired, or been directly involved in the hiring process, for more than a 100 people (easily).
I'm sure you believe so. And I might agree if I saw the assessment. But I have heard statements like these dozens of times - and they almost always end up being not-as-simple as the employer claims. For example, I was recently asked to do a demo app based on an existing repo - and the Webpack config was kinda jacked up. So I'd either have to burn time troubleshooting the Webpack config, or I'd have to deal with the repeated delays that were caused while doing the task because Webpack wasn't properly recompiling the app.
Maybe your take-home assessment is far simpler than that? No Webpack config. No frameworks. Maybe it's just, "Write a function that accepts X and returns Y." But if that's the case, there's no reason that you can't see them do that live.
And there's the rub. We swear that this is just a one-or-two hour task, knowing damn well that some people will take 8 hours to complete it (for whatever reason). And you won't even KNOW that it took them that long to do the task. They may have submitted an incredibly slick solution and they swear that it only took them an hour to do it. But how do you know if they're lying?? After all, you didn't watch them coding. So it could've taken them any amount of time. If the assessment is really so simple, and it took them a load of extra time, don't you think that would be value information??
This also puts the candidate in an untenable position. Maybe you claim that it should only take 2 hours. But at the end of 2 hours, they don't feel confident that they've truly completed the task, or that it's "clean" enough. Of course, they could just "put down their pencil" and submit what they've finished up to that point, but they also know that this will probably eliminate them. So instead, they sit up all night working (for free) on this assessment that you've sworn should be extremely simple.
I couldn't agree more. And that's why you should actually watch them code! If you've watched someone code for an hour, and you're still not sure if they know how to program, and you're still unsure of their 'handwriting' and style of programming, then something's really wrong with your evaluators. When you watch them code, it provides an assessment that's nearly impossible to "spoof" and it respects the candidates' time.
Thank you for taking the time to write this extensive reply! You certainly made me think, I will consider switching to this (or a similar) approach and discuss it with the other members of management.
The trickiest part I think about this approach is that some people might experience disproportionate stress, so making sure they feel at ease will be important. Especially ensuring that solving the problem is not the main goal of the exercise.
Thanks again.
I def agree that it's imperative to do everything possible to make the candidates comfortable. Much of that can be handled with the demeanor you employ when setting them up. But keep in mind that, even in the course of their "normal" job duties (if they were to be hired), it's not uncommon to have two coders working on something side by side (this can include "pair programming", but it might be as simple as someone helping you to troubleshoot a nasty bug). So it's not unreasonable to think that the candidate needs to be at least somewhat comfortable with having others watch them code.
@bytebodger Just letting you know that we are trying the live coding session next Friday with a potential hire.
Very cool!
Please lemme know how it goes. I'd be happy to hear any feedback you have on it.
@bytebodger
It went quite well. Our assignment however is not suitable for live coding. A big part of the assignment is to see how people find and apply documentation and information.
During live coding people feel some form of pressure (unless you have been working with them for quite some time) that prevents them from taking the time to think and read. So at some point I excused myself (it was a digital meeting) to allow the candidate to be on his own. While this was only 3 - 5 minutes, it helped the candidate to focus and read.
During coding there were a lot of excuses and even the phrase: "normally people only see the code once I have cleaned it up".
All in all it was a good experience. I will try it again next time, but I have to carefully redesign the assignment for this experience. I will most likely build in a break (even if it's not digital) at a certain point of the assignment. I might even go as far as breaking the assignment in different stages.
We did it for 1 hour which I think is too short to cover the different aspects of programming:
This is GREAT feedback! And yes, I totally agree that the nature of the assignment itself may need to be tweaked to accommodate this approach. Thank you for following up!
I also wanna make it clear that I don't think the one-hour time limit is sacrosanct. Yes, I'd prefer it be kept to one hour. But I realize that, in some scenarios, you may need more time. What's much more important (IMHO), is to have a set time limit. I firmly believe it's patently unfair to give someone an open-ended assignment, knowing that some people, (especially, desperate people), will end up burning eight-plus hours on the assignment you genuinely believe should take much less time.
I forgot to mention. For junior candidates we often do the assessment up front, before the first interview. For medior and senior we tend to do the assessment between the 2 interviews with more focus on the secondary goal.
And when someone "fails" your assessment (especially junior candidates), what kind of feedback do you give them on why their assessment failed??? Since you're giving all the junior candidates this assessment right upfront, I'm absolutely certain that you'd never think about silently eliminating them without at least giving them some kind of substantive feedback based on what they've submitted, RIGHT???
Haha, a lot of question marks.
But yes, most certainly. I (or my right hand) will call them personally to explain why they have failed the test. This only happend a few times, most likely because they were not completely honest in listing their experience or education.
I feel it is important to give them something tangible to work on. In a few occasions they even re-applied some time later.
My favorite coding assessment to administer is live coding of measurements and conversions. It is simple enough to be done in an hour, universal, and you can't be a good programmer unless you have an innate understanding of the topic.
Can you provide an example?
@bytebodger , Adam, this is a very interesting series. I'm working on a project to solve some of the issues you mentioned. Would love to dig a bit deeper into your ideas, if you can spare a few minutes for a chat. OK to send you an email?
Certainly
I couldn't disagree with this more, I firmly believe that Deliveroo have missed a trick by not requiring riders to be able to recite from memory the steps required to disassemble a derailleur gear, explain the differences in pad wear between disc and rim braking and be able to clearly articulate the practical reasons for frame colour choice. Clearly the interviewing team should review these responses and reserve the right to call the candidate back multiple times to describe the nuances of their answers.
Oh no.
That makes no sense right?
Next time I'm hiring I am going to do this ride along thing, before we've always asked people (who are definitely being interviewed) to talk through a project that they've built outside of test conditions but to my specs. I prefer your suggestion for sure.
I liked your article on how to hire programmers. I think you gave some good advice and tips on how to find and evaluate the best candidates. I’m curious about how you manage and motivate your programmers and what are the challenges you face. Do you have any resources or recommendations for finding programmers for hire? I would love to hear more from you. 😊
Loved this part...."If I truly wrote a solid solution in React/C#, do you really think it's gonna take me some ungodly amount of time to "translate" those skills into Angular/Node?? C'mon, mannn..."
I don't understand what's the obsession with the mighty TECH STACK, especially, in a web platform based products.....
Great post! What about meeting the team? Could be the best candidate but if it doesn't fit, it's a no go if you ask me
Agreed. And IMHO, this fits quite well with the post-assessment Q&A session.
I am sharing this as widely as I possbiy can. 10/10. Thank you * 1e12
My stupid grammar nitpick: " But you should really think about which tasks your asking of which candidates." your -> you're
Thank you! And I've fixed the grammatical error. I genuinely appreciate having that stuff pointed out, cuz I do strive to be clear in my writing. (Even if my chosen style is, quite admittedly, rather "colloquial".)