Senior Engineer in search of work. About tasks at technical interviews and theoretical issues

We continue to talk about technical interviews (if you haven’t read, look at the previous articles in the series -  about interviews with HR and technical ). This time there will be more subjective experience, a minimum of advice, as well as a little about test tasks and theoretical questions. Go.

Disclaimer: the author is not a turbo developer, but an ordinary web macaque with no complaints. Therefore, the above tasks and solutions may cause you to smile, butt-and-desire and a desire to indicate to the author his incompetence. I look forward to seeing you in the comments! :)

Discussion of completed test items

In the last part, I described how I did two test tasks: the first on DevOps Engineer, the second on Ruby Developer. I’ll tell you what happened next.

Interview at Ruby Developer - the interviewer didn’t even look at my test one, didn’t ask him any questions, didn’t give a compliment (I completed the task better than all the previous candidates, at least the recruiter flattered me). It seems that he did not even know about him. This upset me a little, because then they began to ask me the theory, and, as a result, they refused through the theory.

Interview on DevOps Engineer - the interviewer looked at the assignment, made a compliment (said that I had completed it qualitatively) and asked some control questions to solve: why is this line here? if you replace the condition with this, in which file will you need to do this? why is this approach used here? and so on. As the recruiter told me, some candidates did not do tasks on their own, and could not answer such questions. Therefore, here I managed without any problems.

In the first case, I did not ask the interviewee if he had watched my test task at all and what he thought about this. But it was necessary! If you have such a situation, then be sure to tell your interviewees about it.

Interview Tasks

We continue the topic of test tasks from the previous part and consider the tasks of coding at interviews.

There can be several types of tasks: implement an algorithm, write a solution in pseudo-code, refactor something, and so on. Our engineers are most fond of algorithmic problems.

Many people, including myself, believe that these tasks show only the candidate’s ability to solve precisely such problems, and do not show at all how he will cope with real work tasks, which are usually higher-level. Why are they still giving them? I think the reason is simple: interviewers are simply not able to come up with something better. And if we can’t think of anything better, let's take the good old line inversions, sorting, balancing trees, and more.

As the tools that are used for the solution, the code editor + repl + the possibility of collaboration is best suited. Of all the options on the market, I like CoderPad the most . A room is created where you and the interviewers connect, you can edit, execute code together and look at the results of execution. Very comfortably. If there is no money for a codepad, then repl.it goes into battle and screen sharing is basically the same, only without the possibility of collaboration.

Upd: while the article was being translated, repl.it added Multiplayer Mode, which allows an unlimited number of participants to simultaneously work with the code. Absolutely free! CoderPad is no longer needed, cheers!

I had an interview with the company for the position of Java Developer . The company does something like CRM and writes a bunch of integrations. I contacted a Zoom technical specialist and he says: “Let's start with the algorithmic task.” I answer: “Ok, I’ll do the task, but I have a question: do you need this knowledge in your work, do you need to solve similar things?” To which I get a phenomenal answer: "We write rest endpoints and drive json-chiki back and forth, but it's not interesting to talk about it , so let's solve the problem." That is, the interviewer himself admitted to his incompetence. I don’t know who how, but from that moment I realized that I would have nothing to catch there. However, out of sporting interest, the conversation continued.

We opened the coding pad and proceeded to the task, the condition of which I was voiced orally: "Find the longest sequence of unique characters in a given string." After that, the interviewer said that “one could give a task for dynamic programming , but we will limit ourselves to a simpler option.” I would like to look at the person who will give the task of dynamic programming at interviews, seriously.

I repeated the conditions of the task to the interviewer to make sure I understood it correctly, to which I received an affirmative answer and started working. After 5 minutes, it turned out that I still understood the problem incorrectly, because it was necessary to find not a substring, but its length (this is easier). However, I replied, "Well, since we started, then let's solve the problem with an asterisk, and not a simple one." The interviewer was a little confused, because he had prepared the tests specifically for his conditions, but I already decided that I would not give the back one and would try to do it as is. I asked how much time I have (about 40 minutes) and started coding. I note that, despite the fact that I knew that they would give assignments, I did not prepare specially.

