Senior Engineer in search of work. About tasks on technical interviews and theoretical questions

We continue to talk about technical interviews (if you have not read it - review previous articles from the cycle - about interviews with HR and technical ones ). This time there will be more subjective experience, a minimum of tips, as well as a little bit about test items and theoretical questions. Go.

Disclaimer: The author is not a turbo developer, but a regular web monkey without complaints. Therefore, the above tasks and decisions can make you smile, butthurt and a desire to indicate the author to his incompetence. I look forward to seeing you in the comments! :)

Discussion of completed test tasks

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

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

Interview on DevOps Engineer - the interviewer looked at the assignment, made a compliment (said that I had done it well) and asked a few test questions on the decision: 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 applied? and so on. As the recruiter told me, some candidates did not do the tasks themselves, and could not answer such questions. So here I managed without problems.

In the first case, I did not ask the interviewee whether he even looked at my test task and what he thinks about this. And it was necessary! If you have such a situation, be sure to indicate to those who are interviewing you.
')

Tasks for interviews

Let's continue the topic of the test tasks from the previous part and consider the tasks for coding at interviews.

Tasks can be of several types: implement an algorithm, write a solution in pseudocode, update something, and so on. Our engineers are most fond of algorithmic problems.

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

As tools that are used to solve, the code editor + repl + collaboration capability is best suited. Of all the options on the market, I like the CoderPad the most . A room is created where you and the interviewers connect, you can edit, execute code and look at the results of the implementation together. Very comfortably. If there is no money for the codepad, then repl.it and sharing of the screen goes into battle - basically the same thing, 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 work simultaneously with the code. Absolutely free! CoderPad is no longer needed, hooray!

I had an interview in the company for the position of Java Developer . The company does something like CRM and writes a bunch of integrations. I contacted a Zoom technician and he says: “Let's start with an 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?”. What I get is a phenomenal answer: “We write rest endpoints and drive json chicks back and forth, but it’s not interesting to talk about it, so let's solve the problem.” That is, the interviewer himself confessed his incompetence. I do not know how anyone, but from that moment I realized that there would be nothing to catch there. However, out of sports interest, the conversation continued.

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

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

So, I immediately wrote the tests and began to shamanize with i, j and k indices :) Cycles in cycles, and so on. Already after 15-20 minutes, I had a half-working solution, but the boundary cases that the interviewer did not pass. Another 20 minutes was spent on them, in the end, I still did the task right. The interviewer seemed satisfied, and then began to ask me about the data structures. It turned out that to solve the task that he wanted to give initially, it would be possible to use a hashset, or something like that, and he was expecting just such a solution, but I broke it all.

Further quite a bit talked about the project (forms and krudy). And then he says: “After this, there will be an interview about system design. In general, I do not see any reason to conduct it, because we don’t do this and we don’t need knowledge like that, but order is order, so the next step is so. ” Well, you understand - two (!) Interviews are held to see if a candidate can do things that are not needed in their daily work in this company. Here I allowed myself to speak a little about the meaninglessness of such interviews. The interviewer agreed with me, but he turned on the delegation of responsibility again and said: “It’s not me who decides what the process should be, so we’re doing what we’re doing.” I will add that the second interview (on system design) I did go through and it was as meaningless as the first.

What mistake did the interviewer make - he did not fix the conditions of the problem in the text. When I conducted such interviews, I simply copied the conditions of the problem into the code editor so that the candidate would have no questions left.

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

I also had an interview for the position of Ruby Developer . After acquaintance and default questions I was given the task to write the method each_slice. For those who do not know, this is the kind of thing that hits an array on subarrays of a given size and executes a block for each of them, which we passed to the method, or returns an iterator over these subarrays. I sat down to write, and then I got tuping. The problem is that in Ruby I have been doing web making for quite a while and successfully, and, as a reference intern, I did not know some basic language constructs. Namely, I did not know that the index in the for loop is immutable (unlike, for example, Java).

I wrote the method more or less quickly, but it did not work, and I could not understand why. I started to panic a bit, deleted everything and re-wrote, but my code again did not work as it should.
“It didn’t work,” I thought, and told my interlocutors: “Guys, you know, I’m good at web making and doing projects, but with your stupid tasks I’ve got something wrong. I understand that this is a simple task and a person with 10 years of experience simply must do it quickly. So let me not hold you back any longer, and we'll break up. ” The guys agreed on that part.

I was seriously bombed because I was not used to losing so easily. In order to somehow get into the existential plus, I wrote to the recruiter that I broke down on a task that has no relation to real work. Then he calmed down, sat down, quickly tested how indexes work in cycles. I realized that I made a junior error, redid the index and got a ready-made solution. In fact, I had a mistake in one line. I told HR about this and offered her to transfer the link to the solution to the guys, if they are interested, because I nevertheless solved the problem. But she replied: "You did not go further, because you did not solve the problem, forgive ." I still ponil a little about broken interviewing processes in order to justify myself somehow and we broke up.

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

