Programmers, go to interviews

The picture is taken from the video from the channel "Militant Amethysts»

For about 10 years I worked as a Linux system programmer. These are kernel modules (kernel space), various daemons and working with hardware from user space (user space), various bootloaders (u-boot, etc.), controller firmware, and much more. Even sometimes it happened to cut the web-interface. But more often it happened that I had to sit with a soldering iron and interact with PCB designers. One of the problems of such work is that it is rather difficult to assess the level of your competence, since you can know one task very deeply, and next you may not know at all. The only adequate way to understand where to go and what currents are now is to go to interviews.

In this article I want to summarize my experience of going to interviews for the vacancy of a linux system programmer, the features of the interview, work and how to assess the personal level of knowledge in communication with a future employer and what should not be expected from this.

There will be a small contest with prizes in the article.

Features of the profession

A system programmer, in the specifics in which I worked, is a complete universal: I had to both write code and debug hardware. And often there was a need to solder something on their own. Periodically, it happened that my hardware adjustments were then transferred to the developers. Therefore, to work in this area, a fairly good knowledge base is required, both in the field of digital circuitry and in the field of programming. Because of this, often interviews for a system programmer look like looking for an electronics specialist.

A typical workplace of a system programmer.

In the photo above - my typical workplace at the time of debugging drivers. The logic analyzer shows the correctness of the transmitted messages, the oscilloscope controls the shape of the signal fronts. Also, the jtag debugger, which is used when standard debugging tools can no longer cope, did not get into the frame. And with all this fleet of equipment you need to be able to work.

It often happens that resoldering some elements, correcting topology errors is faster and easier on your own than carrying the product to the installer. And then a soldering station also settles in your workplace.

Another feature of development at the level of drivers and hardware is that Google does not help. Often you have to look for information on your problem, and there are three links, of which two are your own questions on some forum. Or even worse, when you see a question from the same poor fellow who asked it 5 years ago on the kernel mailing list, and never got an answer to it. In this work, in addition to errors in the design of both hardware and software, very often there are documentation errors - these are probably the most severe and unpleasant problems. Sometimes registers are described incorrectly, or there is no description at all for them. Such problems are solved only by the method of scientific typing of random numbers into certain registers (a kind of reverse). It often happens that some functionality is embedded in the processor, but no one has implemented this functionality except for you (especially if the processor is new). And this is walking around the field with a rake, of which 70% are for children. But when there is documentation, even with errors, this is already progress. Quite often it happens that there is no documentation at all, and that's where the minefields start walking when the iron burns. And yes, I also successfully solved such problems.

Interviews

My opinion is that you should go to interviews somewhere at least once every half a year, even if you love your job and do not want to change it. The interview allows you to understand your level as a specialist. I think the most valuable interviews are the ones that fail. It is they who most accurately show what bottlenecks of their knowledge should be tightened.

Another interesting feature is the quality of the interviews. This is my observation, and it is not true, I admit that I was just so lucky. If the interview goes according to the scenario:

• tell us about yourself;
• we have such tasks;
• you like?

And if after this dialogue you liked each other, you go to work, then as a rule the company and tasks turn out to be very pleasant and adequate. If the interview is like going through 12 circles of hell: the first interview with HR, then an interview with a group of programmers, then the director, more homework, etc., then as a rule these were failed organizations in which I worked not for very long. Again, this is a personal observation, but as a rule, too much bureaucracy and a lengthy hiring process shows that exactly the same processes take place inside the company. Decisions are made slowly and inefficiently. There were reverse situations when there were circles of hell of interviews, and the company turned out to be gorgeous, and when, after clapping hands, the company turned out to be a swamp, but these are rare.

If you think that the scenario of meeting, talking about yourself, and being hired only exists in small companies, then no. I have seen this in very large companies that employ more than hundreds of people and are represented on world markets. This is a normal mechanism, especially if you have a rich track record and it is possible to call your previous employers and ask about you.