So, I immediately wrote tests and started shamanizing with i, j and k indices :) Loops in loops, and so on. After 15-20 minutes I had a half-working solution, but the boundary cases that the interviewer gave did not go through. It took them another 20 minutes, in the end, I still correctly completed the task. The interviewer seemed satisfied, and then began to ask me about data structures. It turned out that to solve the problem that he wanted to give initially, one could use a hashset, or something like that, and he expected exactly that solution, but I broke it all.

Then we talked a little about the project (forms and piles). And then he says: “After that there will be an interview about system design. Actually, I don’t see any reason to carry it out, because we don’t do this here and we don’t need such knowledge, but order is order, so the next stage is this. Well, you understand - two (!) Interviews are conducted to understand whether the candidate can do things that are not needed in everyday work in this company. Then I allowed myself to speak a little about the meaninglessness of such interviews. The interviewer agreed with me, but again included the delegation of responsibility and said: “I don’t decide what the process should be, so we do what we do.” I add that I did go through the second interview (about system design) and it was just as meaningless as the first.

What a mistake the interviewer made - he did not fix the conditions of the task in the text. When I conducted such interviews, I simply copied the conditions of the task into the code editor so that the candidate does not have any questions.

What mistake I made - I immediately rushed to write the code, without specifying three times whether I understood the condition correctly. If you will be given such tasks at interviews, immediately disconnect from the chat and find yourself a more interesting lesson; check several times if you understood the condition correctly, write a test in the editor and you will receive confirmation from the interviewer that everything is correct.

I also had an interview for the position of Ruby Developer . After meeting and defaulting questions, I was given the task of writing each_slice method. For those who don’t know, this is such a thing that hits an array of subarrays of a given size and executes a block for each of them that we passed to the method, or returns an iterator over these subarrays. I sat down to write, and then I turned on tuping. The problem is that on Ruby, for quite some time I was successfully engaged only in web macing, and, as a reference whitelist, I did not know some of the basic constructions of the language. Namely - I did not know that the index in the for loop is immutable (unlike, for example, Java).

I wrote the method itself more or less quickly, but it did not work, and I could not understand why. I started to panic a bit, deleted everything and wrote again, but my code again did not work as it should.
“It didn’t work,” I thought, and told my interlocutors: “Guys, you know, I am good at web-hosting and doing projects, but I can’t do anything with your stupid tasks. I understand that this is a simple task and a person with 10 years of experience is simply obliged to do it quickly. So let me not delay you anymore, and we will disperse. ” The guys agreed, and parted.

I was seriously bombed because I was not used to losing so easily. In order to somehow get into an existential plus, I wrote to a recruiter that I had broken down on a task that is not related to real work. Then he calmed down, sat down, quickly tested how indexes work in cycles. I realized that I made a junior mistake, redid the index and got a ready-made solution. In fact, the error I had was on the same line. I told HR about this and suggested she pass the link to the solution to the guys if they are interested, because I still solved the problem. But she replied: "You have not gone further because you have not solved the problem, goodbye ." I still understood a little about the broken interview processes in order to somehow justify ourselves and we parted.

After that, I rethought my attitude to such tasks. Usually it was never a problem for me to code something under supervision, but several factors worked here: my application for a serious position, lack of understanding of the basic constructions of the language (although I never needed them, and if they were, then you can google the solution in 5 seconds) and the effect of the observer. Of course, I read that a lot of people cannot solve problems when they look at them, but it always seemed to me that this was some excuse for my own insecurity and incompetence, until I myself came across these harsh guys with each_slice.

I also had an interview for the position of Java Developer. This time it was held in a slightly different format. We contacted by Zoom and the interviewer said: “Tell me your e-mail, I will send you a task, read it, tell me if everything is clear. You will have two hours, I will be on the mute and will not watch what you are doing there (we don’t play with the screen). Two hours later, we get in touch, rummage around the screen and see what you did there. You can use anything. ” I read the conditions of the task, spoke it again with the interviewer, turned off the video (because the coding of the stream eats the CPU) and got confused. Opened the IDE and got started.

The task was related to I / O - it was necessary to make an API for writing data to a file on disk, so that everything was thread safe and fast, and also write unit tests that would check this (including thread safety). I have not worked with concurrency and I / O for a long time, so I had to quickly go over the docks and remember what was happening. I wrote a solution in the forehead, checked that it is thread safe, and so on. Everything about everything took me about an hour and a half. I pinged my interviewer, said that I was ready, but only the little things needed to be polished, will we look? To this he replied: "Let's sit for another half an hour and finish everything that you haven’t completed." Ok, I sat down and brought to mind all the little things and roughness, I finished the javadki, once again I read everything I could about I / O and thought what could be the disadvantages of my solution.

