Senior Engineer in search of work. How I passed 15 technical interviews and what I think about it
Continuation of the story of how I passed the interviews in different companies in different positions. This time we will close a few questions and comments regarding the first part and continue to talk about the test tasks and technical interviews.
To my surprise, the previous article about interviews with recruiters and HR aroused an unexpected interest: more than 100,000 views from all sources. I received a bunch of positive feedback in PM, I was written by former colleagues whom I last saw about 5 years ago; heroine of some stories; the guy to whom I sold a systematist a few weeks ago through OLX the drummer with whom we played metal in the garage last year, and, oddly enough, quite a lot of recruiters took an interest in my thoughts on various aspects of interviewing and hiring. 250 people for some reason were added to me on LinkedIn :).
Before proceeding to the case, I will answer the most popular questions and personal messages and comments.
A lot of comments related to money. I deliberately did not pay much attention to this, because the auction was a separate topic, but commentators still touched it and pointed out the shortcomings of my strategy — for example, immediately call the price. Here are two good articles that deal with this issue in a much more detailed and professional way:
')
I recommend to read before looking for work.
I by no means give advice to recruiters on how to do their work. I am not a professional recruiter, and I don’t know how their internal kitchen works. When I had to look for personnel (not only to conduct technical interviews, namely, to search and hire - a full cycle), these were junior positions, respectively, I did not have any particular difficulties.
In personal messages, I was asked how to make the first message about the offer to work, so that it looked attractive and interested the specialist, how to draw attention to yourself?
It seems to me that, unfortunately, nothing depends on the recruiter. All that a recruiter can do is to find as many contacts as possible of the specialists of the required profile and send them amessage . After that, you need to wait and hope that one of them either already hesitates or is actively looking for work. That is, there is 20% of work with the base and 80% of luck. There are a lot of materials in the network about how to properly create vacancies and so on, but as for me - the key factor is the candidate’s desire to change jobs.
Recruiting is selling a job to a candidate. The sooner you understand this and start pumping your salesman skills, the better. Oh, I told you that I will not give advice :)
I am also convinced that during job searches, candidates need to be taken on all vacancies that are more or less suitable, because in fact, finding out what the vacancy is about is possible only during a conversation with technical experts. In my search, I almost did not pay attention to what is written in the vacancy, and found out the necessary details at the technical interview stage. I believe that this method is the most correct, because the chances of finding a cool project that can hide behind a standard gray description increase significantly. My experience only unequivocally confirms this thesis. Not once in a vacancy was it written specifically what needs to be done. Only common phrases like “code code, test tests, deployment”.
In our realities - definitely on the project.
I positioned myself as a candidate for Senior Software Engineer and higher - Team / Tech Lead, Principal Engineer, Software Architect, Project Manager, People / Group Manager and so on. It is this “higher” that was meant by “+” in “Senior +”.
It seems to me that the title means nothing. What matters is what you will actually do, and this can only be found out from the person with whom you will work.
So, ladies and gentlemen, let's move on to the technical interviews.
In this part there will be more of my subjective experience and philosophy than of tips. Information about what is asked for technical interviews, and how to prepare for them, on the Internet is full.
disclaimer: the author is not a turbo-engineer-olympiadnik, so some decisions or comments may cause a smile, a bat hurt, a desire to indicate the author to his mistakes or low qualifications from the relevant specialists I am pleased to hear constructive.
In total, I passed 15 technical interviews, which, as for me, not so much. I could have gone much more, but on average I waited a week from the first contact with the recruiter to the conversation with the technical specialist. This is despite the fact that I practically had no time limits. Only once I was assigned an interview for the time for which I had already scheduled another interview. Also note that all companies or recruiters came to me themselves. I did not send a CV to any company first. This is to the question that not the seigneur is looking for work, and the work is the seigneur.
Many companies give test assignments before moving on to a conversation to weed out irrelevant candidates. Despite the fact that many people don’t like to invest their time in test tasks, especially if they are rather voluminous, I still think that this is a good practice. Consider what can be the test items.
“Make a project from scratch (perhaps using a specific technology) and post it on GitHub” - as for me, the worst option. You can spend a lot of time on the boilerplate, on the infrastructure around the solution, and the interviewer, as a rule, will be interested in several small implementation details laid down in the task. Well, if you have at hand, for example, project templates and you can raise the server in 5 minutes and quickly code what you need. Otherwise, you have to remember everything and start from scratch. It is also bad if there is a condition in the task to use external dependencies, for example, a non-embedded database.
"Here is a link to the site with tests - go through them" - a very cool option. What is the point? There are SaaS, which allow you to configure a set of practical and theoretical issues, and for the solution provide the REPL and code editor directly in the browser, as well as provide an opportunity to run verification tests. Then you just go on assignments, correct existing or write your code, run it and see the results. The tests themselves are hidden from you, you see only the result (passed / failed) and a short description of the test, which at the same time can be a hint. Why do I like this option the most? Because there is an unequivocal criterion for the quality of the assignment, and the candidate knows exactly how many points he scored, whether his decisions work, and so on. I personally was even interested to complete these tasks. The only thing I do not see the point in theoretical issues like "what will happen if you execute this code" - they are easy to google.
“Here is the repository, there is a task, send a Pull Request with a solution” - I did not come across this option, but my colleagues used it. I don’t really like it, because you can see how other candidates performed the task (if they were).
The disadvantages of this method are obvious: the verifier needs to download the code, compile, watch what's there, it's long and boring. Of course, you can superficially look at the code in the browser, but why then was the task necessary? Let us then write in pseudocode.
“Here is the repository, the code is there, refactor it as far as you can” - a variation of the previous one This is better, because here from the very beginning a framework is created in which you can work. The disadvantages are the same: it is not clear when to stop. As Yegor Bugaenko said , any program contains an infinite number of errors, and they can also be fixed infinitely.
The authors of the assignment must have had something in their head when they created it, and we most likely never find out what was the main thing for them. If the task had a clear criterion, then it would be cool. For example, “there is a code, it produces such a result in terms of speed, refactorize, so that it works twice as fast”. Without criteria work hard. In real life, in real work, we always have a framework and are looking for the optimal solution, guided by this framework and common sense. The main work of the developer - just feel this balance and find the appropriate solution.
To my great regret, no one else gave test items, so my sample is quite small. Unless I can remember those test ones that I did many years ago. All of them were of the first type - it was necessary to make a project. It is interesting that I performed them in those times when GitHub was not so popular yet and it was necessary to send the solution in a zip-archive by mail :)
My recommendations for test tasks?
Well, test, you, I hope, successfully completed, passed this information to the recruiter, and after an indefinite time you will be invited to talk in person.
To begin with, it is now rarely invited to the office for interviews. I was called to the office only a few times - for interviews on the position of Solution Architect, Tech Lead, and once - for a managerial position. All other interviews were held by Skype, Zoom, Hangouts. As in the previous interview with a recruiter, the recommendations are the same - a good camera, a good headset, a good Internet. To this also add the condition of fumbling the screen. Therefore, make sure that you do not have open working projects (if this is important) and other personal things that do not need to be shown to people at that end. Keep a clean browser without tabs at hand and a REPL for coding just in case (IDE or repl.it ).
Of all the communication methods, I like Zoom the most. Actually, it was used most often.
Before the interview, go over the vacancy once again, pay attention to the requirements for the candidate and prepare the speech. I was interviewing at Tech Lead, DevOps / SRE, Ruby / Java Software Engineer and in each case told different things that I think would interest the interviewer more. Try not to go into details, but provide the information that will create a vector for further discussion. It is not necessary to speak in detail about what you did 5 years ago (unless of course this was something extraordinary).
I said, for example, this: “I worked in an enterprise for 8 years, mostly with Java. Then I went to a startup, where I worked on infrastructure. The last two years I've been writing mostly on Rails. ” Everything, interviewers have enough information, and they will promote the conversation in the key that interests them.
And now an unexpected fact.
Honestly, it turned out to be a great discovery for me. Well, well, recruiters do not read LinkedIn profile, because it may not be updated, HR has the skill to view CV diagonally, and highlight the main thing. But people who conduct a technical interview, certainly will not read your resume. Not a single, I emphasize, not once did I feel that people even looked at what I had written there with at least one eye. I suspect that, as a rule, they learned that it was necessary to conduct a technical interview the day before the interview itself, and decided to read the CV 5 minutes before the call, and then somehow it would be there.
But it hurts me the most. In 80% of cases I was dealing with angry, sleepy, tired introverts who were clearly not interested in hiring someone. They were technically literate people and good specialists, but for some reason they didn’t have a desire to actually hire a colleague, there was no desire to take a good engineer for the team that would help them.
I am convinced that these were people who were simply hanged up with the obligation to conduct interviews. Several times I was told that the right person was on vacation, or did not have time to come, or was busy, or something else. They already have a lot of their affairs, problems on the run, do not have time to sprint, meetings with the client, and here again another candidate pinned what to do with him, huh? The problem follows from this: interviewers do not consider you as a person with whom they will need to work, but simply try to assess whether you are normal or not from their point of view. Quite often was the situation when “the first team leader is now busy, so the interview will be conducted by another person.”
I had only a few conversations with the engineers, which showed that yes, they really needed people, they wanted to hire a good specialist, they had a plan for me and so on. And so go to the next item.
This is a consequence of the previous one. I am deeply convinced that you must speak to someone to whom you will obey, formally or informally. All organizations have some kind of hierarchy, be it a Scrum team or a bloody enterprise. Everywhere there is a person who will look after you (at least at the start).
Unfortunately, you can not do anything about it. Yegor Bugaenko in his post “Why I Don't Talk to Google Recruiters” described this situation very well. If you demand a conversation with your future boss - you just will not get to any interview.
It seems to me that now it is one of the biggest problems of hiring with us. Perhaps this is dictated by the specifics of the projects - outsourcing, where people do something on the stream. Perhaps, in general, a bad communication culture and a misanthropic mentality, I do not know.
It is often written in English-language blogs that hiring is one of the key areas vital for building a successful company. I think our companies will need a lot more time to come to this and form the right culture. For now it is necessary to outsource it to customers.
To my surprise, the previous article about interviews with recruiters and HR aroused an unexpected interest: more than 100,000 views from all sources. I received a bunch of positive feedback in PM, I was written by former colleagues whom I last saw about 5 years ago; heroine of some stories; the guy to whom I sold a systematist a few weeks ago through OLX the drummer with whom we played metal in the garage last year, and, oddly enough, quite a lot of recruiters took an interest in my thoughts on various aspects of interviewing and hiring. 250 people for some reason were added to me on LinkedIn :).
Before proceeding to the case, I will answer the most popular questions and personal messages and comments.
How to negotiate a salary at the interview
A lot of comments related to money. I deliberately did not pay much attention to this, because the auction was a separate topic, but commentators still touched it and pointed out the shortcomings of my strategy — for example, immediately call the price. Here are two good articles that deal with this issue in a much more detailed and professional way:
')
- How to discuss money at the interview: the negotiation strategy for the applicant
- Salary Negotiation: Make More Money, Be More Valued
I recommend to read before looking for work.
A few thoughts about recruiting
I by no means give advice to recruiters on how to do their work. I am not a professional recruiter, and I don’t know how their internal kitchen works. When I had to look for personnel (not only to conduct technical interviews, namely, to search and hire - a full cycle), these were junior positions, respectively, I did not have any particular difficulties.
In personal messages, I was asked how to make the first message about the offer to work, so that it looked attractive and interested the specialist, how to draw attention to yourself?
It seems to me that, unfortunately, nothing depends on the recruiter. All that a recruiter can do is to find as many contacts as possible of the specialists of the required profile and send them a
Recruiting is selling a job to a candidate. The sooner you understand this and start pumping your salesman skills, the better. Oh, I told you that I will not give advice :)
I am also convinced that during job searches, candidates need to be taken on all vacancies that are more or less suitable, because in fact, finding out what the vacancy is about is possible only during a conversation with technical experts. In my search, I almost did not pay attention to what is written in the vacancy, and found out the necessary details at the technical interview stage. I believe that this method is the most correct, because the chances of finding a cool project that can hide behind a standard gray description increase significantly. My experience only unequivocally confirms this thesis. Not once in a vacancy was it written specifically what needs to be done. Only common phrases like “code code, test tests, deployment”.
Hire a company or a project
In our realities - definitely on the project.
How to choose a title
I positioned myself as a candidate for Senior Software Engineer and higher - Team / Tech Lead, Principal Engineer, Software Architect, Project Manager, People / Group Manager and so on. It is this “higher” that was meant by “+” in “Senior +”.
It seems to me that the title means nothing. What matters is what you will actually do, and this can only be found out from the person with whom you will work.
So, ladies and gentlemen, let's move on to the technical interviews.
Stage Two. Technical interviews
In this part there will be more of my subjective experience and philosophy than of tips. Information about what is asked for technical interviews, and how to prepare for them, on the Internet is full.
disclaimer: the author is not a turbo-engineer-olympiadnik, so some decisions or comments may cause a smile, a bat hurt, a desire to indicate the author to his mistakes or low qualifications from the relevant specialists I am pleased to hear constructive.
In total, I passed 15 technical interviews, which, as for me, not so much. I could have gone much more, but on average I waited a week from the first contact with the recruiter to the conversation with the technical specialist. This is despite the fact that I practically had no time limits. Only once I was assigned an interview for the time for which I had already scheduled another interview. Also note that all companies or recruiters came to me themselves. I did not send a CV to any company first. This is to the question that not the seigneur is looking for work, and the work is the seigneur.
Test items
Many companies give test assignments before moving on to a conversation to weed out irrelevant candidates. Despite the fact that many people don’t like to invest their time in test tasks, especially if they are rather voluminous, I still think that this is a good practice. Consider what can be the test items.
“Make a project from scratch (perhaps using a specific technology) and post it on GitHub” - as for me, the worst option. You can spend a lot of time on the boilerplate, on the infrastructure around the solution, and the interviewer, as a rule, will be interested in several small implementation details laid down in the task. Well, if you have at hand, for example, project templates and you can raise the server in 5 minutes and quickly code what you need. Otherwise, you have to remember everything and start from scratch. It is also bad if there is a condition in the task to use external dependencies, for example, a non-embedded database.
DevOps Engineer Position. They sent me a task to make a Vagrant configuration of several virtual machines, among which were supposed to be web servers with statics, a balancer for them and Jenkins. All of this needed to be installed and configured using Chef. Now imagine - I have never used Vagrant, Chef and did not configure those web servers that were required in the task. I understand about how it all works, I dealt with similar tools, but I never used these tools specifically.Unfortunately, I don’t have more stories about this type of tasks, because in general, the test ones didn’t give too much :(
I had to sit down for the night, install it all, collect a bunch of rakes and in the end still perform the task. The main difficulty was that I had an old MacBook Pro of the 15th year, which just physically did not have time to restart the containers, as well as that I had no experience with Vagrant.
On the essence of the task - to figure out how to install what - it probably took me half an hour. The rest of the time (7 seconds) I spent on installing the entire toolkit, restarts — reboots, poking through configs in an attempt to understand why it was not working, and so on.
I would do the same task on the Docker Compose, probably in an hour, maybe even less. Was it possible not to limit the candidate tools? It seems to me that it is possible.
Was this task helpful to me? Definitely yes! Now I will know that you need to stay away from Vagrant and Chef :)
Time spent - 8 hours .
"Here is a link to the site with tests - go through them" - a very cool option. What is the point? There are SaaS, which allow you to configure a set of practical and theoretical issues, and for the solution provide the REPL and code editor directly in the browser, as well as provide an opportunity to run verification tests. Then you just go on assignments, correct existing or write your code, run it and see the results. The tests themselves are hidden from you, you see only the result (passed / failed) and a short description of the test, which at the same time can be a hint. Why do I like this option the most? Because there is an unequivocal criterion for the quality of the assignment, and the candidate knows exactly how many points he scored, whether his decisions work, and so on. I personally was even interested to complete these tasks. The only thing I do not see the point in theoretical issues like "what will happen if you execute this code" - they are easy to google.
Position Ruby Software Engineer. I am sent a link to the TestDome site, of course, to the custom test. I click, I get into the actual tests. They give me 2.5 hours to complete the entire set, 5–20 minutes for each question. In fact, I really liked it, I have not passed such things for a long time. Especially liked the TDD-approach: code, launched, looked at what fell, code on. Passed with great pleasure.Also, the great advantage of this type of tasks is that their verification is automated. We all know how interviewers “love” to check assignments, and here the machine does everything for them - it’s very convenient, at least, that you don’t need to download the code and collect it. Perhaps I will use this method when hiring in the future.
The tasks themselves were pretty simple: fix the code (Ruby / JS / CSS / HTML), write validators (Ruby), implement data structures (Ruby), nothing special. However, the fact that you can immediately verify that the solution works helps a lot.
I coped with the task for 93/100 balls in just an hour. Unfortunately, this result did not help me at all in the future.
TDD helps in the decision, you do not need to spend time on raising the infrastructure, repl right in the browser - in short, very cool. For the sake of this, it was possible to wait a month - in the end, I received my portion of dopamine (I did an excellent job with the task) and adrenaline (the clock ticking, time is running out!).
Time spent - 1 hour.
“Here is the repository, there is a task, send a Pull Request with a solution” - I did not come across this option, but my colleagues used it. I don’t really like it, because you can see how other candidates performed the task (if they were).
The disadvantages of this method are obvious: the verifier needs to download the code, compile, watch what's there, it's long and boring. Of course, you can superficially look at the code in the browser, but why then was the task necessary? Let us then write in pseudocode.
“Here is the repository, the code is there, refactor it as far as you can” - a variation of the previous one This is better, because here from the very beginning a framework is created in which you can work. The disadvantages are the same: it is not clear when to stop. As Yegor Bugaenko said , any program contains an infinite number of errors, and they can also be fixed infinitely.
The authors of the assignment must have had something in their head when they created it, and we most likely never find out what was the main thing for them. If the task had a clear criterion, then it would be cool. For example, “there is a code, it produces such a result in terms of speed, refactorize, so that it works twice as fast”. Without criteria work hard. In real life, in real work, we always have a framework and are looking for the optimal solution, guided by this framework and common sense. The main work of the developer - just feel this balance and find the appropriate solution.
To my great regret, no one else gave test items, so my sample is quite small. Unless I can remember those test ones that I did many years ago. All of them were of the first type - it was necessary to make a project. It is interesting that I performed them in those times when GitHub was not so popular yet and it was necessary to send the solution in a zip-archive by mail :)
My recommendations for test tasks?
- Do not like it - do not. If the task, for example, to complete the whole site or write a crud - well, it is in the bath. Tasks should be short and focused on creating context for the subsequent discussion, and not just a test of how you can do scaffolding.
- If the task is of the first type, add a readme to the repository, where in details describe the instructions for launching, a short annotation about why you made such a decision, what are the flaws in it, what you liked or didn't like, how would you decide the task, if you had more time and so on. I don’t know if this helps realistically, but, as an interviewer, I would definitely mention this documenting of the decision.
- Write fine, but do not spend a lot of time licking parts. As for me, it’s enough just to list in the readme everything that you would improve if it was a combat code.
- Be sure to think about what questions you may have about the implementation and read additional documentation about the API that you used. Suppose I have not worked with concurrency for a long time. I have not practiced this for a long time, so after the decision I quickly went through all the related topics, remembered all the typical tasks and was ready to talk.
Well, test, you, I hope, successfully completed, passed this information to the recruiter, and after an indefinite time you will be invited to talk in person.
Technical interview. Intro
To begin with, it is now rarely invited to the office for interviews. I was called to the office only a few times - for interviews on the position of Solution Architect, Tech Lead, and once - for a managerial position. All other interviews were held by Skype, Zoom, Hangouts. As in the previous interview with a recruiter, the recommendations are the same - a good camera, a good headset, a good Internet. To this also add the condition of fumbling the screen. Therefore, make sure that you do not have open working projects (if this is important) and other personal things that do not need to be shown to people at that end. Keep a clean browser without tabs at hand and a REPL for coding just in case (IDE or repl.it ).
Of all the communication methods, I like Zoom the most. Actually, it was used most often.
Important advice regarding proper communication in newsgroups: make a habit of not speaking or typing on the keyboard when the other person speaks, and talking on the headset, and not, for example, through an external laptop microphone and external speakers.If everything is ok, there are pings back and forth, then the conversation will begin. Often, the interviewers themselves offer a plan of conversation. It happens that they do not have a plan, but at least one topic will always be relevant: “Tell us about yourself and your experience . ”
Why is it important? Most often two people will talk to you, respectively, they will not use the headset. When you speak, the software on their side includes a noise that prevents the feedback effect (background, whistle, echo) from appearing. When the noise is turned on, their microphone will practically catch nothing, so you will not hear what they say to you.
When you type on the keyboard, it creates noise, which is transmitted to the other side and also turns on the noise. As a result, the phrases break off and you get the impression of a bad connection. Therefore, you should always wait until people finish the conversation. Otherwise, you simply will not hear what they wanted to say (except when the interlocutors also use the garment). Oddly enough, many people do not know about these mechanisms. It is also useful to turn off (mute) the microphone for as long as you do not speak, so that sounds from your room do not break through to people. I was brought up by years of work in the enterprise, where everyone knows these rules, so this is obvious to me, but I have seen many situations when people did not follow these elementary rules and sinned on the bad Internet.
Before the interview, go over the vacancy once again, pay attention to the requirements for the candidate and prepare the speech. I was interviewing at Tech Lead, DevOps / SRE, Ruby / Java Software Engineer and in each case told different things that I think would interest the interviewer more. Try not to go into details, but provide the information that will create a vector for further discussion. It is not necessary to speak in detail about what you did 5 years ago (unless of course this was something extraordinary).
I said, for example, this: “I worked in an enterprise for 8 years, mostly with Java. Then I went to a startup, where I worked on infrastructure. The last two years I've been writing mostly on Rails. ” Everything, interviewers have enough information, and they will promote the conversation in the key that interests them.
And now an unexpected fact.
Your resume nobody reads
Honestly, it turned out to be a great discovery for me. Well, well, recruiters do not read LinkedIn profile, because it may not be updated, HR has the skill to view CV diagonally, and highlight the main thing. But people who conduct a technical interview, certainly will not read your resume. Not a single, I emphasize, not once did I feel that people even looked at what I had written there with at least one eye. I suspect that, as a rule, they learned that it was necessary to conduct a technical interview the day before the interview itself, and decided to read the CV 5 minutes before the call, and then somehow it would be there.
Do not misunderstand me: I am not a narcissus or a dancer “circle me, circle”. I know that I have a lot of weaknesses (both from the techie and the manager). I do not expect interviewers to look at me like monkeys on the Obelisk.And again I will express my displeasure with such an attitude. You and I, if you are already a gentleman-tomato, are specialists with respect to a serious level in your field (let me remind you, I have this form-slapping and cradles). There are not many people like us in the market, so please show respect, read what I did. I read about your company, project, client. I expect to be treated like a person. Why does the opposite happen?
I do not demand that the praises be sung to me and show respect from the first minutes of the conversation.
I just expect people to train, especially since it only takes 10 minutes. Re-read CV, it is possible to look at the links that are there, to prepare an exemplary list of questions and to reduce the total talk time.
Personally, I always read the CV before the interview and thought that I would be interested in talking with the candidate. Unfortunately, almost no one knows how to prepare a normal resume, so the task is not easy.
Nobody needs you
But it hurts me the most. In 80% of cases I was dealing with angry, sleepy, tired introverts who were clearly not interested in hiring someone. They were technically literate people and good specialists, but for some reason they didn’t have a desire to actually hire a colleague, there was no desire to take a good engineer for the team that would help them.
I am convinced that these were people who were simply hanged up with the obligation to conduct interviews. Several times I was told that the right person was on vacation, or did not have time to come, or was busy, or something else. They already have a lot of their affairs, problems on the run, do not have time to sprint, meetings with the client, and here again another candidate pinned what to do with him, huh? The problem follows from this: interviewers do not consider you as a person with whom they will need to work, but simply try to assess whether you are normal or not from their point of view. Quite often was the situation when “the first team leader is now busy, so the interview will be conducted by another person.”
I had only a few conversations with the engineers, which showed that yes, they really needed people, they wanted to hire a good specialist, they had a plan for me and so on. And so go to the next item.
You will not talk to your future boss or team leader.
This is a consequence of the previous one. I am deeply convinced that you must speak to someone to whom you will obey, formally or informally. All organizations have some kind of hierarchy, be it a Scrum team or a bloody enterprise. Everywhere there is a person who will look after you (at least at the start).
Unfortunately, you can not do anything about it. Yegor Bugaenko in his post “Why I Don't Talk to Google Recruiters” described this situation very well. If you demand a conversation with your future boss - you just will not get to any interview.
It seems to me that now it is one of the biggest problems of hiring with us. Perhaps this is dictated by the specifics of the projects - outsourcing, where people do something on the stream. Perhaps, in general, a bad communication culture and a misanthropic mentality, I do not know.
It is often written in English-language blogs that hiring is one of the key areas vital for building a successful company. I think our companies will need a lot more time to come to this and form the right culture. For now it is necessary to outsource it to customers.
A bit of past experience. When I was hired for a current job, I spoke directly with CTO and the CEO. I would have to be the first engineer in a startup, so the attitude towards me was very scrupulous and serious. As a result, we worked together perfectly, and the interview was one of the best ones I had. We discussed not only technical details, but also the first steps and plans for several months ahead.So far, all the materials and thoughts are many, Longrid came out again, no matter how hard I tried. In the next part, we will continue to look at the topic and move on to specific questions and methodologies that are used in technical interviews.
Even if the interview is not conducted by your immediate supervisor, be sure to ask for thebeer to be poured after you staywith him before accepting the offer (of course, if you manage to go through all the steps).
Source: https://habr.com/ru/post/434864/
All Articles