For me, a very good indicator of a company when asked to show examples of their projects and code. Immediately shows the level of preparation of the applicant. And, as for me, from the point of view of selecting candidates, this is the most effective method of selection than ostentatious interviews. In fact, at the interview, you can fail from excitement, or vice versa, get out on adrenaline. But in real work, you can’t cope with real tasks. And I also encountered this when I interviewed people myself. A specialist comes, shows himself perfectly, I liked him, he liked us. And with the simplest task, he suffered for a month, as a result, another programmer solved it in a couple of days. I had to part with that programmer.

In interviews, I especially value programming tasks. And those that have to be addressed right during the meeting, in stress, and homework. The first shows how ready you are to quickly and accurately solve problems in a stressful situation and in an emergency. The second one shows the level of your competence and ability to search for information and solve current problems.

The most interesting jobs I had were in the defense complex of our country. In the process of work, I had to solve simply fantastic tasks that commercial programmers could not even dream of. Supercomputers, designing routers, various nodal combat systems - this is insanely exciting. When during the parade you see the complex that stores your code, it's really nice. Oddly enough, interviews in such companies are usually very simple, literally came, liked it - was accepted (probably the specifics of the military, who do not like to talk, are superimposed). The tasks that I had to face there were really interesting and difficult. With experience, it came that it is good to learn from them to be a quality system programmer. There are also disadvantages, and this is not even low wages. At the moment, the salary in the defense complex is quite decent, with bonuses and goodies. As a rule, this is a big bureaucracy, irregular working hours, endless rush jobs, work in a lot of stress. In certain cases, secrecy cannot be ruled out, which adds certain problems to travel abroad. Plus, of course, the tyranny of bosses-boots, and this, alas, also happens. Although the experience of working with a representative of the customer, I have, is exceptionally pleasant. This is a collective impression of three different research institutes and companies associated with the state defense order.

Tasks for interviews

So that there are no misunderstandings and in order not to substitute the companies in which I interviewed, I will not tempt fate and indicate their data. But I am grateful for every interview, for the time that people gave me, for the opportunity to look at myself from the outside. I can only say that the tasks were in large international companies represented in different countries.

I'll tell you the most interesting: what tasks are given at interviews. In general, the most frequent questions for the vacancy of a system programmer and a microcontroller programmer are bit operations, in all sorts of variations. Therefore, prepare yourself best in this direction.

The second polarity topic is pointers, this should bounce right off the teeth. So that they wake you up in the middle of the night and you can tell and show everything.

From several interviews, I dragged the questions in my head, and I will bring them here, as I find them quite interesting. I deliberately do not give answers to these questions, so that readers can independently answer these questions in the comments and there was a little gunpowder when passing a real interview.

Questions #1

I. For knowledge of SI. What do the following entries mean:

const char * str;

char const * str;

const * char str;

char * const str;

const char const * str;

Are all entries correct?

II. Why will this program give a segmentation fault?

int main ()
{
       fprintf(0,"hellon");
       fork();
       return(0);
}

III. For ingenuity.

There is a stick one meter long. Ten ants randomly fall on it, crawling in different directions. The speed of movement of one ant is 1 m/s. If an ant meets another ant, it turns around and crawls in the opposite direction. What is the maximum time you need to wait for all the ants to fall off the stick.

The next interview was a failure for me, and I consider it the most rewarding in my programming practice. It showed the depth of my incompetence. Before this interview, I was familiar with each of these questions and they constantly met in my practice, but somehow I didn’t attach much importance to them, respectively, and I didn’t understand them at five. Therefore, I failed this exam with disgrace. And I am very grateful that such a failure happened, it had the most sobering effect on me. You think that you are a cool specialist, you know circuitry, interfaces, work with the kernel. And then you have real questions and you swam. So let's see.

Interview Questions #2

hardware issues.

• How linux system calls are arranged in assembly language on an ARM processor, on x86. What is the difference?
• What are the means of synchronization? What synchronization facilities can be used inside an interrupt context, which not, and why?
• What is the difference between an i2c bus and a spi bus?
• Why are there terminators on the i2c bus and what is their value?
• Can the RS-232 interface work ONLY on two wires: RX and TX? Here I will give an answer: It turns out that it is poor, at 9600, but it can!!!
• And now the second question: why?
• What is the best way to arrange signal lines and power in multilayer boards and why? Power inside the layers, or signal lines inside the layers? (The question is generally purely on circuitry).
• Why do differential lines have traces going everywhere together?
• Bus RS-485. Usually there are terminators on such a line. However, we have a star circuit, with a variable number of plug-ins. What means of avoiding collisions and interference should be used?
• What is a red and binary tree?
• How to work with cmake?
• Questions about building yocto linux.

