Code Test Overview

[00:00:00]
>> Let's talk about the code tests. The code tests is, depending on the company, is something that they give you. It's probably gonna be a multi hour project, maybe 5 to 10 hours, somewhere in there. But they want to see how you code in a larger environment. Code tests are something I personally am on the fence about.

[00:00:20]
If someone has a robust GitHub or a history of delivering projects, like yeah, you worked on that project, okay. I can check out their GitHub, I may not do a code test. But there are plenty of companies you'll get a code test for. Here are some of the things, certainly some of the tips you want to do.

[00:00:38]
Tip number one, if you ignore everything else I say, follow this. Make your code as readable as possible. Don't try to be clever. No one's gonna applaud you for using double tilde instead of math.round. Yeah, it looks cool and you're like, wow, look how they're gonna see how smart I am.

[00:00:56]
If you're reading through many code reviews, you're not gonna want cleverness, you want readable code. As an engineer, if I'm reading someone's code review or reviewing someone's code test I want to see do they know the code. It's this type of code I want to see if I come up in my code base itself.

[00:01:11]
These are the kind of PRs I want to review. That's it, don't be clever, just get it done and make it readable. And comment your code. Until the day I die, I'm gonna say comment your code. Funny enough, not everybody agrees with me on this. Some people say, code should be self-documenting.

[00:01:29]
People say that all the time. Cool, make it self-documenting, but also comment your code, that's it. Especially if you're reading a lot of code tests. Comment you code, it makes it easier to understand. Okay, I don't necessarily agree with the way they're doing things, but I follow their logic.

[00:01:42]
Because they told me what they're doing and I don't have to take time to figure that out. Because if I have to take time to figure it out, I'll probably be like, this is too complicated, next. That's just how it goes. You're a busy person, I'm a busy person.

[00:01:54]
Just make your code readable, and comment it and don't over complicate it. It's tempting to try to be like I said, clever. Just make it simple, the best code is the simplest code. The best code is actually the least amount of code. If someone blows up something and it's six different functions, and it doesn't need to be, that's overcomplicating it.

[00:02:13]
Keep it clean, keep it readable, don't make it too wild. Don't import too many libraries. Libraries don't tell me what you know. They tell me that you know how to Google things or you know how to use what other people know. Which is a skill too, but in this particular test I'm trying to see do you know what you're doing?

[00:02:29]
Do you know how to code? It's okay to import a library here and there, depending on what the people who is giving the code test are. Some people say no library, some people say do whatever you want. But even if they say you can use React or Angular or Vue or whatever you want, I wouldn't go overboard on importing libraries.

[00:02:45]
It's better to keep it as simple as possible. I generally stick to Lodash, just utility functions. I could code up these utility functions, but it's nice that someone did it for me. But they're not cheating anyway. If you have any time at the end, as a cherry on top, add some unit tests.

[00:03:04]
This person is a well rounded engineer. They don't just think about getting the job done, they think about maintainability. They think about how this code is gonna live over time. And if you have any questions on the code test, ask questions. I know, if you have questions, ask questions, but you often don't.

[00:03:18]
Feel free to email that person back and say. Hey, I have a question on, I don't really understand the requirements, or this is unclear to me, ask questions. It's better to ask questions ahead of time, you won't look silly. Than to do the code test and it's completely wrong.

[00:03:32]
And they're like, well, at best we're gonna ask you to redo it. At worst they're gonna be like sorry, no, next. And you wasted your time, you wasted their time. So ask questions ahead of time.