I felt I needed to write this, as we have been interviewing for a bit in Cognitive Match, for various segments of our technical team and we had occasionally bad luck with the candidates who turned up. Having been on both sides of the recruiting fence in my life, I realise that a certain percentage of candidates actually fall into the same mistakes over and over again — quite likely I, myself, did that a few times! So more than anything else this is potentially a “note to self” to avoid these in the future, and if there are people out there who are willing to listen, well, you might want to have a read of this before your next interview — even more so if you’re applying for a job with us ! 🙂

Now, needless to point out, different companies have different requirements during their recruiting process, as such, what I’m talking about here is not a silver bullet, but having been involved with a few startups, I got the feeling it covers a certain segment of those.

First of all, if you are looking to join a startup, you must realise upfront that by sheer definition of the phrase “start up”, it means that the business you are joining is in very early stages of growth — as such, do not expect a huge infrastructure present there. While this might sound obvious, its implications don’t seem to be, having looked back at some of the candidates we have been talking to. The above phrase should be read: “you will be required to do more than just one single thing”!

If you are coming in for a sysadmin job, quite likely expect that you will need to not just look at monitoring tools and restart servers occasionally: you will quite likely have to write shell scripts, help us make decisions on how to roll out software, package it, version it, help us with our redundancy and capacity planning, make recommendations on failover techniques, BCP, HA and the list can go on. Even more, you might be asked occasionally to look at some of the application(s) logs or diagnose communication — this means either liaise with developers or take yourself the charge in looking into the product codebase and correlate log entries to execution and identify parts which are or are not working correctly. You might have to do some DBA tasks occasionally and ensure the databases are working smoothly.

If you’re a developer, you will be expected not to just write code in one language and fix bugs — you will quite likely need to be able to come up with designs, suggestions on technologies, ideas for improving the product. Help with the database design and potentially even the implementation. You might need to pull up your sleeves occasionally and dive into some complicated system setup and / or deployment, rolling out releases or bug fixes. Gone are the days when coders just write code, based on designs created by architects who never see the code!

So when you come in for an interview with our startup — or, as I said, any other startup for that matter — do not be surprised if I’m going to ask you about networking, about operating system internals, about bash scripting, database and so on. The reason why I dive into socket programming is because we actually use this actively — and whatever module you will be tasked with writing in the team will have to integrate with the networking module. If you are not aware of the fact that sending larger objects over the wire means more bytes being exchanged and that means higher time to get data from A to B (not to mention bandwidth overload!) then quite likely your implementation will not work that well with what we have already. If I ask you about the internals of the HTTP protocol is because, like any other internet/online startup, this is our servers’ main “contact” with the outside world, and if you can’t diagnose an issue with the wrong caching headers being sent out, you will be spending hours trying to figure out why certain requests don’t make it into your server!

I will definitely not make a big deal about someone who hasn’t used Spring for dependency injection in the past — though of course it would definitely help if someone already has that knowledge and experience — however, I will insist on candidates who are successful to have used thread pools, connection pools, object serialization, caching, buffering and so on. Even more so, you might be an absolute world-class C++ or Python developer — and I totally dig that, respect! — but if we are using Java and you haven’t touched that in years it’s unlikely you will be able to go through the interview process successfully! So don’t waste your time and ours on this — and sorry if you get rejected at step 0, but since you wouldn’t use a plate to drink your coffee from (even though it might be the best Chinaware!), I’m not willing to hire a non-Java developer for a Java position.

There is of course the potential exception of a junior development role in which I test candidates for other things, mainly their capacity to learn and adapt — and indeed, in such cases, your knowledge of technologies and languages will not be that relevant. However, as with most startups, there will be very few junior positions and/or internships — as a startup you cannot afford too many juniors in the team, that’s a given: you want people who can pull up their sleeves from day one and start helping you build.

So getting back to the developer interview: I am definitely not trying to show off when I’m asking you about the java.util.concurrent package! I am not trying to tell you that I’m cleverer than you, because you see, you still use the (old?) synchronized keyword, whereas we use ReadWriteLock’s here — no! I’m asking you this because our code is probably “decorated” with these constructs — and if you don’t understand the basic principle of these classes you will find this a very steep learning curve. Steep learning curves work well for some individuals, but in 9 times out of 10 this will come with a cost to the team and to you, and I have seen this before: you will find yourself pestering other members of the team constantly about why certain things are done in certain ways, or you will find yourself spending numerous frustrating hours google-ing and prototyping class by class until you understand these things. And while doing so you will miss your deadline, delay the product release, delay another team from reaching their goals and the list can go on.

