I'll call you back
Hi, Iâm Katya, I found a job. And she wrote a training manual on communicating with the employer. Iâll tell you what to ask at the interview, what not to ask and how to do it right.
I drove the whole month through dogmas. I looked at both startups and Yandex. There are many companies, itâs difficult to choose. To find the one you need to consider many factors. For each company I compiled an individual list of questions. Universal framed in this faq. It contains the key questions of the applicant and their analytics. Some of the questions are tailored for developers, the rest will suit everyone. Go under the cut!
Hold the algorithm!
In order not to regret the choice. To find a company that will give you everything that you are looking for: tasks, prospects, conditions - we are not working here for money :)
Interview time is limited. We do not want to spend it on socially expected answers, excuses, unnecessary information. Getting the right one is not easy. You need to know where to poke to infa flow. And do not poke indiscriminately, so as not to drown in it. We will prepare subtle aiming questions. We will build a consistent meaningful dialogue on them.
The purpose of the article is to orient what to ask and why. There are no sacred knowledge and magic questions. Compose suitable based on the listed. Use the algorithm above.
I will help parsing the answers. Under each (not every) question there is analytics by parameters:
Analytics is not exhaustive and is based on personal experience. If there is no section, then I do not consider my opinion objective or I have nothing to add. My âGood to hearâ and âRed flagsâ may not match yours. Analytics is not needed everywhere: I donât know what is in your head, what you want, what you are looking for. Deal with this before you go to social security.
In the section "Wacky Questions" I have collected specific and useless. I do not like them, I have listed the reasons. If you want, use it.
I ran in 70% of what I wrote, the rest did not have time. If I'm wrong, it's not like that, it was different with you - write in the comments how it is right, this will help the rest.
âShow interest - ask about the company.â Bullshit. Not interesting - do not ask, google.
1. What do you earn? Which product is the main source of income?
2. In what areas do you work? What are b2b projects, b2c, R&D?
The recruiter will tell about nishtyaki. If something is especially important to you, specify.
Ask to show the office. Most likely show. Padded stools, kitchen, gym - cool if the workplace is also convenient. And then ottomans on the fifth floor, and you will work on the second, where the repair is going.
1. What affects my salary other than the increase? What does the premium depend on?
2. What are the incentives? How to deserve them?
3. What are the computers / laptops? Can I work for them from home?
4. Are you sending guys to the conference? And international? Where did you go last time? How is it decided who will go?
1. How many people are in the department? How do they communicate? How closely interact?
2. What teams are the developers divided into?
3. How many people have been working in the department for more than 3 years? There are such?
Teams are similar in composition, tasks, processes and stack, and are completely independent from each other. If you are invited to a team that is no different from the others, questions from the sections "Team", "Tasks", "Processes" and "Stack" can be asked immediately. Otherwise, ask for an additional meeting with the team after passing the interview. Most likely you will not be refused. Often such a meeting is already planned. Then proceed immediately to the "Development" section.
1. Who is on the team?
2. Who is the customer (product owner)? Have a project manager?
3. When was the team building? How many people have come? See out of work?
The most important question pool for me. But tough tasks are not a panacea. I didnât get to this right away.
First, in real time you can and should influence what tasks you solve. The key role is played by the initiative and your personal roadmap (do you have it?).
Secondly, in any task you can find something new and interesting for yourself. An interesting task is not only new technologies, complex logic, beautiful interfaces, architectural development. Do it yourself, do it fast, do better than planned, better than last time. To invent, coordinate, refactor, investigate. In this project, in the next one, in the one you just came up with.
Thirdly, a cool team and a pleasant atmosphere level out routine tasks. In the opposite direction it works less often. Do not get hung up on tasks. Itâs better not to get hung up on anything. Set priorities, but consider all factors.
1. What tasks will I solve?
2. What are responsibilities other than development?
3. What are the last two projects done? What are the next projects? How do you plan to develop the service in the near future?
4. What tasks from the last are most remembered, liked?
5. What tasks would you like to get rid of? What do you have to put up with now (no people, have not automated yet)?
6. What did the latter do for the soul, for the department, from non-productive tasks?
7. Is there a backlog of non-productive tasks?
8. Why is such a technology / library / framework used?
9. How much percent of the time do such tasks take?
1. How do you prepare for sprint / quarter planning?
2. What code coverage?
3. Who will review my code?
4. How is the assembly and deployment going?
5. How often do you spend retro?
6. When do you practice technical debt?
Do not try to understand the whole system: monoreps, microservices, on what and why, how they are friends. Well, if you understand all this while working. It is enough to find out what kind of logic is written on what, where it lies and who supports it.
1. What is legacy written on?
2. Why (not) chose a technology / library such and such?
3. What technologies have been implemented over the past six months / year?
June is easier to develop: the whole area is an unplowed field, lower responsibility, initiative will be noticed and encouraged. It is more difficult for the elder: higher than expectations, it is more difficult to justify them, certain conditions are necessary for growth, and adequate assessment is necessary for growth. The higher the level, the more important this section.
1. Who evaluates me? What are the criteria?
2. What does the assessment affect? What does a grade affect?
3. Is it possible to rotate to another team?
âWhat is expected of me?â Is a very important question. If you ask in the forehead, you will get the standard âyou cope with the tasks, do a lot of time, get along with the teamâ. We try not in the forehead.
1. Why is a person needed in a team?
2. What specialist is missing in the team? What hard skills are lacking for the guys on the team? What kind of experience is missing?
3. What tasks no one to transfer? Why?
4. What specialists are missing in the department except for the team leaders?
5. What needs to be done to exceed your expectations? Give an example of tasks.
6. What doubts remained on my account?
7. What difficulties will definitely be at the start?
8. What tasks will you give me at the beginning?
9. Will a curator be assigned to me? For what period?
Personal questions. The meeting should be interesting for both parties. Give a person the opportunity to talk about what he is proud of, what he has achieved, and share experience. Everyone loves to talk to themselves. It is profitable for you. Firstly, if you talk to your interlocutor, it will be possible to throw up uncomfortable, incriminating questions. Secondly, you will like and remember him, do you want to go through social security? Thirdly, communication with a cool dude is a separate reason to go to social security.
1. Have you been working here for a long time? It's a lot. What is so catchy?
2. And where did he work before? And what is left?
3. What did you learn at work over the past year?
4. How many hours a day do you code? What does the rest of the time take? Remain the strength of the house to skip?
5. What time do you come to work? What time do they all diverge?
6. Where can I work outside the workplace? Where do you usually hang out?
7. Do you use your service yourself? What would you like to improve in it? Tried to drop it into the product? Can you influence the development of the service? What about product decisions? Did you manage to push something? Tell me.
8. What metrics are you tracking?
9. How do you ensure safety?
If a team leader / interviewer is interviewed:
1. What processes are not satisfied with now?
2. What are you planning to work on in the near future? What are the priorities?
3. Mentoring someone from the department?
4. How do you deal with a lack of team leaders?
Do you often carry out conversations? Does it take a lot of time?
Then I wonât hold you back. Thanks for your time. I was very interested with you. I hope we do not say goodbye;)
They fall under the definition of "an extra question" (see the algorithm in "TL; DR"). I will offer what to replace. If you want, use these questions too, you know better. In specific cases, they will provide the necessary information. Suitable for "start a conversation." I began to do without them.
1. What are you better than competitors ( USP , competitive advantages)?
2. Who finances projects (key investors)?
3. What difficulties are you experiencing now?
4. What are your plans for the coming year?
Why not. Answers can be google. If they are not in the public domain, they will not give you an interview. Recruiters are sell-side, they will not tell the uncomfortable truth.
Solution She will be told financial reports (if the company is public).
5. Are recycling paid?
Why not. They should not be. If they are, they will say that they are not. If this is the norm, they will say that they will pay. In fact, it could be otherwise.
Solution Find a company where you donât have to ask this question. If you do not plan to raise money for processing.
6. How many team leads / experts / experts? What are they doing?
Why not. The team lead in each team is excellent, but it is unlikely. They are always in short supply. You will learn about your team leader by discussing the composition of the team. Ideally, those who are older spend part of the time solving non-productive tasks. If these are formal requirements, they may not be followed.
Solution If you are interviewing a team leader, ask targeted questions (see the âOfftopâ section).
7. Who is my line manager? What does he do? How do you like it?
Why not. Youâre not parsing the managerâs qualifications. The developer will not evaluate the leadership with you. If it does, he is either lying or biased.
Solution If this is especially important for you, ask to arrange a personal meeting with the leader. If he will interview you, ask targeted questions (see the âOfftopâ section).
8. How do you rate the tasks?
Why not. There is a scale for assessment in historical points and there is a Velocity. You will not parse their accuracy and adequacy in an interview. Evaluation in days will not show the quality of decomposition - suspicious cases will not be voiced.Tasks have priority. The quality of the prioritization you will not parse for the interview.
Solution Perhaps it will help:
- âWhat do you take into account when evaluating time?â Good to hear: they play planning poker, take risks, take into account the expertise of the contractor, the possibility of refactoring, related tasks from the backlog.
9. How long does it take on average to develop a new feature? And including escort?
Why not. Development time will not help to estimate the number of distractions. Tracking time will not help assess the speed of testing and review. Too arbitrary, it all depends on the circumstances.
Solution Perhaps it will help (as an offtopic):
- âWhat was the last decision? How much time did you kill? Che so fast / long? â
- âHow long did the last task hang in testing / review? This is a good indicator? "
10. Meeting at all rigged?
Why not. Will it stop you if not? Canât you arrive half an hour early? Relationships in the team you do not pars so.
Solution Perhaps it will help:
- âWhat time is the rally?â At this time I am having lunch / still sleeping / already at home. Will be able to move to another time? "
11. There are on duty at the time of the holidays?
12. Is there a moratorium?
Why not. Moratoria are violated, and there are admins on duty.
Solution Perhaps it will help:
- âWhen was the last time the moratorium was violated? For what reason? "
-" If I release Katni and sick, who will roll back "?
13. How often is feedback given?
Why not. Feedback on request is everywhere. Often only upon request. I believe such meetings should be held as planned, but you never know what I think.
Solution If there is a problem, do not keep it to yourself.
14. I report a problem in the review. How will it be solved?
Why not. A great chance to get a socially expected response. If you are communicating with your team leader / leader, discuss specific cases.
Solution Perhaps it will help:
- âThe product does not allow to clear the technical debt. He is wrong. âGood to hear: concrete actions are planned to solve the problem. âI'll talk to himâ is bad. âIâll come to planning, assess the situation and help find a compromiseâ - good.
15. Will the company buy me software for work?
Why not. Good will buy, bad - no. You will understand good or bad on other issues. They will buy a license for the IDE; they themselves are interested. If you need something specific and expensive, ask a targeted question.
Solution For example:
âI want Wallaby. Because look what profit ... Can I? "
-" I want to subscribe to the Kurseru. I will justify the costs. Agree? "
16. How Juneau department? How many middle and senior?
Why not. Opportunities for growth, the complexity of tasks and the experience of employees you canât do. There are skill junes, there are inert elders. Not everyone wants to grow. The first is more - they are more profitable, the second is less - it is difficult to catch.
Solution If you are afraid to grab all the black work (the only June) or if you want to share responsibility with someone (the only senior), start with other questions (see the section âExpectationsâ).
17. How long does the sprint last? How did you come to this figure?
Why not.The quality of planning you do not parse. This is a variable, and it is not taken from the ceiling. I have never met any very suspicious cases.
Solution Perhaps it will help:
- âHow many tasks have moved to the current sprint from the previous one? Why? "
18. How sync with the other teams?
19. How are conflict situations resolved?
Why not. Too arbitrary, it all depends on the circumstances. A great chance to get a socially expected response.
Solution Perhaps help:
- "two teams to do the same thing (write a generic component / to test / poriserchit), who will do it?"
- "Do you want to introduce in the common stack of new technology, how will you decide?"
20. If the plan is not fulfilled, how will they be punished?
Why not. No one will come to knock you on the hat. The maximum bonus will be deprived. Specify the award separately.
Solution Find a company where you donât have to ask this question.
21. Microservices or monorepa? How did you come to such an architecture?
Why not. The project lives on, the requirements change, the monorepa is pulled into microservices, sometimes vice versa, but not necessarily and not every. Today is so, tomorrow is different.
Solution If you are looking for architecture and âjust curiousâ - specify. You yourself know what to clarify.
22. How do developers learn about the plans and achievements of the company?
Why not.Mandatory mailing, meetings with the director, presentation before the new year, a blog on Habré, the product sends feedback from users to the general chat - let it be something.
23. Why did you decide to switch to kanban?
I believe this is a useful question, but I do not know how to parse the answer.
For those who have read.
An interview is a conversation, not an interrogation. Questions are just reference points for this conversation. Where you take her, you will receive.
The main task is to find out the adequacy of requirements, the coincidence of desires and opportunities, what to expect in a new place, what not to expect. Squeeze maximum information to make it easier to make a decision. For everything else, there is a trial period. I wish you to make the right choice.
You are also appreciated for your questions. Leave a good impression about yourself.
And the last one.Did you write the code on social security? Joel was not a fool. Interviewing without a code is not the best interview. Let this be our last criterion for evaluating the company.
I drove the whole month through dogmas. I looked at both startups and Yandex. There are many companies, itâs difficult to choose. To find the one you need to consider many factors. For each company I compiled an individual list of questions. Universal framed in this faq. It contains the key questions of the applicant and their analytics. Some of the questions are tailored for developers, the rest will suit everyone. Go under the cut!
TL; DR
I do not know what and how to ask.
Hold the algorithm!
- Reflect.
What did you like at your last job? What didnât you like? Why did he leave?
Map these key points to questions.
- Make a roadmap.
What do you want from a new job?
Display these requirements for questions.
- Filter out.
Remove unnecessary questions. The question is superfluous if it falls under the items from the list:
- the answer can be google;
- the answer will not be worth the time spent;
- a great chance to get a socially expected response;
- the question is uncomfortable, they will most likely lie to you;
- you do not know the correct answer;
- you do not know what you want to hear;
- you do not know what you do not want to hear;
- the answer will not affect the decision.
- Specify.
Specify open questions.
If the answer depends on the circumstances, ask a specific case.
- Set your expectations.
What do you want? What am I ready to put up with? What is unacceptable?
Mark the red flags.
- Starget.
What to consider:
- company size;
- position;
- vacancy description;
- purpose of the meeting (stage).
Why so hard?
In order not to regret the choice. To find a company that will give you everything that you are looking for: tasks, prospects, conditions - we are not working here for money :)
Interview time is limited. We do not want to spend it on socially expected answers, excuses, unnecessary information. Getting the right one is not easy. You need to know where to poke to infa flow. And do not poke indiscriminately, so as not to drown in it. We will prepare subtle aiming questions. We will build a consistent meaningful dialogue on them.
Disclaimer
The purpose of the article is to orient what to ask and why. There are no sacred knowledge and magic questions. Compose suitable based on the listed. Use the algorithm above.
I will help parsing the answers. Under each (not every) question there is analytics by parameters:
- âAsk yourselfâ: what you can hear, what you should think about;
- âGood to hearâ, âRed flagsâ: what conclusions to draw, which not to rush;
- âDiscussâ: what to clarify, where to redirect the dialogue.
Analytics is not exhaustive and is based on personal experience. If there is no section, then I do not consider my opinion objective or I have nothing to add. My âGood to hearâ and âRed flagsâ may not match yours. Analytics is not needed everywhere: I donât know what is in your head, what you want, what you are looking for. Deal with this before you go to social security.
In the section "Wacky Questions" I have collected specific and useless. I do not like them, I have listed the reasons. If you want, use it.
I ran in 70% of what I wrote, the rest did not have time. If I'm wrong, it's not like that, it was different with you - write in the comments how it is right, this will help the rest.
Business
âShow interest - ask about the company.â Bullshit. Not interesting - do not ask, google.
1. What do you earn? Which product is the main source of income?
Analysis
Ask yourself
Case 1. Your project is a locomotive.
The main product is the holy cow: everyone prays for it, pours it with money, it will provide the resources yesterday, but also the corresponding expectations. Ready to work at the forefront with all the consequences?
Case 2. You are invited to a new young project.
In such a flexible stack and processes, but they can collapse: work at the table, reduce staff. Do you understand the risks?
Offtop. Knowing the business model and sources of income, you can estimate the current position of the company in the market, development prospects. There is no point in deeply analyzing a large company. It will not be superfluous to evaluate a startup if you are guided in the field.
Discuss
If you take into the main project, pay attention to questions about the timing and development priorities. If in a new one, find out what will happen to you if the project does not fly.
Case 1. Your project is a locomotive.
The main product is the holy cow: everyone prays for it, pours it with money, it will provide the resources yesterday, but also the corresponding expectations. Ready to work at the forefront with all the consequences?
Case 2. You are invited to a new young project.
In such a flexible stack and processes, but they can collapse: work at the table, reduce staff. Do you understand the risks?
Offtop. Knowing the business model and sources of income, you can estimate the current position of the company in the market, development prospects. There is no point in deeply analyzing a large company. It will not be superfluous to evaluate a startup if you are guided in the field.
Discuss
If you take into the main project, pay attention to questions about the timing and development priorities. If in a new one, find out what will happen to you if the project does not fly.
2. In what areas do you work? What are b2b projects, b2c, R&D?
Analysis
Ask yourself
Any other interesting projects? If you get tired of this, is there anywhere to rotate?
Offtop. The question is more likely for large companies, but the answer is unexpected in small ones - they may turn out to be larger than you thought.
Good to hear
The company analyzes the market, seeks new directions for development, participates in joint projects with other companies. Many different product teams. There are integrations with other services. Invested in R&D.
Any other interesting projects? If you get tired of this, is there anywhere to rotate?
Offtop. The question is more likely for large companies, but the answer is unexpected in small ones - they may turn out to be larger than you thought.
Good to hear
The company analyzes the market, seeks new directions for development, participates in joint projects with other companies. Many different product teams. There are integrations with other services. Invested in R&D.
Motivation
The recruiter will tell about nishtyaki. If something is especially important to you, specify.
Ask to show the office. Most likely show. Padded stools, kitchen, gym - cool if the workplace is also convenient. And then ottomans on the fifth floor, and you will work on the second, where the repair is going.
1. What affects my salary other than the increase? What does the premium depend on?
2. What are the incentives? How to deserve them?
3. What are the computers / laptops? Can I work for them from home?
4. Are you sending guys to the conference? And international? Where did you go last time? How is it decided who will go?
The Department
1. How many people are in the department? How do they communicate? How closely interact?
Analysis
Ask yourself
Do teams / units know what is going on in neighboring teams / units? How are knowledge rummaged?
Discuss
- What issues are resolved together?
- Why did you get together for the last time?
- How many people have come?
- What was the result of the meeting?
Good to hear
Key decisions are made together, taking into account different opinions. The necessary level of independence is maintained. Everyone has an understanding of what is happening in other projects to help with the code review and to know who can get the solution to their problem. Decisions and knowledge are fixed and accessible to everyone. Formal meetings to exchange news and experiences are faults.
Do teams / units know what is going on in neighboring teams / units? How are knowledge rummaged?
Discuss
- What issues are resolved together?
- Why did you get together for the last time?
- How many people have come?
- What was the result of the meeting?
Good to hear
Key decisions are made together, taking into account different opinions. The necessary level of independence is maintained. Everyone has an understanding of what is happening in other projects to help with the code review and to know who can get the solution to their problem. Decisions and knowledge are fixed and accessible to everyone. Formal meetings to exchange news and experiences are faults.
2. What teams are the developers divided into?
Analysis
Ask yourself
In addition to grocery products, there are highly specialized ones: development of common components, development of tools, refactoring team, architectural team.
Case 1. Many teams.
Better focus on tasks, higher expertise of developers in their field, but lower in others, their interest in "alien" tasks is reduced. I am for specialization + rotation. Are you with me?
Case 2. Few teams.
Higher involvement, wider range of tasks, but wider range of responsibilities. Ready for the role of âboth the Swiss and the Reaperâ?
Discuss
Clarify how responsibility for projects and microservices is distributed among teams.
In addition to grocery products, there are highly specialized ones: development of common components, development of tools, refactoring team, architectural team.
Case 1. Many teams.
Better focus on tasks, higher expertise of developers in their field, but lower in others, their interest in "alien" tasks is reduced. I am for specialization + rotation. Are you with me?
Case 2. Few teams.
Higher involvement, wider range of tasks, but wider range of responsibilities. Ready for the role of âboth the Swiss and the Reaperâ?
Discuss
Clarify how responsibility for projects and microservices is distributed among teams.
3. How many people have been working in the department for more than 3 years? There are such?
Analysis
Ask yourself
How many people will be able to orient you when you refach significant functionality or a very ancient legacy?
Offtop. Do not try to appreciate the fluidity. Too many factors affect whether people leave or stay. A bunch of olds can reflect not only comfortable working conditions, but also a bunch of lazy ambitious assholes in the department.
Good to hear
If there are more than two, this is the fault. There were a lot of oldfags at the last job, this helped me out a couple of dozen times.
How many people will be able to orient you when you refach significant functionality or a very ancient legacy?
Offtop. Do not try to appreciate the fluidity. Too many factors affect whether people leave or stay. A bunch of olds can reflect not only comfortable working conditions, but also a bunch of lazy ambitious assholes in the department.
Good to hear
If there are more than two, this is the fault. There were a lot of oldfags at the last job, this helped me out a couple of dozen times.
Team
Teams are similar in composition, tasks, processes and stack, and are completely independent from each other. If you are invited to a team that is no different from the others, questions from the sections "Team", "Tasks", "Processes" and "Stack" can be asked immediately. Otherwise, ask for an additional meeting with the team after passing the interview. Most likely you will not be refused. Often such a meeting is already planned. Then proceed immediately to the "Development" section.
1. Who is on the team?
Analysis
Ask yourself
Case 1. A large friendly team. Perhaps cross-functional.
More communications, more meetings and planning. Are you a team player?
Case 2. You will do everything yourself, not depend on anyone.
A wider range of tasks, higher responsibility. You wanted it?
Case 3. There are remote managers.
It did not turn around and asked. And do not go to dinner together. Are you okay?
Discuss
If cross-functional:
- What do you do if there are not enough fixed testers?
If on their own:
- Who is testing? How many days do you usually wait for a free tester?
- Who agrees with management plans?
Case 1. A large friendly team. Perhaps cross-functional.
More communications, more meetings and planning. Are you a team player?
Case 2. You will do everything yourself, not depend on anyone.
A wider range of tasks, higher responsibility. You wanted it?
Case 3. There are remote managers.
It did not turn around and asked. And do not go to dinner together. Are you okay?
Discuss
If cross-functional:
- What do you do if there are not enough fixed testers?
If on their own:
- Who is testing? How many days do you usually wait for a free tester?
- Who agrees with management plans?
2. Who is the customer (product owner)? Have a project manager?
Analysis
Ask yourself
Case 1. A product with an invalid background in development (oh, my!), Or too ambitious, or inexperienced and does not know the product well. The project is weak / it is not there / it is a product.
You will protect your interests yourself. You will pump soft skills, you will learn to argue your Wishlist and seek compromises. Is that part of your area of ââinterest? Are you ready for this?
Case 2. There is no product, no project, no team lead.
You will coordinate plans yourself, plan the progress of work. Can you handle it?
Offtop. Projects owe us nothing. They can make our work easier and more enjoyable, but they will not save you from communicating with the product and do not guarantee interesting tasks.
Discuss
- Who prioritizes the tasks?
- Who and how evaluates the work of the team?
If not both:
- Who sets the tasks?
- Who agrees with management plans?
If there is a product:
- Does each team have its own product?
- How many years of experience do you have? How many of them does he work for in the company? How many are in the team?
If there is a project: all the same about the project.
Case 1. A product with an invalid background in development (oh, my!), Or too ambitious, or inexperienced and does not know the product well. The project is weak / it is not there / it is a product.
You will protect your interests yourself. You will pump soft skills, you will learn to argue your Wishlist and seek compromises. Is that part of your area of ââinterest? Are you ready for this?
Case 2. There is no product, no project, no team lead.
You will coordinate plans yourself, plan the progress of work. Can you handle it?
Offtop. Projects owe us nothing. They can make our work easier and more enjoyable, but they will not save you from communicating with the product and do not guarantee interesting tasks.
Discuss
- Who prioritizes the tasks?
- Who and how evaluates the work of the team?
If not both:
- Who sets the tasks?
- Who agrees with management plans?
If there is a product:
- Does each team have its own product?
- How many years of experience do you have? How many of them does he work for in the company? How many are in the team?
If there is a project: all the same about the project.
3. When was the team building? How many people have come? See out of work?
Analysis
Ask yourself
Sounds like a friendly atmosphere? Is the company working to create it?
Good to hear
Have lunch together. Drive together on external konf. Organize training and master classes for each other. This happens not only in large companies. They are gathered by the whole department in an informal setting - this is the fault, here itâs definitely friendly. Because to bring together 5 people is difficult, to bring together 5+ people is almost impossible if they are just colleagues.
Sounds like a friendly atmosphere? Is the company working to create it?
Good to hear
Have lunch together. Drive together on external konf. Organize training and master classes for each other. This happens not only in large companies. They are gathered by the whole department in an informal setting - this is the fault, here itâs definitely friendly. Because to bring together 5 people is difficult, to bring together 5+ people is almost impossible if they are just colleagues.
Tasks
The most important question pool for me. But tough tasks are not a panacea. I didnât get to this right away.
First, in real time you can and should influence what tasks you solve. The key role is played by the initiative and your personal roadmap (do you have it?).
Secondly, in any task you can find something new and interesting for yourself. An interesting task is not only new technologies, complex logic, beautiful interfaces, architectural development. Do it yourself, do it fast, do better than planned, better than last time. To invent, coordinate, refactor, investigate. In this project, in the next one, in the one you just came up with.
Thirdly, a cool team and a pleasant atmosphere level out routine tasks. In the opposite direction it works less often. Do not get hung up on tasks. Itâs better not to get hung up on anything. Set priorities, but consider all factors.
1. What tasks will I solve?
2. What are responsibilities other than development?
3. What are the last two projects done? What are the next projects? How do you plan to develop the service in the near future?
4. What tasks from the last are most remembered, liked?
5. What tasks would you like to get rid of? What do you have to put up with now (no people, have not automated yet)?
6. What did the latter do for the soul, for the department, from non-productive tasks?
Hint
Usually a team lead talks, they have more resources or full carte blanche on their Wishlist. Ask the developer of the product team or the most silent one.
7. Is there a backlog of non-productive tasks?
Hint
Sometimes all developers get a percentage of the time to solve non-productive tasks: technical debt, experiments. There is a separate pool of tasks from the "decide who is not lazy" category. These are tasks for self-development and assistance to other teams / departments. Often for them there is a separate board in jir. If you are interested in such tasks, evaluate their relevance. It can be any slag that no one wants to climb into, and there can be tough tasks that no one could, or no one could. Ask for examples of such tasks in order to understand what tasks lack hands / time / volunteers / experts.
8. Why is such a technology / library / framework used?
Hint
Clarify which tasks are solved using the selected tools and key technologies. To know how closely you will work with them, how well you should / will know them.
9. How much percent of the time do such tasks take?
Hint
It is important to understand the percentage of different tasks. Do not ask about everything. Estimate the number of those that you do not want to decide. Define comfortable boundaries in advance.
The processes
1. How do you prepare for sprint / quarter planning?
Analysis
Ask yourself
Does the product discuss projects with the team before compiling the ToR ? Would you like to take more part in the requirements analysis and development phase?
Discuss
Clarify how actively testers participate in the analysis of the project. Testing requirements directly affects the quality of TK.
If you rummage as it should, specify other aspects of planning. Only pointwise, otherwise you will get a retelling of the chapter from a book about scrum.
Good to hear
Two-stage planning. Discuss the purpose of the project. They read tz, look for what they missed. Theyâll examine the code theyâll get into (this code may have to be refactored, and even the libraries on the way to update). Architects also go into the Sat: all of a sudden itâs impossible / wrong / it can be easier / this already exists. Gather requirements for the completion of infrastructure.
Red flags
The team does not realize the importance of training. The team falls into analytical paralysis.
Does the product discuss projects with the team before compiling the ToR ? Would you like to take more part in the requirements analysis and development phase?
Discuss
Clarify how actively testers participate in the analysis of the project. Testing requirements directly affects the quality of TK.
If you rummage as it should, specify other aspects of planning. Only pointwise, otherwise you will get a retelling of the chapter from a book about scrum.
Good to hear
Two-stage planning. Discuss the purpose of the project. They read tz, look for what they missed. Theyâll examine the code theyâll get into (this code may have to be refactored, and even the libraries on the way to update). Architects also go into the Sat: all of a sudden itâs impossible / wrong / it can be easier / this already exists. Gather requirements for the completion of infrastructure.
Red flags
The team does not realize the importance of training. The team falls into analytical paralysis.
2. What code coverage?
Analysis
Ask yourself
How many tests are you ready to finish when you press it?
Discuss
- How many percent of the code is covered by unit tests?
- How many percent of the functionality is covered by integration tests?
- Who writes autotests?
Good to hear
In a large project, I expect 70%, this is a good achievable indicator. Not all manual testers love and know how to write autotests: it is good if this is controlled.
Red flags
A low indicator may mean poor product quality, team irresponsibility, managerâs insanity: âgo ahead and write tests laterâ or âwe are not going to update anythingâ. May mean! = Exactly means. Code coverage is not an easy metric: you can get a high score by covering simple cases to the maximum and not covering key logic. Startups low indicator is excusable.
How many tests are you ready to finish when you press it?
Discuss
- How many percent of the code is covered by unit tests?
- How many percent of the functionality is covered by integration tests?
- Who writes autotests?
Good to hear
In a large project, I expect 70%, this is a good achievable indicator. Not all manual testers love and know how to write autotests: it is good if this is controlled.
Red flags
A low indicator may mean poor product quality, team irresponsibility, managerâs insanity: âgo ahead and write tests laterâ or âwe are not going to update anythingâ. May mean! = Exactly means. Code coverage is not an easy metric: you can get a high score by covering simple cases to the maximum and not covering key logic. Startups low indicator is excusable.
3. Who will review my code?
Analysis
Ask yourself
Case 1. Everything in the subject, 10 reviewers for the pull request, everyone cares about you.
Do you care about everyone? Are you ready to watch 5+ pull requests per day?
Case 2. Timlid will look at your code if there is time.
No review - no one will say how it should, how it is right. Do you know exactly how to do it?
Offtop. A well-organized code review process does not guarantee its quality. In words, âwe deeply analyze logicâ, but in fact - 50 messages in a thread about some absurd gustatory taste. Learn the necessary minimum, but do not rush to conclusions.
Discuss
- How much was your last review task? He quickly drove away. Is it always like that?
- Do pull requests have priorities?
- How many pull requests per day do you watch?
Good to hear
Team members are mandatory reviewers. Mandatory is someone who fumbles for architecture. A pull request does not hang longer than 3 days for no particular reason. Abandoned pull requests are automatically deleted. Teams are guided in the code of other projects, conduct code reviews of other teams.
Red flags
Two and a half cripples are watching your code.
Case 1. Everything in the subject, 10 reviewers for the pull request, everyone cares about you.
Do you care about everyone? Are you ready to watch 5+ pull requests per day?
Case 2. Timlid will look at your code if there is time.
No review - no one will say how it should, how it is right. Do you know exactly how to do it?
Offtop. A well-organized code review process does not guarantee its quality. In words, âwe deeply analyze logicâ, but in fact - 50 messages in a thread about some absurd gustatory taste. Learn the necessary minimum, but do not rush to conclusions.
Discuss
- How much was your last review task? He quickly drove away. Is it always like that?
- Do pull requests have priorities?
- How many pull requests per day do you watch?
Good to hear
Team members are mandatory reviewers. Mandatory is someone who fumbles for architecture. A pull request does not hang longer than 3 days for no particular reason. Abandoned pull requests are automatically deleted. Teams are guided in the code of other projects, conduct code reviews of other teams.
Red flags
Two and a half cripples are watching your code.
4. How is the assembly and deployment going?
Analysis
Ask yourself
Case 1. CI / CD, everything is automated.
Typically, administrators / devs do automation. But they can attract you. Do not piss?
Case 2. All by hand.
Collect packages yourself, bind tasks, create release tasks, control acceptance. Are you normal, or have you already gotten angry?
Discuss
- Does the team have their own test stand?
- How long does it take to create a new stand with a specific environment?
- Who is releasing? Who is responsible?
- How long did your last release take?
- How often do you release?
- If the release falls at 10 pm, what is the plan of action?
Good to hear
CI / CD is configured to the maximum: the master is cut according to the commit / schedule, and the scheme can be created by the button. The team has its own test bench and no one goes to it. The admin will roll, but you are responsible. The company understands this and is not looking for the one to blame.
Red flags
A lot of routine operations. Many releases, but the conditions are not adapted.
Case 1. CI / CD, everything is automated.
Typically, administrators / devs do automation. But they can attract you. Do not piss?
Case 2. All by hand.
Collect packages yourself, bind tasks, create release tasks, control acceptance. Are you normal, or have you already gotten angry?
Discuss
- Does the team have their own test stand?
- How long does it take to create a new stand with a specific environment?
- Who is releasing? Who is responsible?
- How long did your last release take?
- How often do you release?
- If the release falls at 10 pm, what is the plan of action?
Good to hear
CI / CD is configured to the maximum: the master is cut according to the commit / schedule, and the scheme can be created by the button. The team has its own test bench and no one goes to it. The admin will roll, but you are responsible. The company understands this and is not looking for the one to blame.
Red flags
A lot of routine operations. Many releases, but the conditions are not adapted.
5. How often do you spend retro?
Analysis
Ask yourself
Do you like the format? For example, I am enraged by retro in a game format.
Discuss
- How long did the last meeting last?
- How many people have come?
- What did you find out?
- What are you planning to do with this?
- What did the last improve thanks to retro?
- What is an indicator of team effectiveness?
Good to hear
Planned retro, more often - better. There is a plan and tight timing. Present are all who participated in the projects under discussion, and not just the team. The results are recorded, conclusions are drawn, concrete actions are planned to improve the situation. The results of these actions are tracked.
Red flags
Retro is held only in the case of fakap. It lasts longer than two hours, this means the discussion is not structured, they do not prepare for retro, holivars are bred. No one controls the implementation of decisions made.
Do you like the format? For example, I am enraged by retro in a game format.
Discuss
- How long did the last meeting last?
- How many people have come?
- What did you find out?
- What are you planning to do with this?
- What did the last improve thanks to retro?
- What is an indicator of team effectiveness?
Good to hear
Planned retro, more often - better. There is a plan and tight timing. Present are all who participated in the projects under discussion, and not just the team. The results are recorded, conclusions are drawn, concrete actions are planned to improve the situation. The results of these actions are tracked.
Red flags
Retro is held only in the case of fakap. It lasts longer than two hours, this means the discussion is not structured, they do not prepare for retro, holivars are bred. No one controls the implementation of decisions made.
6. When do you practice technical debt?
Analysis
Ask yourself
Manager / product / manager understands why this is necessary? What does he do in order not to get bogged down in technical debts? What do the developers themselves do for this?
Discuss
- What did the last refactor?
- What non-productive tasks did you take this quarter?
Good to hear
The technical debt is being raked as planned. Considered in planning. A fixed time (% of working time / part of the sprint) is allocated for improving the code base, experiments, initiative. Code complexity is analyzed automatically.
Red flags
Product backlog is not distinguished from technical debt.
Manager / product / manager understands why this is necessary? What does he do in order not to get bogged down in technical debts? What do the developers themselves do for this?
Discuss
- What did the last refactor?
- What non-productive tasks did you take this quarter?
Good to hear
The technical debt is being raked as planned. Considered in planning. A fixed time (% of working time / part of the sprint) is allocated for improving the code base, experiments, initiative. Code complexity is analyzed automatically.
Red flags
Product backlog is not distinguished from technical debt.
Stack
Do not try to understand the whole system: monoreps, microservices, on what and why, how they are friends. Well, if you understand all this while working. It is enough to find out what kind of logic is written on what, where it lies and who supports it.
1. What is legacy written on?
Analysis
Ask yourself
Ready to mess with this?
Discuss
âIs Legacy just there or is it actively supported?â
- Do you plan translation, refactoring? Why? When? By whom?
- What percentage of legacy code is documented?
Good to hear
There is nothing very silky. There are - these are well-known technologies. If the bike - there are those who fumble. If you are going to translate - there is a plan and a team, and not a scapegoat (you can become one).
Red flags
"Rewrite someone else's project, no one else."
Ready to mess with this?
Discuss
âIs Legacy just there or is it actively supported?â
- Do you plan translation, refactoring? Why? When? By whom?
- What percentage of legacy code is documented?
Good to hear
There is nothing very silky. There are - these are well-known technologies. If the bike - there are those who fumble. If you are going to translate - there is a plan and a team, and not a scapegoat (you can become one).
Red flags
"Rewrite someone else's project, no one else."
2. Why (not) chose a technology / library such and such?
Analysis
Ask yourself
Case 1. There is a simpler solution.
Was there a good reason to choose a more powerful and complex solution?
Case 2. There is a more reliable / convenient / cheaper solution.
Are there any good reasons not to implement it?
Case 3. Suspicious / key decision.
How many cones will you collect when moving to another solution? The reasons for the selection and review of the nuances are fixed somewhere? Or will you have to analyze from scratch?
Discuss
- Have you considered alternatives?
- Who made the decision?
- There were doubts?
- What problems have you already managed to grab? How did you decide?
- You did not think to refuse / switch to another solution?
- Which version? Che so old?
Good to hear
The specifics of the service are taken into account. The decision was made together, arranged for the majority. Conducted a preliminary drawing. The results of discussions and approvals were recorded and available.
Red flags
She was, we did not change. We only try. We are high lovers.
Case 1. There is a simpler solution.
Was there a good reason to choose a more powerful and complex solution?
Case 2. There is a more reliable / convenient / cheaper solution.
Are there any good reasons not to implement it?
Case 3. Suspicious / key decision.
How many cones will you collect when moving to another solution? The reasons for the selection and review of the nuances are fixed somewhere? Or will you have to analyze from scratch?
Discuss
- Have you considered alternatives?
- Who made the decision?
- There were doubts?
- What problems have you already managed to grab? How did you decide?
- You did not think to refuse / switch to another solution?
- Which version? Che so old?
Good to hear
The specifics of the service are taken into account. The decision was made together, arranged for the majority. Conducted a preliminary drawing. The results of discussions and approvals were recorded and available.
Red flags
She was, we did not change. We only try. We are high lovers.
3. What technologies have been implemented over the past six months / year?
Analysis
Ask yourself
Keep track of the development of the field and tools? Choose consciously? If you donât take the initiative, ready to take it upon yourself?
Discuss
- Maybe, on the contrary, they removed something from the stack? Why?
- Maybe they tried to introduce something, but did not take root? Why?
Good to hear
Conducting research, trying to make it better / easier / more reliable, but within reason.
Keep track of the development of the field and tools? Choose consciously? If you donât take the initiative, ready to take it upon yourself?
Discuss
- Maybe, on the contrary, they removed something from the stack? Why?
- Maybe they tried to introduce something, but did not take root? Why?
Good to hear
Conducting research, trying to make it better / easier / more reliable, but within reason.
Development
June is easier to develop: the whole area is an unplowed field, lower responsibility, initiative will be noticed and encouraged. It is more difficult for the elder: higher than expectations, it is more difficult to justify them, certain conditions are necessary for growth, and adequate assessment is necessary for growth. The higher the level, the more important this section.
1. Who evaluates me? What are the criteria?
Analysis
Ask yourself
Are requirements and expectations fixed? Do you understand them?
Can you live up to these expectations? Doesn't the pressure level bother you?
Where is the ceiling?
Good to hear
You are appreciated by those who work with you side by side.
Formal criteria complement the subjective assessment of colleagues. There are clear assessment criteria: speed of work, volume of tasks, going beyond the area of ââresponsibility, growth of hard skills, development of soft skills. If there are grades, they are run-in and are not the first day.
Red flags
You are evaluated by a formal leader or someone left. The assessment is as subjective as possible. The assessment takes into account only measurable indicators: how many problems have been solved, etc. It is not clear where you can develop and how to do it.
Are requirements and expectations fixed? Do you understand them?
Can you live up to these expectations? Doesn't the pressure level bother you?
Where is the ceiling?
Good to hear
You are appreciated by those who work with you side by side.
Formal criteria complement the subjective assessment of colleagues. There are clear assessment criteria: speed of work, volume of tasks, going beyond the area of ââresponsibility, growth of hard skills, development of soft skills. If there are grades, they are run-in and are not the first day.
Red flags
You are evaluated by a formal leader or someone left. The assessment is as subjective as possible. The assessment takes into account only measurable indicators: how many problems have been solved, etc. It is not clear where you can develop and how to do it.
2. What does the assessment affect? What does a grade affect?
Analysis
Ask yourself
Can you directly influence nishtyaki?
Are you ready to influence them or just want a lot of money?
Good to hear
The results of the assessment instantly (instantly will not) are displayed on nishtyaki: salary, position, job opportunities or working conditions. Or at least give priority to receiving them. Grades are not only about responsibility, but also about opportunities.
Red flags
The assessment does not give anything, you will be patted on the head and not fired.
Can you directly influence nishtyaki?
Are you ready to influence them or just want a lot of money?
Good to hear
The results of the assessment instantly (instantly will not) are displayed on nishtyaki: salary, position, job opportunities or working conditions. Or at least give priority to receiving them. Grades are not only about responsibility, but also about opportunities.
Red flags
The assessment does not give anything, you will be patted on the head and not fired.
3. Is it possible to rotate to another team?
Analysis
Ask yourself
Rotation is an acquaintance with other products and people, an increase in expertise, new tasks, and all this without changing the work. You're interested? Or is it easier for you to change jobs when you get bored?
Discuss
- How often do employee-driven rotations occur?
- Are there restrictions on rotation (frequency, timing)?
- Forced rotation is possible (for the exchange of experience)?
Good to hear
Rotations are possible and practiced. The restrictions are adequate.
Rotation is an acquaintance with other products and people, an increase in expertise, new tasks, and all this without changing the work. You're interested? Or is it easier for you to change jobs when you get bored?
Discuss
- How often do employee-driven rotations occur?
- Are there restrictions on rotation (frequency, timing)?
- Forced rotation is possible (for the exchange of experience)?
Good to hear
Rotations are possible and practiced. The restrictions are adequate.
Expectations
âWhat is expected of me?â Is a very important question. If you ask in the forehead, you will get the standard âyou cope with the tasks, do a lot of time, get along with the teamâ. We try not in the forehead.
1. Why is a person needed in a team?
2. What specialist is missing in the team? What hard skills are lacking for the guys on the team? What kind of experience is missing?
3. What tasks no one to transfer? Why?
4. What specialists are missing in the department except for the team leaders?
5. What needs to be done to exceed your expectations? Give an example of tasks.
6. What doubts remained on my account?
7. What difficulties will definitely be at the start?
8. What tasks will you give me at the beginning?
9. Will a curator be assigned to me? For what period?
Offtop
Personal questions. The meeting should be interesting for both parties. Give a person the opportunity to talk about what he is proud of, what he has achieved, and share experience. Everyone loves to talk to themselves. It is profitable for you. Firstly, if you talk to your interlocutor, it will be possible to throw up uncomfortable, incriminating questions. Secondly, you will like and remember him, do you want to go through social security? Thirdly, communication with a cool dude is a separate reason to go to social security.
1. Have you been working here for a long time? It's a lot. What is so catchy?
2. And where did he work before? And what is left?
3. What did you learn at work over the past year?
4. How many hours a day do you code? What does the rest of the time take? Remain the strength of the house to skip?
5. What time do you come to work? What time do they all diverge?
6. Where can I work outside the workplace? Where do you usually hang out?
7. Do you use your service yourself? What would you like to improve in it? Tried to drop it into the product? Can you influence the development of the service? What about product decisions? Did you manage to push something? Tell me.
8. What metrics are you tracking?
9. How do you ensure safety?
If a team leader / interviewer is interviewed:
1. What processes are not satisfied with now?
2. What are you planning to work on in the near future? What are the priorities?
3. Mentoring someone from the department?
4. How do you deal with a lack of team leaders?
How to finish
Do you often carry out conversations? Does it take a lot of time?
Then I wonât hold you back. Thanks for your time. I was very interested with you. I hope we do not say goodbye;)
Wacky questions
They fall under the definition of "an extra question" (see the algorithm in "TL; DR"). I will offer what to replace. If you want, use these questions too, you know better. In specific cases, they will provide the necessary information. Suitable for "start a conversation." I began to do without them.
1. What are you better than competitors ( USP , competitive advantages)?
2. Who finances projects (key investors)?
3. What difficulties are you experiencing now?
4. What are your plans for the coming year?
Why not. Answers can be google. If they are not in the public domain, they will not give you an interview. Recruiters are sell-side, they will not tell the uncomfortable truth.
Solution She will be told financial reports (if the company is public).
5. Are recycling paid?
Why not. They should not be. If they are, they will say that they are not. If this is the norm, they will say that they will pay. In fact, it could be otherwise.
Solution Find a company where you donât have to ask this question. If you do not plan to raise money for processing.
6. How many team leads / experts / experts? What are they doing?
Why not. The team lead in each team is excellent, but it is unlikely. They are always in short supply. You will learn about your team leader by discussing the composition of the team. Ideally, those who are older spend part of the time solving non-productive tasks. If these are formal requirements, they may not be followed.
Solution If you are interviewing a team leader, ask targeted questions (see the âOfftopâ section).
7. Who is my line manager? What does he do? How do you like it?
Why not. Youâre not parsing the managerâs qualifications. The developer will not evaluate the leadership with you. If it does, he is either lying or biased.
Solution If this is especially important for you, ask to arrange a personal meeting with the leader. If he will interview you, ask targeted questions (see the âOfftopâ section).
8. How do you rate the tasks?
Why not. There is a scale for assessment in historical points and there is a Velocity. You will not parse their accuracy and adequacy in an interview. Evaluation in days will not show the quality of decomposition - suspicious cases will not be voiced.Tasks have priority. The quality of the prioritization you will not parse for the interview.
Solution Perhaps it will help:
- âWhat do you take into account when evaluating time?â Good to hear: they play planning poker, take risks, take into account the expertise of the contractor, the possibility of refactoring, related tasks from the backlog.
9. How long does it take on average to develop a new feature? And including escort?
Why not. Development time will not help to estimate the number of distractions. Tracking time will not help assess the speed of testing and review. Too arbitrary, it all depends on the circumstances.
Solution Perhaps it will help (as an offtopic):
- âWhat was the last decision? How much time did you kill? Che so fast / long? â
- âHow long did the last task hang in testing / review? This is a good indicator? "
10. Meeting at all rigged?
Why not. Will it stop you if not? Canât you arrive half an hour early? Relationships in the team you do not pars so.
Solution Perhaps it will help:
- âWhat time is the rally?â At this time I am having lunch / still sleeping / already at home. Will be able to move to another time? "
11. There are on duty at the time of the holidays?
12. Is there a moratorium?
Why not. Moratoria are violated, and there are admins on duty.
Solution Perhaps it will help:
- âWhen was the last time the moratorium was violated? For what reason? "
-" If I release Katni and sick, who will roll back "?
13. How often is feedback given?
Why not. Feedback on request is everywhere. Often only upon request. I believe such meetings should be held as planned, but you never know what I think.
Solution If there is a problem, do not keep it to yourself.
14. I report a problem in the review. How will it be solved?
Why not. A great chance to get a socially expected response. If you are communicating with your team leader / leader, discuss specific cases.
Solution Perhaps it will help:
- âThe product does not allow to clear the technical debt. He is wrong. âGood to hear: concrete actions are planned to solve the problem. âI'll talk to himâ is bad. âIâll come to planning, assess the situation and help find a compromiseâ - good.
15. Will the company buy me software for work?
Why not. Good will buy, bad - no. You will understand good or bad on other issues. They will buy a license for the IDE; they themselves are interested. If you need something specific and expensive, ask a targeted question.
Solution For example:
âI want Wallaby. Because look what profit ... Can I? "
-" I want to subscribe to the Kurseru. I will justify the costs. Agree? "
16. How Juneau department? How many middle and senior?
Why not. Opportunities for growth, the complexity of tasks and the experience of employees you canât do. There are skill junes, there are inert elders. Not everyone wants to grow. The first is more - they are more profitable, the second is less - it is difficult to catch.
Solution If you are afraid to grab all the black work (the only June) or if you want to share responsibility with someone (the only senior), start with other questions (see the section âExpectationsâ).
17. How long does the sprint last? How did you come to this figure?
Why not.The quality of planning you do not parse. This is a variable, and it is not taken from the ceiling. I have never met any very suspicious cases.
Solution Perhaps it will help:
- âHow many tasks have moved to the current sprint from the previous one? Why? "
18. How sync with the other teams?
19. How are conflict situations resolved?
Why not. Too arbitrary, it all depends on the circumstances. A great chance to get a socially expected response.
Solution Perhaps help:
- "two teams to do the same thing (write a generic component / to test / poriserchit), who will do it?"
- "Do you want to introduce in the common stack of new technology, how will you decide?"
20. If the plan is not fulfilled, how will they be punished?
Why not. No one will come to knock you on the hat. The maximum bonus will be deprived. Specify the award separately.
Solution Find a company where you donât have to ask this question.
21. Microservices or monorepa? How did you come to such an architecture?
Why not. The project lives on, the requirements change, the monorepa is pulled into microservices, sometimes vice versa, but not necessarily and not every. Today is so, tomorrow is different.
Solution If you are looking for architecture and âjust curiousâ - specify. You yourself know what to clarify.
22. How do developers learn about the plans and achievements of the company?
Why not.Mandatory mailing, meetings with the director, presentation before the new year, a blog on Habré, the product sends feedback from users to the general chat - let it be something.
23. Why did you decide to switch to kanban?
I believe this is a useful question, but I do not know how to parse the answer.
5 rules
For those who have read.
- Please go to the "you" whenever possible.
- Remember the names. An appeal by name is +100 to karma.
- Do not ignore. Ask everyone present personal questions: theyâll be offended that they asked everyone, but they didnât.
- Do not let yourself be charmed. A nice friendly conversation can be a bribe. Interviewers are sell-side, so everything is so fit and great. You will be surprised how much this can bring you closer to the wrong decision.
- Do not think anything, focus on the facts. Be vigilant.
The most important point
An interview is a conversation, not an interrogation. Questions are just reference points for this conversation. Where you take her, you will receive.
The main task is to find out the adequacy of requirements, the coincidence of desires and opportunities, what to expect in a new place, what not to expect. Squeeze maximum information to make it easier to make a decision. For everything else, there is a trial period. I wish you to make the right choice.
You are also appreciated for your questions. Leave a good impression about yourself.
And the last one.Did you write the code on social security? Joel was not a fool. Interviewing without a code is not the best interview. Let this be our last criterion for evaluating the company.
All Articles