After half an hour, we got in touch, I shared a screen, showed the code, ran the tests, and so on. The next half hour, we spoke strictly about solving the problem and possible options for its modification when changing certain conditions. I want to draw attention to the fact that in previous interviews (and in subsequent ones too) no one prepared the basis for conversation by tasks, it was always just some kind of abstract piece that gave 0/1 at the output and we went on to the next question. And here the task was simple enough so that it could be done in a couple of hours, but at the same time thorough enough to add conditions and discuss with the candidate how he would finalize the decision.

I really liked this interview. I was able to show that not only fizz buzz can solve, but also understand something in architectures. The interviewer was convinced that he was not sitting in June, but a specialist who shoots something in his work. It was the best technical interview I have ever had. I think you already guessed that the interviewer was not one of ours :) I will also add that I successfully passed it, then two more stages and eventually received an offer. But that is another story.

What was good about this task?

• Proximity to real work, to what they do in that company.
• Time limit.
• Lack of observation.
• The ability to use anything and not a memory check.
• Creating a basis for further conversation.
• Testing the skills of the candidate to code, use the IDE and think in general.

Unfortunately, of all the interviews, I had only three such tasks, so the selection is small. Perhaps there are some more tricky tests / tasks, but I did not get them.

Typical Shortcomings of Interview Tasks

1. The task has nothing to do with real work. It annoys me the most. Algorithms are allowed to solve, although in reality the piles are riveting. Let’s the relevant task, I’ll do you a crude! Why do you need a person who knows how to search for substrings in strings?
2. Organizational - often there is no normal tool for a solution. Once they showed me the code in google docs, once I fumbled the screen in repl.it, once was CoderPad.
3. The task does not create a context for further conversation - this is a consequence of the first paragraph. Why give a task if we do not discuss it later?
4. Not all people can cope with the task under supervision. Accordingly, a good candidate can be eliminated at this stage.

Theoretical questions

This is my favorite part. Everyone loves asking theory, let's go over this a little bit.

For some reason, it so happened that most of all I was asked the theory at the positions of the Ruby Engineer. I knew her worst of all, so I constantly filled up the interviews and looked like a june until I realized that it was no longer suitable to continue like this. I sat down and read a textbook on language, which allowed me to speak much better and without whining “Guys, why are you asking me this? I am a good developer, what's the difference, what is the order of the method search for an object? Who needs this? ”

The first interview I went to as a Ruby Developer was exactly where the test task was to be done, however, as it turned out, nobody was interested. Timlid, who was supposed to communicate with me, did not come (he was stuck in a traffic jam or something), so they gave me another one. After meeting, he says: “I have a rule - I conduct all interviews in English, so we switch to English.” And then my ears are twisted into a graphene nanotube, because the interviewer has a very strong accent. It unsettled me somewhat (it is very difficult for me to communicate with my compatriots in English).

Next came the questions: what is a module, what is a block, what is yield, and I started to file. Instead of defining "as in a textbook," I began to babble: "Well, I don’t know the exact definition, but probably this is such a thing, I used it like that." The interviewer was unhappy, I began to feel it and then thought that everyone had arrived.

Then there were questions about specific methods, namely: “What is the name of the method that filters all the nil in the collection?” Then I turned on the troll and answered: “If you check my memory for knowledge of these methods, then I can’t tell you anything about what I haven’t used recently. I write in many languages ​​and platforms and don’t remember all the SDK methods. ” This did not satisfy the interviewer, and the next question was something like: “What is Enumerable? What methods are there and who will extend it. ” “Uncle, didn’t you understand?”, I thought to myself, but said aloud: “I don’t know for sure, I think there are some methods like map / reduce / slice and so on.” It didn't suit him either.

Then he asked me a standard question about where to put logic in MVC. I replied that in the model, and if it does not fit in the model, then in some other classes. It turned out that the so-called Service Objects were the correct answer (is this rubbish got here too?). I mumbled something in response, like, well, you can call it that, but I don’t like it.

