Programmers, go to interviews

^{The picture is taken from a video from the channel " Militant Amethysts "}



For about 10 years I worked as a system programmer for Linux. These are kernel modules (kernel space), various daemons and work with hardware from the user space (user space), various boot loaders (u-boot, etc.), controller firmware and much more. Sometimes it even happened to cut the web interface. But more often it happened that I had to sit with a soldering iron and interact with designers of printed circuit boards. One of the problems of such work is that it is quite difficult to assess the level of your competence, since you may know one task very deeply, but you may not know at all nearby. 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 interviewing for the vacancy of a linux system programmer, the specifics of interviews, work and how to assess the personal level of knowledge in communicating with the future employer and what should not be expected from this.



The article will contain a small competition with prizes.

Features of the profession

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





A typical workplace of a system programmer.



The photo above is my typical workplace while debugging drivers. The logic analyzer shows the correctness of the transmitted signals, the oscilloscope monitors the shape of the signal edges. Also, the jtag debugger, which is used when standard debugging tools no longer cope, did not get into the frame. And you need to be able to work with all this equipment.



It often happens that re-soldering some elements, fixing topology errors is faster and easier by yourself than wearing the product to an installer. And then a soldering station also settles in your workplace.



Another feature of development at the driver and hardware level is that Google does not help. Often you have to look for information on your problem, and there are three links, two of which are your questions on some forum. Or even worse, when you come across 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, documentation errors are often encountered - these are probably the most severe and unpleasant problems. Sometimes registers are described incorrectly, or there is no description for them at all. Such problems are solved only by the method of scientific poking random numbers into certain registers (a kind of reverse). It often happens that the processor has some kind of functionality,and besides you, no one has implemented this functionality (especially if the processor is new). And this is walking in the field with a rake, of which 70% are 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 here walking already begins in minefields, when the iron burns. And yes, I also successfully solved such problems.

Interviews

My opinion is that it is worth going to interviews somewhere at least once every six months, even if you adore 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 failures. It is they who most accurately show which bottlenecks of their knowledge are worth tightening.



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

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

And if after this dialogue you like 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 resembles going through the 12 circles of hell: the first interview with HR, then the interview with a group of programmers, then the director, more homework, etc., then as a rule these were failed organizations in which I worked for not 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 within the company. Decisions are made slowly and ineffectively. There were also the opposite situations, when there were circles of hell of interviews, and the company turned out to be gorgeous, and when, after a slap on the hands, the company turned out to be a swamp, but these are rare.



If you think that the scenario: met, talked about yourself and got a job, exists only 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 have the opportunity to call your previous employers and ask about you.



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



I especially value programming tasks in interviews. And those that have to be solved 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 emergency situations. The second one shows the level of your competence and ability to seek 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 problems that commercial programmers never dreamed of. Supercomputers, designing routers, various nodal combat complexes - it's insanely exciting. When, during the parade, you see a complex that stores your code in itself, it's really nice. Oddly enough, interviews in such companies, as a rule, are very simple, literally came, liked it - accepted (probably, the specifics of the military are superimposed, who do not like to mess around). The tasks that I had to face there are really interesting and difficult. With experience it has come 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 buns. As a rule, this is a big bureaucracy, irregular working hours, endless rush jobs, work in great stress. In certain cases, secrecy cannot be ruled out, which adds certain problems for traveling abroad. Plus, of course, the tyranny of the boss-boots, and this, alas, also happens. Although the experience of working with the customer's representative is extremely pleasant for me. This is a collective impression of three different research institutes and companies associated with the state defense order.Of course, the tyranny of the chiefs-boots, and this, alas, also happens. Although the experience of working with the customer's representative, I have, is exceptionally pleasant. This is a collective impression of three different research institutes and companies associated with the state defense order.Of course, the tyranny of the chiefs-boots, and this, alas, also happens. Although the experience of working with the customer's representative, I have, is exceptionally pleasant. This is a collective impression of three different research institutes and companies associated with the state defense order.

To avoid misunderstandings and in order not to expose 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 have given me, for the opportunity to look at myself from the outside. I can only say that the tasks were for large international companies represented in different countries.



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



The second topic in terms of polarity is pointers, this one should bounce off the teeth. So that you are awakened in the middle of the night and you can tell and show everything.



From several interviews, I pulled the questions in my head, and I will give 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 powder when passing a real interview.



Questions number 1

I. 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 throw a segmentation fault?

int main ()
{
       fprintf(0,"hello\n");
       fork();
       return(0);
}

III. .



. , . 1 /. , . , .

The next interview was a failure for me, and I find 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 did not attach much importance to them, and accordingly I did not understand them for the top five. Therefore, I failed this exam in 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 floated. 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?
• ? , ?
• i2c spi?
• i2c ?
• RS-232 : RX TX? : , , 9600, !!!
• : ?
• ? , ? ( ).
• ?
• RS-485. . , , . ?
• ?
• How to work with cmake?
• Questions about building yocto linux.

Objectives for this interview:



1. Write a function that inverts uint32_tall the bits. (they love working with beats at interviews, I recommend)

2.

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

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



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



4. What are the methods of output in programs, incl. into the stream of errors.

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



Interview questions # 3

1. , .
2. ls. “-l”.
3. . ?
4. RS-232? RS-485 RS-232? RS-232 RS-485 ?
5. USB ( )?
6. .

—

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



One of the key problems is that a candidate successfully solves problems at interviews, shows himself as an excellent specialist, but merges on the very first real task. I won't be cunning, 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 yet. The most difficult thing is to stay aboard this company.



Therefore, I trust more companies 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 pass it successfully, 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 the current organization, and why should the employer's problems worry me as a programmer? Another option is various government agencies. I had an interview, as a result of which I was offered a good salary, but they said that the previous programmer quit, got sick, died, went into a binge because of the workload, and your working day starts at 8 am. I also ran from such a place so that my heels sparkled. Yes, HR pay attention that programmers are ready to give up 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 such an interview more than once. If you see tyranny at the stage of questions, then respect yourself, get up, take things and leave - this is normal. If HR and the manager at the interview assert themselves at your expense, this indicates the toxicity of the company and you should not work there, unless you like inadequate bosses.

conclusions

Programmers, go for interviews! And try to always go up. For example, if you receive N money, then go to an interview for at least N * 1.2, and preferably N * 1.5. Even if you don't take this vacancy right away, you will understand what is needed for this pay level.

My observations have shown that a good knowledge of the English language, quite a wealth of experience in the industry and self-confidence are decisive. The latter is the main quality, as elsewhere in life. As a rule, a more confident candidate can pass an interview more successfully, even with more errors, than an excellent, but more shy and proactive candidate. Good luck with your interviews!

P / S Competition

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