12 Questions to Ask Potential Employers

Original author: Amber Wilkie
  • Transfer

I just completed the six-week process of finding a job as a middle-senior developer in the market, where an active talent hunt is currently underway (Amsterdam). In other words, I visited a bunch of interviews. In order to accurately scout which companies are most suitable for me, I tried to ask more questions. Here you need to find the right balance based on your needs and the one who communicates with you.

If you are a junior in search of work, then you may come to the conclusion that you really are of little interest, that they will answer all the questions below - you should at least get somewhere. But even in this case, decide for yourself what moments will be stop signals for you and ask with the expectation that the necessary information will pop up. If there is something that can force you to refuse a vacancy, it is better to find out about it before accepting a job offer.

Standard Steps

In my experience, the selection process usually goes like this:

  1. Phone conversation / sometimes 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 bombard them with questions).
  2. Technical Interview. This is followed by a series of interviews already strictly with a team of developers who will thoroughly analyze what you know and what don’t.
  3. Test task / "homework" / co-writing code. In my eyes, companies that have introduced co-writing code for candidates immediately earn a lot of extra points. I understand why many give a “homework”, but in most cases it’s a waste of time for both parties - not the skills that are really needed come to light.
  4. The final meeting, getting to know 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 recruitment may be slightly different, but in general terms I have listed everything that should be expected from the employment process.

Questions for HR

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

A conversation for the most part should revolve around you. Of course, they already have your resume on hand, but they will expect a short story about you - be sure to prepare a short, succinct and informative description of your professional history. Until you talk, you have to repeat it as usual.

How do you select candidates?

Most likely, they themselves will write to you what will happen next, but if this did not happen suddenly, specify which stages are carried out in this particular company. If you do not have serious intentions regarding this team yet, and they intend to ask you to write a full-fledged application as the next step, it is more reasonable to say goodbye right away.

Tell me in a nutshell about the development team.

How many people are there, what is the proportion of juniors and seniors, how is the internal hierarchy built up (does the company have a technical director or a product owner)? Such questions are usually easily answered even by a personnel officer. If not (this sometimes happens, especially in large corporations) - well.

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

Questions for a technical interview

This is where I put the bulk of my questions. The employer evaluates you, but you also evaluate it in parallel. Let the interviewee talk, but don't be afraid to insert a question or two along the way. At the end of the meeting, they usually ask if you have any questions, and at this point you can ask whatever you see fit. If the answer is not too interesting for you - do not ask. There is no point in wasting your own and other people's time on reasoning that will in no way affect your final decision.

I have arranged the questions in order of priority for me personally. If we easily found a common language with the interviewer, I usually did not get to the last items on the list. If the conversation was difficult and not too comfortable, I went through all of them and hoped that I would better get along 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 exactly they will expect from you. If the interviewee could create an ideal candidate for this vacancy from the air, what would he be? In some cases, it’s like a mirror will be shown to you, in others - a lot will not fit into your experience, set of skills and preferences. This is a good way to understand how well you fit into the team.

For example, in one company I was told that they need a person who "will cope without much help." This is a bell for me. 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 transferring skills, I consider this a serious minus.

However, I often heard that the ideal candidate will be able to "work independently" and "set goals". This, in my opinion, is a good sign - I consider myself to be such an employee and do not like it when someone digs in and tries to forcibly organize my work process for me. These two answers seem to be essentially the same, but the way the information is presented tells a lot about the difference in working conditions.

What is the most difficult thing about this post?

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

Who defines the overall vision in the company?

Here I am trying to understand whether the company has any long-term plans and, ideally, talk also about development goals and directions. The only answer that I perceive as an alarming sign is the lack of an answer. “Founder” is a perfectly normal option for a small team, while “advice” or “management” is larger for companies. If everyone considers themselves to some extent involved in the formation of a vision and a roadmap, this is the highest score. The misunderstood views suggest that it is bad - it is advisable to work with those who at least have an idea where they are moving.

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

This question also relates to the workflow. I want to understand on the basis of what they will judge my work and the work of my team. If the interviewee finds it difficult to answer, I go on the other side and ask by what criteria 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 “overwhelm the task,” then nothing worth the wait. How can you successfully fulfill your duties without knowing what is meant by success here?

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

It’s great to be able to ask these questions to several team members. One should immediately follow the other (I prefer to start with a positive). Often, you can easily trace patterns - people are infuriated by the same things. It is usually difficult to bring an employee to talk about negative aspects, but, in my experience, with this approach they rarely manage to hush up the topic.

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

Tell us how code is inspected.

Here the answers are mostly concise - they use Pull requests, the Code Review option on GitHub or elsewhere. Try to delve deeper into the topic and find out what comments are being made, how long it usually takes to merge with the main branch. Do they really find fault? Or vice versa, even serious errors are missed? Are employees really rooting for the product or just love to flaunt their knowledge? What about testing? How often do releases happen?

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

I want to understand where the ideas come from. Does the team study the relevant data and then act on the basis of it? Or something comes to the founder’s mind, and the rest will perforce adjust?

This question has something in common with that which concerned vision; it can be set next, as a logical continuation. Suppose you have a vision, but how are individual 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 do not ask it in plain text and, accordingly, do not get anything beaten up in response.

Tell us about a technical issue you’ve recently encountered.

If the previous question turned out to be too complicated for them, this one will be simpler - I just ask you to give a concrete example from the latest tasks. The team coped with the situation jointly or was someone looking for a solution? Have developers resorted to any external resources? Or did they end up thinking 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 course of affairs? How are new developers being introduced to the team?

I consider this question not too significant, unless you yourself are a junior. Juniors should look for places where the support and even training of new employees is serious. Mid-level developers and seniors may ask just to find out if something is being done on this part in principle. For me personally, it’s important whether the company thinks about what the beginners have to do, or try to somehow facilitate the adaptation process. Of course, the answer “no” does not oblige you to break off relations with the employer, especially since so many will answer.

Here, I like to ask if they even hire juniors in the team and how they work with them, but only in those cases if we have made it clear that I myself do not belong to them. I have about three years of experience behind me, and I would not want to leave a false impression. More advanced developers can ask similar questions without fear that they will be mistaken for a junior - the answers allow you to judge how much the company appreciates employees.

Questions for the closing meeting

In the last stages, you will probably already talk about what your salary will be and when you will leave. If you are offered, find out all the conditions - bonuses, benefits, promotions, leave, date of employment and so on. But there is another potential question that can be asked with great caution, if the atmosphere is good for it.

Is there some kind of domestic policy that I need to keep in mind?

In large companies, they can point you to the sales department and say that they are gods here and it’s 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 am here the first day." Who actually rules the ball? Maybe there is some kind of project that some consider useless, while others adore? If at this stage they show you 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 rub in with different people with whom you have to contact.

And the last

Each of these questions can be the beginning of an interesting conversation. Do not take it in such a way that you must necessarily move strictly on the list. Start with what seems most important or informative to you, and then look at the situation. Where it is better to come to a thorough bilateral discussion than to just throw 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 eyeliners suggested above are just a help to get started.

Good luck in your search!

Also popular now: