Giving & Evaluating a Code Test

[00:00:00]
>> If you're giving a code test, which probably a lot of you have already. If you haven't, you probably will at some point in your career, you're gonna give a code test. These are things you want to do. Make the problem straightforward, as much as possible. It should be here are the requirements, bam, bam, bam.

[00:00:17]
Do they fulfill these requirements?. If it takes you 20 minutes to explain the problem, it's not a good problem. [LAUGH] It should take two minutes to explain what you're trying to do or it should be readily apparent. Have a read me with tips in there. If you wanna put in style guidelines, that's fine too.

[00:00:34]
But just make the problem straightforward and don't over complicate it. I once, so my gem stories, I once interviewed for or applied for our a role as a front engineer for a company. And they gave me a code test, it was, given this dot pixel image, so dot pixels, a lot of you won't know what that is, but it's an image made up of tiny little dots.

[00:00:57]
They're not so together, don't @ me on Twitter. I know all images are made up of tiny little dots. But this is made of larger dots. And the idea was, you had to parse this image, which I know nothing about. You had to parse this image and then create Conway's game of life so that in 1000 iterations it created this image.

[00:01:17]
Real interview question. These are skills that I did not have at the time. I didn't know how to parse an image, never read an implementation of Conway's game of life, let alone getting it to run backwards. That's not necessarily a good code test. Maybe it was for that company.

[00:01:31]
It wasn't for me. I just didn't even do it. Nothing wrong with that. And if you get a challenge that you're like this isn't good. I don't agree with this. You don't have to do it. You don't have to kill yourself on it. It's good to take on all challenges.

[00:01:47]
But if you feel like this is insulting or this isn't relevant to my skill set, you don't have to do it. It's okay. And give them that feedback. If you can say like, I don't feel it's relevant in my skill set, be polite about it, but that's fine.

[00:02:01]
But if you're giving the code test what I really want people to do and this is something we don't do at all, be honest with the time constraints. Here's a code test, it's gonna take five to seven hours. I usually double whatever they tell me it's gonna take.

[00:02:15]
If they say it's gonna take ten hours, it'll probably take 20 hours. And think about empathy. Would you wanna be on the other side of the table, you're looking for a job, and someone's like hey, here's a code challenge that's gonna take eight hours to complete. That's eight hours of unpaid labor that you're doing, and it's gonna take them more than eight hours.

[00:02:31]
So try to keep it down to the two to three hour range, something you can complete in that. And if possible, give them the option. This is one of my favorite things. Give them the option. Give them say hey we have a code test gonna take two, three, four hours.

[00:02:47]
Or we have a phone screen, it's gonna take an hour. Because different people have different strengths. Some people, live code wanna get it done, they're great at that. Some people, they get anxiety, they get nervous. So in that case give them a code test, give them something they can sit down research, figure out how to do.

[00:03:03]
So if possible, give people an option. I think we should all be doing that as engineers because sometimes I'm in a hurry. I'm like, let's just get this done. Give me the phone screen. Sometimes I got time and this is really important to me. I'm going to show you what I can do.

[00:03:13]
I'll do the code tests. Importantly, have a code review checklist. It should look something along these lines. So as in have a rubric that you can apply to everybody. So in doing this, you remove any bias you have, like, hey, this person's named Jem too, so I bet they're gonna do pretty well at this code test.

[00:03:34]
I already have bias there. Having a rubric that you can give to all engineers who are reviewing this code test means it's more than one person that can review the tests. It's not just one engineer and you can apply it fairly to everybody. They're exceptional, we wanna bring them on site immediately and if they pass, we're gonna give them very high salaries, they did really well.

[00:03:56]
Well what makes them exceptional? What are things you consider to be an exceptional engineer? Well if they're average, that's fine too. Are you looking for average engineers? Yeah, maybe. Or maybe you're like I only want top tier, exceptional or bust. That's on you. I'm not gonna tell you how to hire specifically, but I can tell you how to the interview.

[00:04:17]
But doing stuff like this is again things that larger companies have down, they've got every company for something like this where they should. Start ups, it's a little mixed bag. And this is a point that has gotten me before because if I use a say ES2019 or a ES2020 in my scripts and the person doesn't understand that, there might be like, this isn't JavaScripts, fail.

[00:04:44]
But if you have this rubric of like, hey, I don't really get this, but they use advanced features. That's cool too, put that under good. Yeah, but you just want a level playing field, you wanna make it as predictable as possible when you give someone a code test.