Do an interview for me. An alternative flow for conducting a technical interview with a backend Spring Java developer

Disclaimer: there is a lot of water in this article, the thoughts and experience of an inflamed brain are reflected, therefore I warn you in advance that you can simply waste your time in vain. From java there is generally little and basically everything is beaten.

What types of interviews have you done or arranged? I think no one will argue that no interview gives a complete picture of how the applicant will work, so here I will try to convey the idea of ​​\u200b\u200bone of my approaches to a technical interview. If interested, welcome under cat.

I have several tried and tested methods of conducting technical interviews with backend Java developers in my arsenal:

1. Questions and answers.

2. Tasks for refactoring

3. life coding

4. The applicant conducts an interview with the interviewer … (only available to seniors, leads, architects)

All 4 are relevant and reveal about the same thing. Why such a choice? Nothing to do There is a need to give the applicant the most convenient way to pass the interview in order to maximize the disclosure of his experience, knowledge, communication skills (soft skills are tested minimally). What I evaluate: how much you need to invest in a candidate before he is able to perform our tasks, what he can bring to the team/project and how he will fit into the team. What I want to convey: with whom the applicant will need to work, with what technologies, what tasks to solve. I emphasize that there are no bad candidates and employees! There is probably a coincidence in the stack, technologies, team … this is exactly the problem of a microscope if nails are hammered into it.

I’ll tell you a little about the first 3 types of interviews:

1. A long time ago, I deleted question-answers from the types of interviews I used, as it is boring, inefficient, and in general, you can learn all the typical questions. Somewhere on the github there are even repositories about these OOP and patterns. In addition to all this, I myself very often had to go through interviews in this format and often there was a slight feeling (and sometimes certainty) that I was being tortured … Well, such an interrogation, just a thermorectal cryptanalyzer and a lamp in the face were missing. When all this is also happening with a bunch of 6 people, you hardly remember how HashMap dodges an algorithmic attack on a hashtable or some kind of tree in a TreeSet. I also didn’t like the fact that the interviewers didn’t want to have a dialogue and answer counter questions, retorting that there wasn’t enough time (one feedback was: I started interviewing in the opposite direction, confusing the interviewer, um, there were actually 3 of them , to see a piece of paper was one). After a while, I had an interview with Sergey and Anton from the Kazan Express company, where we talked more, but I noticed how they ask questions, how they listen, wait for questions themselves, enter into a discussion of solutions, and yes, I felt that the questions were from their production , therefore, in this way they understand: whether the applicant will solve their problems.

2. I use refactoring with Anton’s permission. He did not conduct a full-fledged interview with me, he simply threw off the tasks, but someone uses them without his consent))). Tasks in vanilla Java, but with several levels of complexity and understanding, i.e. in each task there are several levels of problems, which, depending on the experience and knowledge of the candidate, will be solved in different ways. There is clean code and clean architecture, but in practice, and not “tell me about L”. True, I add this approach with more questions about Spring, databases and a number of other technologies from our stack, but there are very few. Sometimes I mix something like this into the refach itself: what if you have Spring, how?

3. Live coding was stolen from Alexander from one bank (a colleague wished to remain anonymous). The bottom line: we solve a business problem close to practice, the interviewer throws in requirements, looks at how the applicant solves it, how he can think locally in code and architecturally, how he solves problems with his hands, that is, it doesn’t matter whether the applicant knows the names of microservice patterns or not, the main thing is how he thinks and can solve problems. Of course, the variability here is a little less than with questions and answers, but you can throw different cases on different levels: somewhere for patterns, somewhere for blocking. I adapted this approach a little to my needs and I definitely take the same Spring for development, throwing cases that can be solved using its capabilities, but adhering to the original mainline while preserving the idea.

In principle, one could stop at this, but sooner or later, like a lazy Kazakh, I got tired of conducting interviews myself, but I decided that it might be interesting for applicants of a strong level to interview me, but who am I in general to ask questions in an interview ?! And so the idea of ​​flipping the interview was born.

Of course, even strong applicants often choose questions and answers, less often refactoring, even less often life coding, well, only a few chose the strangest option.

How the interview is structured:

1. Company story.

2. A story about the stack with which to work.

3. What business problems are to be solved.

4. Applicant’s story about himself.

5. Directly the interview itself by the applicant of the interviewer.

6. End of the interview.

The skeleton is simple, but the devil is in the details: at the second point, the applicant understands what he will have to work with: what versions of frameworks / data stores / orchestrators (or without them) and so on, that is, already at this stage, the applicant can roughly understand which questions are better to ask, so to speak, which questions are closer to the topic.

The most interesting part, of course, is the interview itself, and here the interviewer needs to:

1. Be prepared for various questions.

2. Ask counter questions in the subject of the applicant’s question.

3. Be able to admit that the interviewer himself does not know something, and ask for clarification.

4. Trying to smoothly lead the interview in the right direction if the conversation went completely off topic.

Usually the first questions of the applicant are those that caused itching and irritation in past interviews he had once been asked in previous interviews at other companies. Yes, this is where multithreading, garbage collection, and various puzzles begin (like: how to filter values ​​in a stream without filter) …

List.of(1,2,3,4,5,6,7,8).stream()
.flatMap(h -> h % 2 ==0 ? Stream.empty() : Stream.of(h))
.collect(Collectors.toList())

So to speak, one has to receive in full for all those who tormented him with all these questions earlier. Of course, here the interviewer can swim too, well, I sometimes swim, because I myself don’t ask such questions at social security in principle.

When the vengeance has already passed, the aspirant drops all this husk, as he begins to ask questions in which he is best versed, or at least considers himself competent in them. For example, the basics of a programming language, framework, database, system design, design patterns. Thus, the applicant shows his experience and depth of knowledge within the stack.

Then questions on the stack may end, and the applicant begins to ask questions outside the technology stack: about orchestration, Linux administration, database backups, how to live in a modern eventual consistency world, soft skills, and so on. With these questions, the applicant shows his horizons.

The questions may end there, or they may continue, but the approximate classification of questions and what can be understood from them about the applicant, I think, is clear.

The main thing is to additionally play along with the applicant and motivate him to explain to the interviewer why he answered incorrectly, otherwise you can go into the option of conducting an interview in interrogation mode or fly away to higher matters. You also need to follow the timing and answer questions as clearly and concisely as possible.

Naturally, I myself may not know much or nothing of what the applicant will ask, but this is cool. After all, if the applicant is above my level and is ready to work with me, then he will give a lot to the company, the only question is whether he himself wants to work with such a colleague.

Of course, one can object: how can you know if the applicant understands enough about what will be needed for the job? But a counter question arises: does any other interview reveal everything well enough? If the entire interview was spent in solving the problem of balancing brackets in different ways, or we talked about ephemeral architecture, and, for example, we need a person to code business tasks, then in our team, in the position for which the applicant is applying, he may not feel very good comfortable, or he is simply poorly versed in what we use for work. Either way, it’s a mismatch.

One can argue endlessly which interview option is the best, but, of course, to each his own, and the silver bullet is so … or rather, there is none.

Perhaps this article will help someone apply this approach and find a great employee. I will be happy about it!