Recently I’ve heard interviewing being compared to a particle physics experiment. You throw a bunch of questions and tasks in the general direction of a candidate. You hope for some collisions with her paths of thinking, her skills and experience to occur. Then you analyze the little fallout these collisions produced and try to reason about much bigger and complicated things like the Universe or probability of this candidate being a great one.

This analogy suggests that there is always a random component present in the process and you can fail to spot a great developer just by chance. This still does not mean you should abandon designing and perfecting your experiment. I like the one we are using for spotting great Java developers at Base so let me give you some thoughts on some design details of our collider. It is obviously not perfect but it is one of the best I’ve seen so far.

Programming. Pretty high on our requirement list. Some companies still try to check this skill through various proxies – from checking certificates to talking about programming. Base is not one of these companies. One can say we try to evaluate if a person can code in a much more primitive way – we simply ask her to code and see what happens.

When you enter our formal recruitment process and arrive on site we ask you to code a simple task. It should take around one hour. It’s done in pair-programming-like setup but it’s obviously skewed toward having the candidate do most of the reasoning and actual coding.

Here are some thoughts on how we think about this task and what we look for:

1. Keep it real

We try to make the coding exercise realistic, mimicking a task you would encounter in everyday work. We don’t ask you to code a pure CS problem, we don’t quiz you over things that you would quickly google up in your everyday work. What we try to do is to use a moderately simple programming task to observe how you reason about a problem at hand. How do you structure your code, how extensible you decide to make your design upfront versus how often you refactor later?

We want to observe and discuss your personal struggle between YAGNI and design that is still open for future extensions. What is your personal take on that?

Do you leave huge procedural blocks of code annotated with //TODO refactor it or do you maybe over-engineer by providing three layers of abstraction to iterate over a list, because you are going to need to customize it in the future?

This is the element that most candidates, even the ones with a very solid background, have problems with. I’ve often seen programmers entering this “recruitment mode” during our interview and either racing towards a correct algorithm implementation while abandoning everything they know (and even use in everyday work) about code quality or doing the exact opposite – going after code with perfect test coverage, perfectly flexible design with infinite abstraction layers allowing one to morph this code one day into the ultimate reasoning machine able to compute “Answer to The Ultimate Question of Life, the Universe, and Everything”.

Try to strike a reasonable balance – one that is making you productive in everyday work and your colleagues not hating you when they need to develop or maintain your code.

2. Know your tools

When you join Base we give you the best tools because we believe these enable developers to move fast and produce better output. We hope you figured it out by now as well. So what is in your toolbox?

If you are to code something in Java do you use Notepad for this? Or maybe you installed a full-blown IDE but are still using it as Notepad?

Another things is that there are some powerful libraries in the Java world – do you know some of them, how do you quickly include them in your project? How about the standard Java API, can you work efficiently with it?

Have you heard of this magical place called the Internet? Does it help you with finding answers you need to complete a task? The setup of our interview is realistic so it of course involves a network connection. So don’t hesitate to use it if you need it – that’s what you would do in a real-life scenario, right?

3. Be utilitarian

There is a time constraint and the task is relatively simple for a purpose. It’s not that it is absolutely necessary for you to produce a complete solution in the given timeframe, but we hope to see you going strongly in this direction. It’s not so much about pace of coding or avoiding getting into unnecessary perfecting off irrelevant details as it is about your mindset and plan for implementation. Do you design top-down or more bottom-up, how long does it take you to produce at least the happy path solution for the task?

We hope for you to often have a bias towards an utilitarian perspective. Does your TDD help you or are you simply dogmatic about it? Do you optimize prematurely, are you getting lost in your code because you overcomplicated it?

To sum up, we try to perform our coding session in a realistic way with a setup that would mimic a good candidate’s everyday work and we hope she will also write quality code in a realistic way. What raises our yellow or red flags is overcomplicating, putting too much effort into polishing unnecessary details but also producing throw-away horrible procedural spaghetti. Between those two extremes lies a huge area. The key to cracking the Java coding interview is thus to find this sweet spot.

Want to give it a try?

Posted by

Adam Gatnar

Share this article

  • Damo

    Pretty damn good advice, I’d say ;)

    • Adam Gatnar

      Thanks, man!

  • Jacek Spólnik

    Many companies are crazy about hiding the details of interviewing stuff they have, hoping to find best talent considering all random factors. This actually gives pretty good way to prepare or even learn how to be better in what you do as programmer. Very nice article!

    • Adam Gatnar