Landing That Dream Job

I’m currently looking for my next dream job (sidenote: if you know somebody who wants to hire an experienced Ruby programmer to write code in any functional language, let me know), which means I’m doing quite a few job interviews. Knowing that most of them will be inconclusive I can approach them casually and treat them as a learning experience. Here’s what I’ve learned so far both applying and recruiting people.

Coding exercise

There are two types of coding exercises. First is where they send you a description of a problem you need to solve and you send back the code. Things they expect in your code:

Tests. If you didn’t send any tests along with the code, that’s a straight no-no. Also, even if they did accept you, you wouldn’t want to work in an environment where it’s okay not to write tests.

Instructions on how to run the code that you’ve sent. If it works only on your machine, it doesn’t work. If they need to debug issues with it, it’s your fault.

Documentation, where appropriate. If you’re writing a simple Rails app, you can get by with proper naming and just a short README. If it’s a general use library, you’d better document its API properly.

Code design. Whatever the problem description is it never means “hack together a quick procedural script”. If you’re gonna be writing object-oriented code if you land this job, make your code object-oriented. Name all the classes carefully. Use meaningful method names. Make the code easily extensible. Use proper design patterns. If they care about code (and you want to work in a place where they care!), they’ll analyse it six ways to Sunday.

Performance. We all know premature optimization is the root of all evil. Except when it’s not. Then premature optimization is THE SHIT. It’s important to know the difference.

It doesn’t matter that the problem description doesn’t say “this needs to work for arrays with more then 1 000 000 elements”. Assume that it does. If you use an array where you should’ve used a set, you might blow it. If you assume that input data’s small and there’s no problem iterating it n times, you’re definitely gone.

Anything. Whenever you question yourself “do they expect me to…?” the answer is a definite yes. If you’re not sure (or if it’s a lot of work to handle a specific case), ask. Unless the question’s ridiculous, you’ll show that you ask for clarification when necessary.

In general, don’t treat the coding exercise they send you casually. It needs to be the best code you’re capable of writing, because it’s gonna be judged as such.

Automated programming tests

The second type of a coding exercise is when they give you a URL to a coding exercise service. You get a problem description, sample input & output and a textarea to put your code in. Here’s what you need to keep in mind:

Code design. Although it doesn’t matter much, make sure you’re code’s readable, as they WILL take a look at it to see what you did. Throw in a couple of methods with helpful names into your hacky procedural script. Nobody sane will judge your code design on a sample you wrote in a textarea on a website.

Performance. Matters a lot. Even if they have multiple testcases that say they check large data inputs and your code passes with flying colours, it doesn’t mean anything. You might not traverse the input array n times, but you might do it twice when once is enough. You might store values in a hash, where in reality you only care about the keys, so a set would be enough. Such mistakes might let your code pass the testcases, but still fail the review.

Tests. There’s no way to attach them to your solution anyway, so it’s up to you to write them. If it makes you write quicker or better, use them. Otherwise, don’t bother.

Interview

Show that you’re a nice person. They probably don’t want to work with jerks and on the off chance they don’t care, you do. Working in a hostile/uncomfortable environment is seldom worth it.

Show that you care. Research the company before, try to use their product, mention any experience you might’ve had working in the same industry. It displays your commitment and enthusiasm. This stuff is important to them.

If you don’t feel any enthusiasm about working with them, the whole recruiting process is a waste of your time anyway as you’ll get bored and start looking for something new soon. Or worse, you’ll be stuck doing something you don’t enjoy for eight (hopefully) hours a day.

Ask questions. Usually the first part of the interview is about showing how awesome you are and the second is making sure they are as well. Ask them about everything you care about. For example, I care about remote work, holidays, overtime, test coverage in the codebase I’ll be working with, team structure, decision making processes, etc.

Clarify stuff. If they tell you, for example, that they’re “flexible about working remotely” make sure if that means you can work from home all the time, or that you can work from home (only) when your water pipe breaks and you’re waiting for somebody to fix it. Also “unlimited holiday time” might mean something different if you want to go for a 4-week trek in the Himalayas.

Talk about money. This subject should pop up in the first interview. Either ask them what’s their budgeted salary for this position or let them know what your expectations are. Avoiding it is just a waste of time you put into the recruitment process. Always be prepared to answer what your salary expectations are. If you don’t know the market at all and are afraid of shooting in the dark, you can say something along the lines of “I haven’t really thought about it yet, but I’m sure you’ll offer me a fair market salary”.

Also, never start the interview off with your salary expectations. Even if that’s what is most important to you about the job.

Be prepared to say “I don’t know”. For any technical questions “I don’t know” or “I haven’t worked with that technology before” are valid answers. They might not score you many points, but trying to lie that you’re an expert when you have no knowledge of the matter will blow all your chances. Unless they’re just as clueless as you are. In that case, you don’t want to work there.

Final advice

Don’t treat rejection personally. You’re not a good fit for every single company out there and neither are they. They might be looking for someone cheaper, or more experienced, or willing to work overtime, or more independent, or more team-oriented. You never know.

Also, in case you do get rejected, ask for feedback. Especially if it’s because of a technical interview or a coding exercise. Sometimes you’d never guess what was your mistake. They might never answer, but just as well they might.

Written by Wojciech Ogrodowczyk who takes photos, climbs mountains, and runs Brains & Beards to help companies deliver better mobile applications faster.