Tasks for this interview:

1. Write a function that inverts in uint32_t all bits. (working with beats is very popular at interviews, I recommend it)
2.

int32_t a = -200;
uint32_t b = 200;
return *(uint32_t) * (&a)) > b;

What will this function return? (solution on paper, without computer)

3. The function of calculating the arithmetic mean of two numbers int32_t.

4. What are the methods of output in programs, incl. to the error stream.

The third selection was relatively recent, and I would not be surprised if there is still such a profile, so I will not disclose the company so as not to substitute them ... But in general terms I will give an example of possible questions, and if you recognize your questions, then I say hello :).

Interview Questions #3

1. An example of a tree traversal code is given, it is necessary to tell what is done in this code and point out errors.
2. Write an example of the ls utility. With the simplest option "-l".
3. Give an example of how to make static and dynamic linking. What is the difference?
4. How does RS-232 work? What is the difference between RS-485 and RS-232? What is the difference between RS-232 and RS-485 from a programmer's point of view?
5. How does USB work (from a programmer's point of view)?
6. Translation of technical text from Russian into English.

A successful interview is not a guarantee of a successful job

This chapter is more likely not even for programmers (although for them too), but more for HR. The most adequate companies do not meticulously look at the results of interviews. It is normal to make mistakes, most often they look at how a person knows how to solve problems and reason.

One of the key problems is that the candidate successfully solves problems at interviews, shows himself to be an excellent specialist, but merges on the very first real task. I'm not going to lie, I had this too. He successfully went through all the circles of hell, solved all the test tasks, but in real conditions the work turned out to be too tough due to banal inexperience. Getting on board is not the most difficult task. The most difficult thing is to stay on board this company.

Therefore, I trust companies more that conduct simple interviews with a candidate and say: after the first month of work, it will be clear whether you are suitable for us or not. This is the most adequate approach, yes, perhaps a little expensive, but it is immediately clear who is who.

There is another option for interviews: when you successfully pass it, but according to the results of the interview, you understand that the employer is completely inadequate. I immediately refuse to work if I am offered to work as an individual entrepreneur, promising large incomes. This is a form of tax evasion for an operating organization, and why should the problems of the employer be of concern to me as a programmer? Another option is various state structures. I had an interview, as a result of which I was offered a good salary, but they said that the previous programmer quit, fell ill, died, went into a binge due to workload and your working day starts at 8 in the morning. From such a place, too, he ran so that his heels sparkled. Yes, HR, please note that programmers are ready to refuse even the most delicious vacancy if the working day has to start early in the morning.

At the end, I will give an excellent video of the selection of a programmer, a screenshot of which is given at the beginning of this article. I also had this kind of interview more than once. If you see tyranny at the questioning stage, then respect yourself, get up, take your things and leave - this is normal. If HR and the manager at the interview assert themselves at the expense of you, this indicates the toxicity of the company and you should not work there, unless you like inadequate bosses.

Conclusions

Programmers, go to interviews! And try to always go up. Let's say if you get N money, then go to an interview for at least N * 1,2, and preferably N * 1,5. Even if you do not take this vacancy right away, you will understand what is needed for this level of payment.
My observations showed that a good knowledge of the English language, a fairly rich experience in the industry and self-confidence decide. The latter is the main quality, as elsewhere in life. As a general rule, a more confident candidate can do better in an interview, even with more mistakes, than an excellent but more shy and enterprising applicant. Good luck with your interviews!

P/S Contest

If you have interesting examples of tasks that HR loaded you with, then welcome in the comment. We have prepared a small competition - the conditions are simple: you write the most unusual task that you had for an interview, readers evaluate it (plus), and in a week we sum up the results and reward the winner with funny nishtyaks.

Source: habr.com