I also had an interview for the position of Java Developer. This time it took place in a slightly different format. We contacted Zoom and the interviewer said: “Tell me your e-mail, I will send you a task, read it, tell if everything is clear. You will have two hours, I will be on mute and I will not watch what you are doing there (the screen is not fumbled). Two hours later we get in touch, fumble the screen and see what you did there. You can use anything. I read the conditions of the problem, spoke it again with the interviewer, turned off the video (because the encoding of the stream is being eaten by the CPU) and became confused. Opened IDE and started work.

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 would be 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 run through the docks and remember what was happening. I wrote a solution to the forehead, checked that it was thread safe, and so on. It took me about an hour and a half to do everything about everything. I pinged my interviewer, said that I was ready, but all that remained was to polish things, shall we look? To this he replied: "Let's sit for half an hour more and finish everything that you have not completed." Ok, I sat down and brought to mind all the little things and roughness, added Javadoki, read everything I could about the I / O one more time and wondered what could be the disadvantages of my decision.

Half an hour later we got in touch, I shared the screen, showed the code, ran the tests and so on. For the next half hour we talked strictly about solving the problem and possible options for modifying it when changing certain conditions. I want to draw attention to the fact that at previous interviews (and at subsequent ones too) no one prepared the basis for the conversation, she was always just some 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 so that you could add conditions and discuss with the candidate how he would refine the decision.

I really enjoyed this interview. I was able to show that not only fizz buzz can solve, but I also understand something in architectures. The interviewer made sure that in front of him is not sitting a joon, but a specialist who shoots something in his work. It was the best technical interview I've ever had. I think you have already guessed that the interviewer was not from ours :) I will also add that I successfully completed it, then two more stages and in the end I received an offer. But that's another story.

What was good about this task?

• The proximity to the real work, to what they do in that company.
• Time limit
• Lack of observation.
• The ability to use anything and not a memory test.
• Creating a basis for further conversation.
• Check the ability of the id to code, use IDE and think in general.

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

Typical deficiencies in interview tasks

1. The task does not concern the real work. It annoys me the most. Allow to solve the algorithms, although in reality the crudes are riveted. Let's take the relevant task, I will make you a cruise! Why do you need a person who can search for strings in strings?
2. Organizationally - often there is no normal tool for solving. Once I was shown 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 don’t 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 issues

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

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

The first interview, which I passed to the position of Ruby Developer , was exactly where the test task had to be done, however, as it turned out, it did not interest anyone. Timlid, who was supposed to communicate with me, did not come (stood in a traffic jam or something like that), so they gave me another. After the acquaintance, he says: “I have a rule - I spend all the interviews in English, so we are switching to English.” And here my ears are curled into a graphene nanotube, because the interviewer has a very strong accent. It made me somewhat unsettled (it is very difficult for me to communicate with compatriots in English).

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

Then there were questions about specific methods, namely: “What is the name of the method that filters all the niles in the collection?”. Then I turned on the troll and answered: “If you test my memory for knowledge of these methods, then I can’t tell you anything about something I haven’t used recently. I write in many languages ​​and platforms and do not remember all the methods of the SDK. ” The interviewer was not satisfied, and the next question was something like: “What is Enumerable? What kind of methods are there and who is its extendet. ” "Uncle, you sho, did not understand?", - I thought to myself, but said out loud: "I don’t know for sure, I think that some methods like map / reduce / slice and so on." This did not 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 in the model it does not fit, then in some other classes. It turned out that the correct answer was the so-called Service Objects (did this stuff really get here?). I grunted something back, like, well, you can call it that, but I don’t like it.

Then he asked the default question about SQL, which I was already able to correctly answer, then asked about RSpec, which I did not use, that's all. According to Rails (and they just had rails), I didn't get a single question. Also, I have not received a single question about my previous experience.

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

Then he offered to ask him questions (apparently out of politeness), and I, on my head, asked about the process, architecture, and so on. I didn’t like what I heard, because they did a lot of cycling for typical tasks. I wanted to make the guy understand that I was not just a developer, but I could do a little more, but everything was in vain, and he soon said that it was time for him to rally and set off.

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

So they refused me because I did not know the basics of the language (Ruby). Ok, we go further.

Another interview at Ruby Debeloper , already two of them. It’s good that at least one speaks Russian, the other speaks Ukrainian, so I didn’t have to break my brain. To my surprise, the same story begins: what are modules, what are blocks. I hadn’t read the textbook yet, so I swam in answers again. Further asked about the types of associations in Rails. “Finally, at least something,” I thought, and named three types from memory. The interviewers did not like it (because there were more of them), as well as what I said: “I climb in the dock for the others.” Then they gave me the task that I described above - about each_slice. After that, as you already know, I suggested that we round out. One of the interviewers finally decided to try his luck: “I then have the last question, did you once write Rack middleware?”. I do not know what he wanted to hear. I said that I did not write, but I know what it is (such as filters in Java Servlets, or middleware in some Laravel / Express), and I can quickly figure out if necessary. And again it 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 do not 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 so and I need to read the theory. If she is asked - you need to know. Nobody wants to believe that I am a good guy just to give normal tasks, so I sat down, read the textbook, and ...