I am all for the team constantly learning new things — but as it is with Maslow’s pyramid, in order to get to the next level, I expect your base to be solid. And the “base” means different things to different companies, like I said — in my case, it includes the things I’m asking you about during the interview.

Don’t fall into the mistake of thinking though that I expect you to be just a good coder and know the JDK API by heart — I personally don’t know it, that’s what the JavaDoc, the internet and all the other resources are there! (I do expect you to know there are collection classes though, libraries which deal with XML and JSON parsing, packages which deal with thread pools etc though!) I do expect from a solid candidate a very good understanding of the OO principles — and even more so, the Java OO principles. (Let’s remind ourselves that certain things work in other languages differently than they do in Java!) Unless I need you to write pure C-like procedural code (hmmm, unlikely!), I can’t see how you could code in Java elegantly if you don’t have a good understanding of the OO paradigm!

Pretty much every single application I worked on in my time had a database somewhere of some sort. More often than not, that is an SQL database — and I would expect my developers to be able to manipulate the data in this database by basic means of simple SQL — whether it is for the purpose of querying the data or modify it! JPA has its place in today’s world (unfortunately!) and even if you have used that your entire (Java) life, I still expect you to understand what’s happening under the covers and be able to diagnose the data directly, not through JPA!

Google, Microsoft and all the big guns out there can afford the luxury to test you on your algorithmic skills only — they do have the infrastructure which would allow an individual to spend countless months learning technologies and languages — but a startup can’t afford that luxury! I am not going to test you simply on how clever you are in coming up with an optimal algorithm, I will test you on how can you write the Java code which implements the requirements given. While I would prefer everyone in my team (myself included!) to always come up with an algorithm in O(logN) when O(logN) is optimal, we need to get stuff out into production quick — so O(N) would do probably! If we don’t deliver on time, if we don’t deploy our releases with new functionality on time, someone out there will come and eat our lunch while we’re still optimizing “stuff”! Stick to O(N) for now therefore and show me you can write the code such that at some point in the future, when this is hitting us big time, it would be easy to review this segment and improve the algorithm!

Have you used JBoss rather than Tomcat? That is not a problem — principles are the same, the configuration and tool would be different but the learning curve should be much easier than if you haven’t used any of these! And if you used JBoss than I expect you to know what does a container like these 2 offer and what their basic functions are. And you can’t tell me you’ve done web-based development in Java when your view of JSP, servlets and static pages is blurred. It’s great that you have used Struts or Spring MVC — but do you know what happens under the covers? Because if you did then you would know how to deal with a statement like “a JSP is always a view”!

And having just touched on the Spring/Struts side of things I have to confess to one thing: I hate frameworks! I really do! Ok, granted, that sounds a bit too harsh, but let me explain: it’s a love-hate relationship I have with these frameworks! And here’s why: assume every developer starts with a blank “canvas” and there are no libraries out there apart from the standard JDK. In that case, if you want to use a database connection pool, you would have to build it yourself. That’s a pain in the arse, I know! But part of doing so will mean that you understand personally what happens under the covers of your connection pooling library. And if you have to build a library for JSON parsing, you will also know at the end of it the JSON standards by heart and know all the insides of your library such that when it throws an exception you can just glance at it and say “oh yeah, the JSON syntax is wrong as it’s missing a comma/quote/whatever”. Now if we had that scenario, everything we build would take ages, but! Every developer who would have worked on a project would have good insights into how thread pools work, how JSON parsing is done, REST services etc etc etc. I agree that would be an extreme scenario to take things to — which is why I do tolerate frameworks (and I even find myself using them on a daily if not hourly basis). But what I hate about them is that they give birth to thousands of programmers who just know how to use some black boxes, with no understanding of what’s inside them. Those engineers would never work in my team, sorry! If you can bring a new technology to the team and explain why would we use it, what are the benefits and shed some light onto the insights of it (which could help in making a point about using it!) then you’ve pretty much won my vote of confidence! But if all you bring to the table is “in my previous job we used to use Spring MVC cause then you can do everything in JSP” (??? you mean you can’t have standard JSP pages on their own otherwise????) you are just saying to me out loud that you don’t understand really this whole Spring MVC “stuff” but let’s use it cause you always worked inside it and that’s the only way you know how to code.

Ultimately, I will test you on your code writing abilities in Java because I’m hiring you as a coder — don’t stare puzzled at me when I write you to write “proper” Java code on the board! After all, if you can’t write code… why are you applying for the job???