Then he asked the default question about SQL, which I could already correctly answer, then asked about RSpec, which I did not use, that’s all. On Rails (and they just had rails) I did not receive a single question. Also, I have not received a single question about my previous experience.

After that, he asked me what I think about daily stand-ups. Then I decided not to give the socially expected answers (the barn burned - burn and the hut!), And immediately said that it was a waste of time and was practiced in teams where the manager could not ensure transparency and ease of reporting on progress. And he added that Scrum is garbage in vegetable oil, and no one works normally for us according to scrum, and everyone just pretends. Obviously, I still picked up the minuses.

Further, he suggested asking questions to him (apparently out of politeness), and I, on my own head, asked about the process, architecture, and so on. What I heard, I did not like, because they did a lot of cycling for typical tasks. I wanted to make it clear to the guy that I was not just a developer, but I could do a little more, but everything was in vain, and soon he said that it was time for him to rally and set sail.

The next day, a recruiter wrote to me and informed me of the refusal. “And thank God,” I thought, but still a little burnt. I got the impression that the interviewer had some prejudices from the very beginning, I don’t know. By the way, this was the same office that dragged a month from the first contact to a technical interview.

So, they refused me because I did not know the basics of the language (Ruby). Ok, let's move on.

Another interview at Ruby Debeloperalready two interviewers. It's good that at least one is spoken in Russian, the second - in Ukrainian, so I did not have to break my brain. To my surprise, the same story begins: what are modules, what are blocks. I had not yet read the textbook, so I swam again in the answers. Further asked about the types of associations in Rails. Finally, at least something, I thought, and named three species from memory. Interviewers did not like it (because there were more of them), as well as what I said: "For the rest I climb into the dock." Then they gave me the task that I described above - about each_slice. After that, as you already know, I suggested to round off. One of the interviewers finally decided to try his luck: "Then I have the last question, did you ever write Rack middleware?" I don’t know what he wanted to hear. I said I didn’t write, but I know what it is (like filters in Java Servlets, or middleware in some Laravel / Express), and I can quickly figure it out if necessary. And again, this did not suit them, so our conversation ended.

Again, no one was interested in either my experience or my knowledge in building solutions or in related fields. I don't blame those guys. Maybe they really need programmers who right now know how to write rack middleware, but I think that in fact they just do not know how to conduct interviews.

After two failures, I realized that this should not be and I need to read the theory. If asked, you need to know. Nobody wants to believe that I'm a good guy and just give normal tasks, so I sat down, read the textbook, and ...

Third Interview at Ruby Developer. Timlid is on vacation again, so a simple developer spoke to me. The same questions about modules and blocks, but I was already fully equipped, so I give the correct answers. The interviewer goes further and asks me what Proc is, but here I give the right answer, although I never used it :) Then he decides to use heavy artillery and asks the question: “What is the order of searching for a method to call, if we have a class, it extends from another, and there is still a module and something else there. ” Then I did not know the 100% correct answer, so I tried to somehow logically assume what chain should be. I guessed half.

Then there was another question, like this: “how does require work”. These guys no longer had Rails but Grape, so, probably, it was relevant for them. I again replied, "I don’t know right away, but probably like this and like that." Seems not guessed right. Then there were some puzzler questions, such as “here is a piece of code, what will it output?”. Then we talked a bit about ActiveRecord - here I already answered almost everything correctly, because I had good experience with it.

Then he begins to ask me about concurrency (here it became funny to me). I don’t know exactly which concurrency model in Ruby - that’s how I answered it. Added that I know about synchronization primitives, atomics, mutexes and more. I tried to hint that your competition in MRI is a rotten fish compared to the JVM and right now I'll tell you about memory models, the difference between volatile and synchronized and I will quote Shipilev, but that didn’t work for the interviewer. In addition, he admitted that in the project they (cannot be!) Do not use concurrency. Who would have thought? Why then ask?

Then the host decided to show off and asked if I knew something about SOLID. I said that I forgot the exact decoding, the meaning of everything roughly translates as “Do it normally - it will be normal”, and I outsourced the logger with all the functions of writing solid code. The interviewer did not agree with me, and we did not succeed in constructive dialogue. This was the only time I was asked about buzzwords. After that, we talked more about some architectural solutions, approaches, and more. As a result, I was allowed to continue, and in the end I received an offer marked "does not know the basics of the language." But more on that later.

