Greetings, in this article, I will share with you some of my views that occurred over a period of time so that both parties can have a good experience in software interviews.
First of all, regardless of the outcome of the interview, I think that the interview should contribute to both parties. The candidate should be able to leave the interview by learning new things. These things can be a technical topic, process, product, or approach.
The interviewer, on the other hand, should be able to learn to analyze people with different characters, measure different levels of knowledge, direct the subject, and create a healthy communication environment.
In this process, there are important responsibilities that fall on the parties. Now let’s go over the topics that we will examine these responsibilities.
Preliminary
The first issue I would like to mention is that the parties should have information about each other before the interview.
Having information about the company, team, and project you are going to interview contains important clues to prepare for an interview, you can predict what you will encounter. It allows you to prepare in advance some questions that you can ask during the interview.
Having information about the candidate allows the interviewers to have an interview that is suitable for the level and experience of the candidate, to skip the boring interview questions, and measure the hands-on experience of the candidate directly through the tasks he took in his previous projects and the work he has done.
This preliminary preparation also saves time to be lost by explaining the resume or the team during the interview.
Ability to Problem Solving
Rather than trying to measure the mere knowledge of the candidate you are interviewing, asking questions that will reveal the candidate’s problem-solving ability will help you see the abilities of the person you are interviewing. Specific information, a piece of code, and the behavior of a framework may not come to mind at that moment, it may be forgotten. This does not mean that the person in front of you is ignorant.
One thing that the interviewees should not forget is that they must demonstrate their problem-solving skills in the interview.
Not Personalizing Processes
What is meant by personalizing the process? What processes can be personalized in an interview?
For the candidates who are interviewed, you should consider that the questions posed to you are not so that you cannot answer, but to measure how much you know about a subject. These opposing thoughts will make you tense in the interview and feel cornered.
Interviewers, on the other hand, should not have an ego-satisfaction motive on candidates. Without focusing on understanding what the candidate knows, interviewers should not try to get pre-prepared answers specific to the subject that already knows. Be aware that you are not in a race for supremacy. There is a very important ethical value here, at that moment your company gives you the responsibility to take the deserved person to the position they deserve. You must not abuse this responsibility.
Another thing that should not be personalized, regardless of the interview process, is that you should describe your problem (for example, a person with whom you have problems in your working life) without personalizing it, through a cause-effect relationship. So how can this be done? Let’s say that when you are asked about something that you are uncomfortable with, instead of saying, “I am uncomfortable with person A, I do not work with it, he is so and so”, instead of saying “exhibiting x behaviors causes y results, these negative results disturb the motivation/peace of the employees”, it shows that you do not personalize the issue, on the contrary, you are in favor of improving processes.
Being realistic
Yes, another important issue is to be realistic. Candidates who are interviewed should first determine their expectations from the company, their working environment, and the team they will work with (salary, fringe benefits, technical responsibility, culture) and should also be able to transparently state that they can add them to the team. This is an important situation in terms of maintaining the motivation of both yourself and the other party. He should also be aware that pretending to do things he hasn’t already done will not make a good impression as it will weaken the current team dynamics.
The interviewer, on the other hand, should not raise the candidate’s expectations in such a way that cannot meet them. The image above sums up what I’m about to say. A developer who joins the team thinking that he will deal with different technical challenges every day will lose his motivation and enthusiasm quite quickly when he spends his day only with crud transactions.
Pieces of Advice
Yes, we’ve gone over the general topics so far. Now, I would like to briefly share a few recommendations with you.
Developers: Before starting to solve the problems posed to you, ask questions to find out the extent of the problem. Set limits. How many users will use the system Can the process be managed asynchronously HA, what are the consistency priorities…
Interviewers: You should not leave the candidate alone in the interview. The moment you feel that the interviewee is lost, you must take on the role of guiding.
Developers: Problems do not have a single correct solution. There are different approaches. Don’t be fooled into thinking that the other party is waiting for a single clear answer from you. Interpret the problem.
Interviewers: You cannot measure any knowledge or ability with stereotyped questions. Do not use rote interview questions and techniques.
Developers: When you come across a question you don’t know, don’t just say you don’t know and throw it away. In the worst case, try to find direction by asking questions to find out what you don’t know so that you can come up with a solution. Otherwise, your ability to produce solutions cannot be measured.
Interviewers: The candidates are not the prisoners you question. They do not have to memorize a topic, tool, or code that you have learned specifically at your workplace. Being aware of this, measure the interviewee’s approach specific to a subject. Do not try to measure mere knowledge.
Developers: Practice topics like design patterns, microservices, data structures, DDD, unit testing, architecture, caching, scaling, cap, message brokers, CI/CD. These topics will come up in most interviews.
Interviewers: Inform the candidate on a question that the candidate does not know or cannot answer correctly. Both you and your company will gain value in the eyes of a candidate who leaves the interview by learning something. Thus, even if the interview is negative, there will be no loss for both parties.
Developers: The team you will work with, the work you will do, the technologies used, the projects developed, the way of doing business, company culture, incident management… Ask questions about anything that comes to your mind. If you do not work in a happy and productive environment, you cannot be beneficial to yourself or the company.
Interviewers: Asking questions about the problems you are dealing with to get the right person to your team allows you to recruit people with the same perspective and interests. If the person you ask utopian questions to writes “just crud”, they will be disappointed.
Developers: On something actually you don’t know anything about, do not pretend like you have knowledge about it. It is very easily understood and certainly does not leave a good impression.
Interviewers: Choose your co-workers from people who fit the current team culture. Someone will not be included in the team just because they have technical knowledge, nor will they be eliminated because you find their technical knowledge insufficient. Technical knowledge can be gained later.
Developers: Do not disparage your old company, or your colleagues. If you’ve had a problem, talk about the “problematic behavior” without personalizing it.
Interviewers: Get up-to-date information about the candidate’s past projects and interests. Don’t ask funny questions like what is SOLID, what is Factory Pattern, to an experienced candidate who has worked on good projects.
Developers: Questions will be asked in order to measure how experienced you are on a subject. Don’t feel cornered or questioned. Remember that you can ask counter-questions as part of the process and you don’t have to know everything.
Thank you for reading so far. See you in another article.
Want to Connect?
Top comments (0)