12 questions to ask potential employers

I have just completed a six-week job placement process for a middle-senior developer position in the market, where an active hunt for talent is currently underway (Amsterdam). In other words, I visited a bunch of interviews. To carefully investigate which companies suit me best, I tried to ask more questions. Here you need to find the right balance based on your needs and who communicates with you.

If you are a junior in search of work, then you may come to the conclusion that you are in fact of little interest, that you will be answered to all the questions below - you could at least get somewhere. But even in this case, decide for yourself which moments will be stop signals for you and ask with the expectation that the necessary information will emerge. If there is something that can make you refuse from a job, it’s better to know about it before accepting a job offer.

Standard sequence of steps

In my experience, the selection process usually takes place as follows:

1. Telephone conversation / occasional meeting in the office. Usually, personnel officers are responsible for this stage. If one of the developers is involved, then the conversation, as a rule, turns out to be rather fluent (not the best time to fill them with questions).
2. Technical interview. Then a series of interviews follows strictly with a team of developers who will thoroughly analyze what you can and cannot do.
3. Test assignment / "homework" / co-writing code. In my eyes, companies that have introduced the practice of co-writing code for candidates immediately earn a lot of extra points. I understand why many people give a “homework assignment”, but in most cases this is a waste of time for both parties — not the skills that are really needed are revealed.
4. The final meeting, meeting with the whole team. If the company is small, this stage is sometimes replaced by a personal conversation with the founder.
5. A job offer.

Of course, in different companies the set may be slightly different, but in general terms, I listed everything that should be expected from the employment process.
')

Questions for personnel officers

As a rule, the very first interview is conducted by people who are not related to technical processes. Accordingly, it is inappropriate to ask them about the technology stack - they are usually not in the know, even if the company is small.

The conversation for the most part should revolve around you. Your resume is, of course, already in their hands, but you will be expected to have a short story about yourself - be sure to prepare a short, capacious and informative description of your professional history. Until you talk, you have to repeat it as a wound up.

How do you select candidates?

Most likely, they themselves will sign out to you what will happen next, but if this does not happen suddenly, specify which stages are carried out in this particular company. If you have no serious intentions regarding this team yet, and they are going to ask you to write a full-fledged application with the next step, it’s wiser to say goodbye right away.

Tell me a few words about the development team.

How many people are there, what is the share of juniors and seniors, how is the internal hierarchy built (does the company have a technical director or a product owner)? Even a personnel officer can usually answer such questions easily. If not (this sometimes happens too, especially in large corporations) - well.

Before you hang up, make sure you understand what awaits you in the next step.

Technical Interview Questions

This is where I post the bulk of my questions. The employer assesses you, but then you also evaluate it in parallel. Let the interviewer have a conversation, but do not be afraid to insert a question or two along the way. At the end of the meeting, they are usually interested in whether you have any questions, and at this point you can ask everything that you see fit. If the answer is not very interesting to you - do not ask. It makes no sense to spend your and other people's time on the arguments that will not affect your final decision.

I arranged the questions in order of priority for me personally. If we easily found a common language with the employee conducting the interview, I usually did not get to the last items on the list. If the communication went on hard and not too comfortably, I went through them all and hoped that I would get along better with the rest of the team.

How do you imagine the ideal candidate for this position?

I really like this question, because it reveals in a non-standard way what is expected of you. If the interviewer could create an ideal applicant for the vacancy out of thin air, what would it be? In some cases, it will seem like a mirror will be shown to you; in others, much will not fit into your experience, skill set and preferences. This is a good way to understand how well you will fit into the team.

For example, in one company I was told that they needed a person who “would cope without special help”. For me, this is a bell. Any developer starting to work with a new code base will need help to understand the business logic at its core, even if he knows all the technologies on which it is built. If the team is negative about the idea of ​​creating a comfortable environment for the transfer of skills, I think this is a serious disadvantage.

At the same time, I often heard that the ideal candidate would be able to “work independently” and “set goals for himself”. This, in my opinion, is a good sign - I consider myself just such an employee and I don’t like it when someone goes to bed and tries to force my work process for me. These two answers seem to be essentially different, but the way information is presented says a lot about the difference in working conditions.

What is the most difficult thing in this position?

The answer to this question very much depends on what exactly you will do. In any case, it perfectly helps to dilute the rainbow colors in which the rest of the conversation will be sustained. Take the employee’s opinion on what is most likely to cause problems, very seriously, consider whether you will be able to successfully resolve them.

Who in the company defines a common vision?