Third interview with Ruby Developer. Timlid is again on vacation, so a simple developer spoke to me. The same questions about the modules and units, but I was fully armed, so I give the correct answers. The interviewer goes further and asks me what Proc is, but even here I give the right answer, although I have never used it :) Then he decides to use heavy artillery and asks: “Name the search method for the call, if we have class, it is extended from another, and there is also a module and something else there. ” Then I did not know 100% of the correct answer, so I tried somehow to logically guess which chain should be. I guess half.

Next was another question like this: “how does require”. These guys already had not Rails but Grape, so, probably, for them it was relevant. I again answered, “I don’t know right away, but probably like this, and like this.” It seems not guessed. Then there were some questions, puzzlers, like "here's a piece of code, what will it output?". Then we talked a little about ActiveRecord - here I already answered almost everything correctly, because I had a good experience with it.

Then he starts asking me about concurrency (it made me laugh). I don’t know exactly which concurrency model in Ruby is, I answered him. I added what I know about synchronization primitives, atomics, mutexes and so on. I tried to hint that your concarrency in MRI is a rotten fish in comparison with JVM and right now I will tell you about the memory models, the difference between volatile and synchronized and I will quote Shipilev, but this has not gone to 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 presenter 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 have done all the functions of writing a solid code to chopping it. The interviewer did not agree with me, and we did not have a constructive dialogue. It was the only time I was asked about buzzwords. After that, we already talked more about some architectural solutions, approaches, and so on. As a result, they missed me further, and in the end I received an offer with the note “does not know the basics of the language”. But more about that later.

What conclusion can be drawn from these three interviews? Several days passed between them. 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. I somehow was, and remained so! Knowing the theory in practice has added absolutely nothing to me (sorry for the pun). Simply, instead of reading Cracking Ruby Interview in advance, I decided to step on the rake myself. I think two or three more such interviews and my “seniority” will not cause any doubts to anyone, despite the fact that in fact I was some kind of monkey, and stayed like that :)

A few more stories and with pure theory will tie.

I had an interview at Fullstack Java Developer. I was warned that it would consist of two parts - a backend and a frontend. I don’t know the last one very well and informed the recruiter about this, but they decided to go further. Ok, contacting guys, starting with Java.

To be honest, the questions were neither theoretical nor practical, but some kind of tedious burden. I think that the person who talked to me didn’t really know what to ask. However, as a sparrow that was shot many times, I answered as needed.

Moved to the front. At the end was already sitting purely front fender. He began to ask me about past experience, and then he switched to puzzlers, such as what would happen if undefined compare with null, how the scopes and var work. A few more default JS questions and again turned to WAT issues. I immediately said: “Listen, I have never dealt with your WAT in my life. If I really need it, I’ll google it, but I think that this knowledge has no place to apply, except to laugh with the boys on mitters. ” The interviewer agreed with me, but still continued to ask puzzle questions. As a result, he advised me to read the book “JavaScript: The Good Parts”, after which I talked to the manager, and that was the case.

I was quickly informed that I was coming up, and they would schedule an interview with the customer. After some time, they contacted me again and said that the customer is not satisfied with my knowledge of the frontend (?) And therefore he does not want to have business with me, but they (the outstaff office that resold my head) will try to convince him, because in their opinion all OK. After that, no one wrote to me. Probably not persuaded :)

Although these people also tried to get some purely theoretical questions out of me, but the front-endander himself admitted that they have no such practical tasks. Front on jQuery, and need to be able to it. I said that I can and no problems :)

And I also had an interview at DevOps Engineer , where I did a test. We started talking and the interviewer asks: “What is the subnet mask?”. It was then that I fell down :) He said that this is the number of digits that represent the address of the subnet, 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 interviewer was again from another country (albeit with a Soviet background)?

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

About SOLID was asked, it seems, only two times: once at the Ruby-position, the second time - at Java. About DRY did not ask :)

What conclusions can be drawn from this?

1. The theory is still loved to ask, especially our compatriots.
2. Knowledge of the theory does not guarantee knowledge of the practice, so they like to add tasks to the theory.
3. The ability to answer questions or solve a problem does not guarantee that a person can program.
4. Ignorance of the 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 the sample sets of questions on your language / platform and memorize them thoroughly. Know the controversial questions, the answers to which just do not find out. One of my favorite questions is: “What is the lack of use of proxy AOP compared to AspectJ in Spring?” :) This is necessary to easily interview interviewers who lack imagination for normal questions.
• To solve typical algorithmic problems on LeetCode and similar resources to be ready for them.

So far, everything, 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 speculate” and other things that already look more like a proper technical interview.

Do not forget to subscribe to my telegram channel (I write smaller text there, but also interesting ones), go read the messages and until the next article!