Theses, formulated while drinking tea, about the interview process, from the perspective of the interviewer

There were four periods in my life when I was actively involved in interviewing people for work. In 1998 for his start-up in the field of chip design software, in 2010-11 for MIPS Technologies (a mid-sized company, but prestigious in its time in a narrow circle of processor builders), in 2019 for Wave Computing (a hype startup in hardware AI) and now for Samsung (in the position of designers of graphics processors for phones). I was not going to write a long text, but while I drink tea, I will sketch out a few theses, the first thing that comes to mind:

1. Most of the texts on the Internet about job searches focus on tips for writing a resume and how to pass a behavioral interview. My personal view: the real fight is not there. You can learn how to write a resume correctly in half an hour. And with companies that focus on behavioral interviews, IMHO, it’s better not to get involved at all. The main focus is two skills: the ability to clearly tell what you did in previous jobs, and the ability to solve problems.

2. As for the summary: it should be short and to the point. Long eight-page resumes are written by crazy people. If you are under 30 years old, one page is optimal, then two are fine. Every job should have an achievement. I did not “program in C”, but “developed and implemented an algorithm for register allocation in a compiler from such and such a language, taking into account the effects of the pipeline of such and such a processor.” No need to mention all the companies and all the skills – the combination of “RTL wireless chip lead block in [топ-10 электронной компании]” and “I know how to work with Microsoft Word” – this is insanity.

You only need to include in your resume what you are willing to answer questions for. One applicant wrote that he programmed in the Jovial language, thinking that he would simply be believed (in this language the US military wrote programs in the old days). The applicant was unlucky: I once leafed through a book on Jovial in the Stanford library. The expression on the applicant’s face when I asked him a question about Jovial was priceless.

3. A story about what you did at a previous job should be well structured. First you need to describe the chip or core within which you developed or verified the block. Then you need to draw on the board (real or virtual in zoom) the key elements of your block (interfaces, memories, FIFO queues), describe the course of transactions between them and the microarchitectural problems that arose. Mention the solution to problems with timing and power consumption, as well as how it is better than other solutions. The interviewer should feel that you did it, did it with understanding, and you can convey your understanding to others.

There is a subtle point here: you cannot give out the secrets of your current or previous employer. Fortunately, blocks of processors or network chips in different companies (for example, TLB MMU in processors or Egress Processing in routers) have a similar structure. Also, companies often use open inventions from academia (example: TAGE transition predictor). Therefore, it is enough for you to dance around some common knowledge spilled throughout the industry among understanding people, with slight variations. And also not to mention any benchmarks, throughputs, special patentable finds, plans and other specifically classified information.

4. The level of questions and tasks is related to your experience in the resume. If you are a fresh intern who has only a course project in his resume in which you wrote an execution unit in a training RISC-V processor, get ready to answer about delays and bypasses in the pipeline. If you mention a FIFO or SPI protocol in your resume, get ready to write the code for a simple FIFO or SPI receiver in veriolog before the eyes of the interviewer.

There are applicants from recent students who can tell in words and pictures, but have not gotten their hands on the mechanics of writing code in Verilog. This is a bad combination. Yes, I know that there is an opinion “he understands complex problems and will learn simple coding in a couple of months”. Such an opinion is found in management, especially if the student is an excellent student and is positive. But this does not work well during interviews with team engineers (see note 1).

5. In general, for those who do not know: a typical interview in a large electronic company consists of several stages: 1) recruiter; 2) technical screening by the hiring manager or one of the experienced engineers; 3) a big interview in which you talk with 5-8 engineers in 4-6 hours; 4) talking to the boss two levels up; and 5) discussing the proposal. Part (3) is critical.

This theme has variations: point (3) can be in two steps – for two days; engineers can interview you in pairs of interviewers rather than one by one; in rare cases, there are presentations of the applicant to the entire engineering team, etc.

6. It is critical for senior engineers to know some general industry know-how that everyone uses but is poorly represented in textbooks. For example, the combination of a pipeline, a FIFO queue, and a credit counter is widely used in network chips for processing packet fragment streams, and in graphics chips for processing triangle streams. But textbooks describe this very poorly: I saw it in the context of network software (not hardware), as well as in a fragment of a lecture at Princeton. If the applicant has worked in a team that clearly applies this, such as the system-on-a-chip design group at Apple, then they can 1) first ask “what is credit based flow control”? 2) if he answers “no”, then find another similar area; 3) and if he answers “yes” then ask one of the many problems on this topic.

   Some of the interview questions are covered in articles by Cliff Cummings, ideas for training on microarchitecture problems can be found on the RTLery website, etc.

7. The problem with interview questions is that any question you have can be submitted to a website like glassdoor where people share what they were asked in the interview. Against this there is an antidote – to make variations of the problems. For example, there is a well-known interview question “write a code in veriolog that takes numbers bit by bit (one bit each cycle) and determines whether this number is divisible by three (the length of the number is not limited – it can be at least a billion bits). Since this question is on such sites for a hundred years, then you can’t ask it in its pure form: you need to make a variation, for example 1) bits can come both from high to low and from low to high, or 2) determine not the remainder of division by 3, but the remainder of dividing by 7. Etc.

In conclusion, I will add that you can learn everything that I described above in practice: if you are a chip designer at the level of register transfers, you want to work on an interesting project in the GPU and (alas, this is a limitation) you have the right to work in the USA, then send me your resume.

Note 1: There is a gap between the level of basic courses at universities and the level of skills required to be successful in companies. If a student did not get his hands on educational projects himself, but only passed tests using pictures from a textbook and simple exercises, he will have a problem. Faced with a task a little further than the textbook, the student may find that what seemed simple to him (example: gearbox, bus width converter with valid/ready interfaces on input and output) suddenly becomes complex. If at the same time he does not firmly master the mechanics of a verilog such as blocking and non-blocking assignments, parameterization, etc., then he will have glitches and he will beat like a fish on ice, layer shit code and patches, debug it endlessly, hope that someone will fix it for him, etc. . This stage must be passed in educational projects, not in production. Yes, and all sorts of cache replacement algorithms and other things from the pictures in the textbook will then look different.