The other side of the desk

Originally published on Medium - 11th December 2018

Interviews can be intimidating, make no mistake about that. But what are we looking for with the various parts of an interview? I’ll break this into four sections… Culture, Coding Challenge (this isn’t actually done in the interview, but still very relevant), Whiteboard Coding and Technical Questions.

Culture

The biggest part of this is “can we work with this person?”. We realise you get nerves, so we do take that into account (although don’t forget, we’re evaluating how you cope under pressure too), but what we’re looking for here is how you hold yourself and you a fit culturally? Can you articulate your answers and statements. The stereotype is that coders are introverts and should be locked away in a room, but the reality is far removed from that.

Working for a consultancy, it is SO very important that you can engage with people you’re not familiar with. We are a team that prides ourselves on our ability to constructively push for change, to help uplift platforms in to more modern technology stacks, not just because as coders we like to work on the latest and greatest, but so our clients can benefit from that as well, faster turnarounds on bug fixes, enabling them to tweak things themselves, etc.

So yes, we may have never met before, but we want to engage. Throwing in a few personal stories from your career thus far is always a benefit — and the ability to laugh out loud is an added bonus!

Coding Challenge

While technically this isn’t part of the interview itself, it still is so very important. You’d be surprised at the amount of people that don’t take this seriously.

Yes, it may take up a couple of hours of your time, but if you’re serious, you get this done quickly and back to us to review. But what are we actually looking for?

In my personal opinion, I don’t care if you use the latest and greatest API’s and languages, or something that is ancient (well, nearly, no COBOL please). A good software developer can learn the newer stuff easily enough. We’re looking for good practices here. Some may care at particular companies, most shouldn’t.

Have you written tests for your program? Are you consistent with your formatting? Have you removed commented out code (bad developer! that’s what source control is for!)? Have you written comments explaining the WHY not the WHAT? We cry a little when we see code like:

let value = 0; // sets the value to be 0

Are your methods named well (naming is one of the tricky software development problems)? Have you documented any assumptions? Included a README on how to run your program (bonus points for having something up that we can run without even compiling)? Are you following proper SOLID principals? What logic do you apply and how do you think?

This could quite possibly be one of the most important parts of the interview. Having a taste of it before the interview gives us more of an insight and will help guide the interview also.

Also, feel free to use this as a learning experience for a new tool. I love seeing where someone said “I hadn’t used this before, so used it to learn”. But don’t forget good coding.

Whiteboard Coding

A lot of developers out there HATE this part, and yes, while it may not be a real world situation (or problem), we are TRYING to put you under pressure to see how you perform.

Perfect syntax doesn’t matter. Even using a real language isn’t important. Asking questions is good (eg. can the inputs be null)? Yes, certain languages may have functions built in that make the problem trivial, don’t use them, we want to see you think about the algorithm.

There are things that most people miss on these. Don’t feel like you’ve stuffed up here, this is by design. When we bring this up after you’ve written it, we’re seeing how you deal with suggestions and critiques. Once again, this goes back to “can I work with this person?”

Take into account what is said ahead of the problem. If we say don’t use something, or focus on this or that, we actually want to see that.

Technical Questions

Yes, we know you may look things up on Stack Overflow when developing in the real world, but we want to see you have an understanding of basic computer science. If necessary, go back to your school books and brush up (yes, some things asked are CS101 type questions).

Personally I may throw a couple of language specific questions in there, don’t be ashamed to admit your knowledge in that language is lacking. It’s not an issue. Like I mentioned earlier, things can be learned. However, if you have it listed on your résumé, you’d better know it (don’t worry, we’re not going to ask anything obscure).

As I said at the beginning, Interviews can be intimidating. The best trick is trying to relax. We WANT you to nail it, we’re looking to hire just as much as you’re wanting to get a new job.

We want to hear the times at your old workplace when things went wrong, nobody is perfect, it’s how you deal with it that is important.

We want to hear what you’re interested in outside of work. Even if you’re not coding in your spare time.

We want to see the real you.