Skip to main content

About job interviews… and why they (usually) suck.

Almost every programmer starts his own career with a job interview. First step – phone call. Next is Skype call, few technical questions, maybe a little coding session. If You’re good enough then You proceed to on-site tests. And there You have to do the same thing again: answer many technical questions and write some code. The problem is that this entire process costs time (and, in result, money) and usually is pointless.

What are they looking for?

After quite a few interviews I realized that the majority of recruiters don’t care about intelligence, self-sufficiency, cleverness and basic understanding of a problem. They only want to know if You know answers for their, strictly technical, questions. Let’s consider a simple example.

Please imagine that the recruiter wants to know if you are familiar with transactions in Java. What will be his question? In 90% of situations he will ask: “Do you know @transactional annotation?”. You don’t have to think, solve any problem, anything like that. Just answer the question, recite the definition and move on.

How should the proper question look? “Imagine that you have a service method that modifies many objects persisted in a database, one after another. You know, sequence of actions. Something went wrong and in the middle of execution an exception has been thrown. How would you take care about rolling back application’s model to the latest stable state?

See the difference? Next question could be: “How would You solve the same problem in Java?”.

Recruiters shouldn’t be checking if the programmer knows given solution of a problem. They should check if the programmer knows any good solution and, if not, if he can deduce something on the fly.

Speaking of @transactional question. What if the programmer knows how to open and close a transaction in Java but he doesn’t know that there exists @transactional annotation that does it automatically? Well, it depends on the question asked by the recruiter.

In case of the first, strictly technical, very specific question – programmer will not know the answer. Recruiter will think that the programmer does not know the mechanism behind transactions.

What about the second question? Programmer knows how to solve the problem, knows transactions, maybe he will offer few different solutions, describe benefits of each one. And definitely he can catch up with @transactional annotation in literally 5 minutes.

This is what I hate in interviews. Majority of recruiters don’t test my skills, they test my memory. I have an API, IDE, Google, I am able to find answer to any technical question in less than 5 minutes. What I cannot do in less than 5 minutes is learn to think about problems, analyze them, find solutions and compare them.

Recruiters should be checking if the programmer knows how to approach the problem and find the best solution. Lack of knowledge can be filled up in 5 minutes in contrast the lack of cleverness.

Funny interviews

Sentences quoted below are real.

Situation 1

“Do you know book X written by Y? How many technical books have you read over last 3 months? And over last year? Could you give me 3 titles?”

In my life I bought around 5 technical books. Now I see that only 1 book was worth buying. “Clean Code” by Robert C. Martin. The rest was obsolete. Why? Because majority of books just copy contents of API descriptions, online guides, webinars etc. It’s available for free online. Another thing is that technology changes so fast. You finish reading “Django 1.9 recipes” and after 2 months you have to grab “Django 1.10 recipes” because new version of the framework has been released.

Anyway, what’s the point of asking the programmer if he reads technical books?

Situation 2

I have been classified as a regular Java developer because I didn’t know framework known by the recruiter. Despite the fact I have answered all other questions. So remember, if you don’t know something that recruiter knows then your seniority becomes lower.

To be more precise – recruiter didn’t ask about Spring or Hibernate. He asked about Grails. You don’t know Grails? You can be mid-level Java developer at highest. Ridiculous.

By the way, Grails is a Groovy web framework, it’s not pure Java thing. So why asking about that during Java interview?

Situation 3

This is the funniest one. During the interview I told something like: “now you are going to ask me about X”. And… I was correct! Interviewer gathered questions from one of the very first web pages found after typing “Java interview questions” in Google and he read them one by one. It seems to be quite unprofessional. Luckily I was aware of those sites, I have studied them many, many times.

Anyway, the interviewer was stunned. Priceless.

Smart recruiters

This is my subiective opinion on what should or should not smart recruiters do:

  • Do not ask about the API. “Is there a method named Foo.doCalculations or Foo.calculate?” Does it matter? I can check it in the API or ask IDE. Solving this “problem” takes less than 5 seconds.
  • Be proficient in the area you are asking about. Another problem is that recruitments are often run by non-technical people. It leads to stupid, strictly technical questions downloaded from the internet.
  • Test candidate’s ability to think and solve problems without spoiling any solution.
  • Ask about general concepts (thread pool management, reflection) rather than specific implementations. Details might come later.

Simply ask yourself what kind of questions would you expect from the recruiter.

Marcin Skiba

Marcin is a full stack software developer based in Łódź, Poland. He loves to learn new technologies, improve coding skills and share his knowledge with others.

Leave a Reply

Your email address will not be published. Required fields are marked *