What conclusion can be drawn from these three interviews? Between them several days passed. During this time I did not make a new project, did not receive new knowledge or new experience, did not become a better developer than I was. As I was, I remained so! Knowing the theory in practice has added absolutely nothing to me (sorry for the pun). Just, instead of reading Cracking Ruby Interview in advance, I decided to step on all the rakes myself. I think that two or three more such interviews and my “seigniority” will not cause anyone to doubt, despite the fact that in fact I was what kind of macaque, I stayed like that :)

We will tie a few more stories with a pure theory.

I had an interview on Fullstack Java Developer. I was warned that it will consist of two parts - a backend and a frontend. I don’t know the latter very well and reported this to the recruiter, but they decided to move on. Ok, contact the guys, start with Java.

Honestly, the questions were neither theoretical nor practical, but some kind of boring burden. I think that the person who was talking to me really did not know what to ask. Nevertheless, as a sparrow shot many times, I answered as I should.

We went to the front. At the other end sat a purely front-end. He began to ask me about past experience, and then switched to puzzlers, such as what would happen if undefined is compared to null, how the scope and var work. Some more default questions on JS and again switched to WAT questions. I immediately said: “Listen, I have never dealt with your WAT in my life. If you really need to, I will google it, but I believe that this knowledge has nowhere to apply, except to laugh with the guys on the caps ”. The interviewer agreed with me, but still continued to ask puzzle questions. In the end, he advised me to read the book "JavaScript: The Good Parts", after which I still talked with the manager and on that parted.

They quickly informed me that I was suitable and would schedule an interview with the customer. After some time, they contacted again and said that the customer was not satisfied with my knowledge of the front-end (?) And therefore he did not want to deal with me, but they (the office outstaff who resold my head) would try to convince him, because in their opinion all OK. After that, no one wrote to me. Probably not convinced :)

Although these people also tried to get some purely theoretical questions out of me, the front-end himself acknowledged that they did not have such practical tasks. Front on jQuery, and you need to be able to into it. I said that I can and there are no problems :)

And I also had an interview on DevOps Engineer , where I did a test. We went over to the conversation and then the interviewer asked: “What is a subnet mask?”. It was then that I fell in love :) I said that this is the number of digits that indicate the subnet address, and everything else is a range. But I don’t remember what to do with it, I haven’t set up networks for a long time. It is good that the interviewer turned out to be adequate, led me to the correct answer and did not pay attention to the fact that I could not immediately give the right answer to such a simple question. Further, the interview took place without theoretical questions. Is it worth mentioning that the interviewee was again from another country (albeit with a Soviet background)?

I was surprised that they stopped asking about design patterns at all (except for the case of MVC). In total (ha ha) 5-10 years ago literally at each interview they checked the knowledge of patterns. Since that time, I have known almost all of them (from GoF) as a keepsake and can also implement them on a piece of paper. But this year, among all the interviews, I did not receive a single question on the templates. Ruby developers can probably still be understood - they probably don’t know anything about them (they have MVC and ActiveRecord and that’s enough). But the lack of such questions in Java interviews really surprised me.

About SOLID, it seems, they asked only two times: once for the Ruby position, the second time in Java. About DRY did not ask :)

What conclusions can be drawn from all this?

1. They still like to ask the theory, especially our compatriots.
2. Knowledge of the theory does not guarantee knowledge of practice; therefore, they like to add tasks to the theory.
3. The ability to answer questions or solve a problem does not guarantee that a person knows how to program.
4. Ignorance of a theory or a file with problem solutions does not mean that you have a bad developer.

Therefore, no matter how meaningless it is, but I advise you:

• Before the interviews, study typical question sets for your language / platform and memorize them well. Know controversial questions, the answers to which simply can not be deduced. One of my favorite questions is: “What is the disadvantage of using proxy AOP compared to AspectJ in Spring?” :) This is necessary to easily pass interviews with interviewers who lack the imagination for normal questions.
• Solve typical algorithmic problems on LeetCode and similar resources in order to be ready for them.

That's all, again, a lot of text, I hope you were interested. In the next part, we will talk about questions about past experience, questions about system design, questions “to think and reason” and other things that are more like a proper technical interview.

Do not forget to subscribe to my telegram channel (I write less text there, but they are also interesting), go read the brochures , and see the next article!