Here I am trying to understand whether the company has any long-term plans and, ideally, talk also about the goals and directions of development. The only answer that I perceive as a warning sign is the lack of response. “Founder” is quite a normal option for a small team, and “advice” or “management” is bigger for companies. If everyone considers themselves to some extent involved in the formation of the vision and roadmap - this is the highest score. Uncomprehending views suggest that the matter is bad - it is desirable to work with those who at least roughly imagine where they are going.

How do you evaluate the success of the development department and the company as a whole?

This question also concerns the workflow. I want to understand on what basis they will judge my work and the work of my team. If the interviewer finds it difficult to answer, I go to the other side and ask how they assess the work as unsatisfactory. In my opinion, if no one knows what is meant by good work, but everyone clearly understands what it means to “fill up the task” - nothing good can be expected. How can one successfully fulfill one's duties without knowing what is meant by success here?

What do you like most about working? What annoys you the most?

It's great if you can ask these questions to several team members. One must be followed immediately by another (I prefer to start with a positive). Often, you can easily trace the patterns - people are besyat the same things. It is usually difficult to bring an employee to talk about negative points, but, in my experience, with such an approach they rarely manage to hush up the topic.

It is unlikely that they will discuss with you the fundamental, systemic problems in the company's activities (although this happens), but at least you will better feel the specific difficulties of this particular team, whether it is labor organization, interpersonal relations or bureaucracy.

Tell us how the code is inspected.

Here the answers are mostly concise - they use Pull requests, the Code Review option on GitHub or elsewhere. Try to delve into the topic and find out what comments are made, how much time usually passes before merging with the main branch. Do they quibble badly? Or on the contrary, do they even miss serious mistakes? Do employees really support the product or just love to show off their knowledge? And what about testing? How often do releases occur?

Describe the process of introducing any new feature - how does it turn from an abstract idea into a backlog point, and then into code?

I want to understand where ideas come from. The team examines the relevant data and then acts based on them? Or something comes to the founder, and the rest are willy-nilly adjusted?

This question echoes the one that concerned the vision; it can be set next, as a logical continuation. Suppose you have a vision, but how are certain features planned and implemented? It seems to me that this question is closest to “how does it work here at all?”, The only difference is that you don’t ask it directly and, accordingly, you will not get something beaten in response.

Tell us about any technical problem that recently encountered

If the previous question turned out to be too difficult for them, this one will be simpler - I just ask you to give a specific example from the last tasks. Did the team cope with the situation with joint forces, or was someone looking for a solution? Have developers resorted to some external resources? Or did they end up with the thought of introducing this opportunity? Again, this question is useful because it demonstrates how the daily workflow proceeds.

Bonus: Is there any accepted scheme for introducing newcomers to the news? How are new developers embedded in the team?

I think this question is not too significant, unless you yourself are a junior. Juniors should look for places where they are serious about supporting and even training new employees. Middle-level developers and seniors may inquire just to find out if something is being done on this part in principle. For me personally, it is important whether the company thinks about what a beginner has to do, whether they are trying to somehow facilitate the adaptation process. Of course, the answer "no" does not oblige you to break the relationship with your employer, especially since so many will answer.

Here, I like to ask if they hire a junior team at all and how they work with them, but only in those cases if we have previously clarified that I myself do not belong to them. I have about three years of experience behind me, and I would not like to leave a false impression. More advanced developers can ask such questions without fear that they will be accepted as a junior - the answers make it possible to judge how much the company values ​​employees.

Questions for the final meeting

In the final stages, you will probably already be talking about what the salary will be and when you will go. If you make an offer, find out all the conditions - bonuses, benefits, promotions, vacation, employment date, and so on. But there is one more potential question that can be asked with great care if the atmosphere is at that.

Is there any internal policy that I need to keep in mind?

In large companies you can point to the sales department and say that they are gods here and it is better not to anger them. In small teams, as a rule, they assure that no problems will arise. In this case, you are interested in information from the category “I'm here the first day”. Who actually runs the show? Maybe there is a project that some people consider to be useless, while others adore? If at this stage you are shown some “dirty laundry”, this can be very useful in the first weeks. In addition, this question makes it clear that you are anxious to join the team and properly get used to the different people with whom you have to contact.

And last

Each of these questions can be the beginning of an interesting conversation. Do not take it so that you must move strictly on the list. Start with what seems most important or informative to you, and then look at the situation. It is much better to go to a thorough bilateral discussion than to pour questions.

Evaluating the company, I try to understand whether I will be comfortable here and whether I will arrange them as a subordinate and colleague. Good is the conversation that brings me to the answer to one of these questions. The above proposed liner is just an aid to start it.

Good luck in your search!