Coding problems (LeetCode-style) in the interview process for software engineers has become a tradition in the industry. However, is this still necessary when hiring for higher level positions like, L7+ in Amazon/L6+ in Google/67+ in Microsoft?

As far as I know, the focus of the daily work and ability for engineers in this level of positions is almost about architecture design, project management, team management, maybe even about making business decisions, coding (if they do) just rarely happens in their daily work.

So I would like to know: 1. Does coding problem always necessary for all levels of software engineer position? If not, from which/what level of position? 2. For this kind of positions, what will be the focus and problems for their interview process?

-- 2/4 update:

I agree with that any engineer should be verified with their coding skill, but the tool should be some kind of real-world-like problems, instead of problem like "Merge two linked lists" or "Number of Islands".

  • Hi Fred and welcome to the Workplace. Per the site tour it's best to focus on actual problems you're having (versus generic or speculative questions). Can you explain the context in which you're asking this? Are you trying to design your own hiring process for your employer? Are you a job candidate trying to prepare for an interview? Or perhaps something else?
    – dwizum
    Jan 31, 2020 at 18:55
  • 3
    This is going to depend on the needs of the employer and what skills are necessary for the position. Levels are entirely arbitrary and impossible to define from one company to the next. This can't be answered here.
    – Seth R
    Jan 31, 2020 at 18:56
  • 1
    @ OP, what's your purpose in asking? Are you applying for architectural etc roles (or recruiting people for them!)? Or asking more hypothetically? Jan 31, 2020 at 19:21
  • Hi @FredPym - I see you've recently edited this. If you could address the text in the close reason, and/or the questions being asked of you here in comments, you may be able to get this question on topic so it can be opened and receive more answers. As is, the question has been closed because it's not very focused.
    – dwizum
    Feb 4, 2020 at 14:49

4 Answers 4


From what I have heard, they can exist at every level

I have a friend who is a very senior developer. He interviewed for an architect position where he would have overseen several different tech teams. He successfully passed 4 rounds of interviews with them on microservices, employment, management, cloud, design patterns, etc.

His final round included one of those algorithm/coding tests. He got eliminated as he couldn't code quicksort by hand from memory on a whiteboard. This was for a position that was going to have him away from day to day coding.

One of the problems is that talk is cheap. I have read half a book on microservices and have learned to talk reasonably intelligently about them. I have never actually built such a system. I just read a few chapters and picked up terms.

  • 3
    You should know the principle of Quicksort. With the principle of Quicksort, you should be able to write down reasonable code. Plus you should know how to make that code good.
    – gnasher729
    Jan 31, 2020 at 19:16
  • 3
    The problem with anecdote is that it varies. I've got a team of software engineers working for me right now and I don't use coding tests for any level of position on this team. My last employer used them only for lower level positions. And when I was contracting, I worked for a client that used them only for higher level positions.
    – dwizum
    Jan 31, 2020 at 21:20
  • 12
    @gnasher729 I have worked in software for over 30 years now, and have never needed to know how quicksort works.
    – Simon B
    Feb 2, 2020 at 17:46
  • 3
    I learned about searching algorithms and frequently forget about them. In the rare case I have to deal with them (0 till now), I look them up online, compare their performance for what I need, pick one, then look up the (pseudo)code and implement them. Dismissing candidates who are supposed to be employed for jobs which are even more far away from search algorithms than regular programmers is just plain stupid. It reeks of "college-smart" arrogance, and declining somebody for such trivial nonsense does not filter for the best fit. You can do that for junior programming jobs, if at all.
    – Battle
    Feb 4, 2020 at 10:09
  • 2
    Paraphrasing a comment I read some time ago. Keep doing those coding tests so I can have the good candidates that you filter out. Feb 5, 2020 at 21:24

Coding problems are more of a company thing: there are companies that do not do them (although this is increasingly rare) and they don't do them. Companies that do coding interviews do them for virtually all candidates, even when the person might be doing work that is well beyond what can be covered in coding interviews. Companies that do coding questions generally believe in them as a way to sanity check candidates, even though it's known to create false negatives. (Companies are generally okay with false negatives in their hiring process.)

Edit: the exceptions I'm familiar with for high level employees are basically when an individual is being hired for skills they are well-known to possess and the company is more wooing / partnering with them than screening them. For example, I've known of people who were hired to run specific projects because they are known to be experts in the field. These are the only exceptions I've known of to the general hiring process.

I can confirm that at companies where I have either worked or interviewed have used coding questions for interviews of senior employees. Some places I've worked have even periodically trained interviewers to make sure the coding questions are hard enough.


It's entirely company by company basis.

I recently changed jobs (over 10 years experience) and about 2 in 10 positions I applied to wanted me to take one, so there are places that don't require them.

Not requiring them is nothing to do with how many years you have. It's usually just company procedure. Unfortunately these tests don't suit everyone. I do terrible on them because often they have questions requiring you to know the 'exact' syntax, and as I jump between about 4 languages a day, that proves quite hard.

When I interview now I just say from the beginning that I wont take a technical test. Instead I suggest a face to face interview where they can ask me any technical questions. That way I can be judged for my understanding and approach, rather than failing because I don't remember the exact syntax.

Be aware if you do refuse the test and suggest an alternative, most companies aren't flexible enough to accommodate that, so only do it if you're not desperate.


As someone who does technical interviews for a internet company I doubt that Amazon or Google would hire someone as an senior engineer in any capacity that the interviewers feel wouldn't be able to pass an entry level coding test. Given that there is only so much time to do interviews, the focus for higher level engineering roles might be more on architecture and system design, though. A good interviewer would still figure out, if the candidate would be very rusty in actual programming.

In modern software development companies anyone in a technical will be expected to code from time to time or coach people on there coding. E.g. an architect would have to be able to show how her architecture is implemented.

Project management and team management however are not necessarily done by engineers, so you might want to apply as project or people manager, where a tech background might be expected but not actively tested.

Not the answer you're looking for? Browse other questions tagged .