Why it’s not bad to go on interviews
Even if you don’t want to change a job
Small note: this article is not about how you can manipulate with your boss to raise your salary because “every company wants me, here is offer, raise my salary now”; and this article not about how you can make fun of other companies going to their interviews and teaching them how to live. This article is about you, and how you can improve yourself.
I love to take an interview. From both sides. In this post, I will try to explain, why.
It helps your knowledges to be fresh
Memory is an interesting thing. We tend to forget everything we learned if we will not refresh knowledge. But it’s hard for me just to seat and go through all stuff we have in let’s say Java or Kotlin and repeat it. Yes, there are articles and books. But actually I find good articles on rare occasions, so I prefer books. However, usually, I use books for learning something new, or dive deep into specific things, instead of repeating things that I know. (Actually one of the ways to repeat is to write articles; I already wrote a post about that here, check this out)
From the interviewer side:
It helps you to prioritize topics and understand which knowledge important to your team. When you create or update a list of questions, you mentally not only answer them. You try to understand why you as a team need this knowledge and how knowing, for instance, hashCode and equals will help you to understand that the candidate suits you.
During the interview, it is a chance for you to speak with the candidate, and depending on the answer start to ask more deep things. Here I pointed for myself that the ideal case to ask questions like “How do you think…”. This gives the interviewee the ability to think loud and express himself. Funny thing that from productivity standpoint you ideal interview, when candidate answers perfectly. However, from a knowledge repeating standpoint, it’s the worst scenario because you will probably not ask clarification questions and will not have an interesting discussion.
From the interviewee side:
If in ordinary case it could be hard for you to learn something again, here is a stimulus. Knowing that you will talk with other people about some things leads you to mentally look over all topics to understand what you could forget. And possibly try to re-read documentation or articles on those topics.
During the interview, you have the possibility to see how good your information is structured in your head. How far you can go until you will be confused. How often you can recognize familiar topics through different angles (because on different interviews you can have different questions on the same topic).
The interview is also the way to speak and acquire some knowledge from the interviewer. Obviously, he will not give you the whole theory, but I think this is just a good manner either to make a dialog with the candidate or give him the possibility to ask questions in the end. This is your opportunity to clarify anything that could confuse you in the interview
It helps to improve algorithmic knowledge
Algorithms are important. It may seem that they not, but the truth is they are. And this is a big topic, maybe I will write a separate post for that. But the point is that most of the time you don’t need to implement anything like bubble sort or reverse a singly linked list.
Still, sometimes you face a situation when you have to choose, will you find some solution as a third party library, or will you write your own solution. This is a tough question for me. I wrote an article about that, check it please :) and sometimes when you providing own solution you need to implement let’s say a binary search, or a sliding window, or maybe some custom tree. You actually never know.
Plus knowing how to solve algorithmic tasks helps your brain to be trained more, to be structured more. It is like going to the gym for me. Or go for a run in the morning :)
From the interviewer side:
This is the best way to try to find how some abstract algorithms can be applied in real-world situations. This also helps your brain to gain experience because acquiring such knowledge serves you to improve your recognition ability. In the future, if you will face something similar it will be easier for you to find the right solution
For instance:
Given the 2d array of integers and a size K return the array, where in (i,j) place will be sum of all integers from (i-k, j-k) to (i+k, j+k).
One more freak task!!! But the reality is that this is how blurring algorithms work. You have a picture (2d array) which is just a bunch of colors (array of integers). And the result array is almost blurred one, because in blurring for each pixel you take the nearest pixels, sum them, and divide by count of them. See?)
During the interview it is your chance to explain the task; to give some hints; which can be also good training. Because sometimes it is hard to find a really good hint :)
From the interviewee side:
Before the interview, it is your chance to prepare. Solve one task per day. This is not hard, but it is like morning exercises. Take not much time, but help you to “wake up” and to warm up. Moreover, in services like Leetcode, there is a forum for each task, where you can see other solutions and acquire some experience.
Actually solving an algorithmic problem during the interview is a special dance. And this dance is a good way for you to not get confused and fail the interview. So the interview itself is a good opportunity to check how you can structure not the solution of your task, but your thoughts. And this is the main reason for simple problem-solving in the interviews: to see how you think. Then show it. Not only a solution but how you come to it. This will help you to generalize that later in different problem-solving. For example, tasks in your project :)
It helps to gain info about the company and projects
Most of the candidates come to the interview with a bunch of experience behind. And as a candidate, you come to the interview at some company. So the interview itself is a good chance to exchange some small knowledge. Yes, there are conferences and etc. But often during the interviews, no one asks something related to the company, which is wrong in my opinion.
From the interviewer side:
When you search for an engineer that fits your team, his theoretical knowledge, and ability to solve simple problems is not enough. it interesting to know more about his experience. What he has done in previous companies, the projects in previous companies, his role in previous companies.
There are different CVs. But most of the time I saw something like:
- Created new features
- Fixed bugs
- Wrote tests
- Refactored code
- Used Rx, Coroutines, hammers, nails, drunk bunch of coffee
Personally, I don’t like that, because, well, we all do that :) But it’s my thoughts, and the aforementioned experience example is a reality.
Because of that, it is important to ask clarification questions on interviews: which feature was the hardest? Which kind of tests did you write? What was the coverage? Why you refactored code? Which parts were vulnerable in terms of architecture? And etc
You need all of that not just for proper candidate’s estimation, but also for you can earn some knowledge from the candidate’s personal experience. Suppose you use Rx in the project, but the candidate said that they use coroutines now, but used Rx previously. Ask him why, maybe he will tell something that will affect you and the project, and new modules (or a new project) you will try to write with coroutines.
From the interviewee side:
In most of the interviews, they asking you so many questions but give you only 5 minutes to ask your own questions. I think this is not fair, because not only the company interviewing you. You also interviewing the company. Yes, this is a utopia. In the end, you still have only 5 minutes.
But at the same time, I’ve heard “I have no questions”. Which is strange for me. If you are interested in the company, I think you should ask questions. Especially when you know, on which project you will go to.
You can ask technologies, how they build the architecture part, which protocols are used between server and client? How the working process is built? Do or don’t they have testing and why?
This helps you to gain knowledge about the company, about technologies that are used in production. All of that grow your experience as well and affects your future decisions.
It helps you to check you soft skills
Finally, you need to develop your soft skills. Or you may not to. It’s up to you. But if you want to improve them, you need to try to find ways, how you can improve interaction with people, words you using and etc Interview is a good candidate for that.
As an interviewer, you should listen carefully, but be able to lead the conversation in the right way, especially, when you have limited time. You should also never intend that candidate is silly or using silly technologies or etc. For me, it's better to ask “why” than to say “you using wrong things”. There are tons of reasons or circumstances and you never know, maybe they wanted to change it. Or maybe they believe, that you should not refactor the codebase, and respect the owners of the code. Or they doing small incremental refactoring.
As an interviewee, this is your possibility to structure your thoughts into nice words. As for me, you should know the golden middle. You should not tell too less, because in this case interviewer can think, that you don’t know, or don’t want to tell, or you this type of person, who does talk to much, and every time it is a hard job to get a word out of you. But you also should not tell to much, because there are time limitations and because accidentally you can go to the topic, that you really don’t know, but you said so confidently.
Afterwords
Personally I like to go to interviews. This is a great way to speak with people, to see, what happens in other companies and to improve my knowledge: language, algorithms, soft skills.
Personally I like to be an interviewer. This is a great way to speak with people, to see, what happens in other companies and projects, and to improve my knowledge: language, algorithms, soft skills. But from a different angle ;)
If you liked that article, don’t forget to support me by clapping and if you have any questions, comment me and let’s have a discussion. Happy coding!
Also, there are other articles, that can be interesting:
