107

I rarely act as a "programmer" in my daily job. I lead a team of engineers and consider myself and engineer. I build features, fix bugs, work on APIs, DBs, etc., but I rarely ever have to write algorithms... and when I do... I just google the best way to do something and this has worked for me for the last decade.

I've wasted a lot of time being interviewed by people who want me to solve LeetCode style questions and I just don't care to get into them. I'm a lead engineer with a good resume and pay, and I want to maintain this kind of position throughout my career.

How do I tell companies that I'm not interested in fiddling with algorithms in order to interview with them?

1
  • 2
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Neo
    Aug 20 '20 at 13:18

13 Answers 13

128

First of all you might have your terminology wrong. How I see the words used "programmer" more often describe position where simple code is written according to existing specifications and APIs, where "Software engineer" is a job that involves complex algorithms, design patterns, architecture and system design. You might want to look for programming jobs instead of software engineering jobs.

I'm a Lead Engineer with a good resume and pay, and want to maintain this kind of position throughout my career.

I think this is the exception and most companies expect a lead software engineer to be able to solve simple variations of a graph problem or list search. If you want to be a lead engineer, I think you should get used to the idea of learning algorithms. Not that you are expected to write complex algorithms every day, but if you are not able to see the difference between a O(N^2) solution and a O(N) solution, you will not be able to recognize a problem when you stumble about it, e.g. when as a lead engineer you are reviewing the code of more junior developers.

So if you interview for a "lead software engineer" position chances are high that you are wasting your time. Have you considered looking for more managerial roles, like infrastructure manager or engineering manager?

5
  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Neo
    Aug 20 '20 at 13:59
  • 5
    I think this is reaaaaaaly country specific. In most European countries most companies don't care much. You might be able to write amazingly efficient algorithms, but if your code looks like shit and is unmaintainable, you still shouldn't be hired. So, a lot of companies give you a coding assignment instead. A real problem that you have to solve in a few days. No need to make it super efficient. But it has to be maintainable and it has to work right Aug 22 '20 at 12:40
  • I can speak a bit from personal experience that while the Google interviews are algorithm-heavy, it is supposed to be adjusted based on the position, and the emphasis is more on being able to puzzle out a good approach than for you to be able to solve it in a particular correct way. Yes, some interviewers don't get that right, of course. Aug 22 '20 at 14:46
  • 1
    I'm a software engineer and now software architect. I worked for the biggest banks in my country, for multiple government branches, for logistics/transport companies - and I never had to write a single "algorithm" in my entire career.
    – fgysin
    Aug 24 '20 at 12:17
  • Most jobs at least in my past 10 years as a SW Engineer in Finland have had pretty much zero algorithms involved. AWS implementations, frontend/UI, rest apis, database queries and model updates and migrations, integrations, log investigation, deploying, Jenkins configuration, unit and integration tests, etc. A wealth of e2e software work yet never was there a need to do algorithm design or implementing an algorithm from scratch. Apr 30 at 6:26
130

Concert pianists can still play scales. Algorithms aren't some weird thing that only academicians use. They are minimal, encapsulated design patterns that are used quite a bit in most every domain. Yes, no customer is going to come to you and say, "Please implement a binary search in your next software release," but they will say, "This page is way too slow" and a binary search will happen to be the best way to fix it.

If you get a "this is too slow" problem and you can't connect the dots to know you need a binary search, and be able to communicate concisely that's what you need, it will just get passed on to someone else in the company who can. As one of the people who tends to get assigned the "this other team can't do algorithms" bugs, I can tell you how annoying it is to work with people who don't think that's part of their job.

11
  • 37
    I think this is the right answer. I used to HATE algorithm interviews, for much the same reason that OP seems to. But then I had a job I REALLY wanted that had a very extensive algorithm stage of the interview process, so I hunkered down and studied "leetcode" type problems and you know what? It made me a much better developer. Thinking about the Big-O of a piece of code is just second nature now, and while you'll rarely be solving the same problems in the real world (few developers ever actually need to sort a BST) the tricks you pick up will be applicable to all sorts of real world problems.
    – Bitsplease
    Aug 20 '20 at 15:34
  • 9
    This is actually not a good answer because it does not attempt to answer the actual question; how to avoid interviews looking containing entry-level style questions. Being a Team lead is way more about people than it is about algorithms, many places the Team Lead is flanked by a Tech Lead for this very reason.
    – M_dk
    Aug 21 '20 at 7:12
  • 14
    There is a big difference between knowing about complexity classes with experience about what to use where versus coding quicksort by hand. A good lead engineer has to know that for this specific problem a binary search is the optimal solution. But a good lead engineer doesn't have to actually implement the algorithm itself. Basically all modern languages have the data structures and algorithms for such things, and those have been developed and tested and fine-tuned for a long time by many experts focusing on just that. Ask in crypto.se about homebrew encryption, and see how they react
    – Val
    Aug 21 '20 at 7:37
  • 6
    @FrankHopkins : That's true, but an interview question like "here is a blank piece of paper (or an empty file), now implement quicksort in five minutes without using external references" will fail such candidates, and select for candidates who were good at doing their homework and good at memorizing things perfectly even if they don't fully understand it but not really good at finding good solutions to real life problems.
    – Val
    Aug 21 '20 at 9:51
  • 4
    @BernhardBarker Actually, as a completely non-musical person, I have a good enough idea of what scales are. Moreover, though, just from the context, it's pretty much obvious that it is something pretty basic you do on a piano.
    – Jasper
    Aug 21 '20 at 11:28
61

How do I tell companies that I'm not interested in fiddling with algorithms in order to interview with them?

By responding to an invitation to such tests with a "no thank you". You can try to propose alternate process to go with the "no" but that's a hail mary.

If you are good, eventually you will find a company that agrees with your world view. If not, you may have to compromise and do the algorithm writing tests or face unemployment.

9
  • 25
    This is probably the best answer. No-one can force you to do something against your will, so simply decline. Of course, the consequences of that are obvious, but if someone is that dead-set against spending perhaps 30 minutes to an hour of their time demonstrating the core skills of the job, that's probably the best outcome for all concerned. Aug 20 '20 at 11:11
  • 4
    It's still a waste of time to go to an interview, saying no and be kicked out x% of the time.
    – usr1234567
    Aug 21 '20 at 5:22
  • @usr1234567 how is it? There might be any number of reasons someone declines or doesn't get offered a job. "I won't talk about algorithms. I must have a window seat. If I don't have at least three monitors, I'm out. I expect advancement annually." etc. etc. Are you going to give them a shopping list before you even agree to meet them? Literally the whole point of an interview is to find out whether the company wants to employ you and whether you want to work for them. Finding out you don't (even for a silly reason like the OP's) is what the interview is literally for. Aug 21 '20 at 7:58
  • 1
    The question doesn't specifically mention (in-your-own-time) tests. Would you also propose saying "no thank you" if asked this in a live interview? If not, what would you propose? Aug 21 '20 at 11:23
  • 2
    @BernhardBarker I thought I was pretty clear that hardlining like that can lead to unemployment. Now whether I agree or not, I have my own opinions, but OP didn't ask whether that makes sense or not, just how to achieve what he wants to do. Aug 21 '20 at 11:56
29

Just decline them if presented

Whether companies use this or not would be difficult to consistently determine from the application. At my current organization, no algorithmic questions were asked of me. We are currently asking algorithmic questions of interviewees because the engineer running the interviews has changed.

At other companies I have interviewed for, they have a LeetCode style interview thing to be done unless you are referred. I jumped right to the final round as a referral.

At yet another government organization I interviewed with, they have LeetCode as one of several options you can use as proof of competency. There was no mention of it as part of the hiring process and it seemed unusual for the government to do it at all.

You can't really predict.

If you really want to avoid that stuff, cultivate relationships with the recruiters that inevitably wash up on your LinkedIn. I've found that they can tell you a heck of a lot about how things will go.

27

Get an executive recruiter and focus on management jobs. Tell the recruiter what you're looking for.

Executive search consulting firms are typically used for senior-level executive positions and board directors. Assignments are generally for positions where the best candidate is harder to find and harder to persuade to make a move, and where the potential impact of success or failure is greatest. Contingent recruiters are most often used for mid-level positions or positions where there are a large number of qualified candidates. Three Things Candidates Should Know About Executive Recruiters, Forbes

Don’t assume that a retained executive search consultant will market you to multiple employers to get you the best offer... No candidate that has been presented client company should be referred to a different client until the original client has closed out the candidate. Since contingency recruiters are not retained, they do market candidates to multiple employers at the same time. They do it to maximize the chances of a placement and getting paid. However, they only market so-called MPCs — Most Placeable Candidates — and focus on lower level roles. How to Get to Know a Retained Executive Recruiter

It's not easy to get an Executive Recruiter but it may be something you wish to shoot for eventually.

0
19

Pivot your career to management.

Reading the question I had the impression that you do not have much interest in software engineering (which algorithms are a significant part of) but job title, salary and resume are important to you. Fortunately for you, software industry is full of management jobs that benefit from engineering background but do not involve actual programming such as product manager, line manager, product owner, scrum master etc. Because of the management status, these are often paid better than engineering roles, and you are not competing against people who have actual interest in their profession beyond what is mandatory. Another benefit is that in companies that do not have serious R&D, engineering careers are very limited and management offers more options.

7
  • 16
    Software engineering is mainly dealing with complexity, not algorithms. Aug 20 '20 at 13:39
  • 1
    Now that I think of it, management is just one level up in the game: instead of dealing with complexity, it's about organizing others to deal with complexity. But I'm not sure if this is what the question is about.
    – ojs
    Aug 20 '20 at 14:27
  • 9
    @ojs But I think it's a good answer. As an engineer, I'm fine with managers not being technical. The skills they need to keep everyone heading in the right direction and try to hit milestones, with just the right amount of padding on estimates but not too much, is definitely not my skill set. But if I meet someone who claims to be a "lead engineer" on a software team who says "I don't do algorithms", I'm worried. They're not competent as an engineer, and they're reveling in their ignorance, but they're somehow in a position where they're supposed to be responsible for technical quality. Nope.
    – Graham
    Aug 20 '20 at 20:07
  • 2
    Solid advice, whipping up binary trees and glue code in python, or fiddling c++ disassembly on rainy weekend is pretty much dead end at certain stage of life, management is just natural progression of any tech career. Aug 21 '20 at 0:50
  • 2
    Actually spending time "whipping up binary trees and glue code in python" is a dead end. The idea is that a capable engineer should be able to do these things without effort when needed and accomplish more difficult things when they do have time. In job interviews, the interviewee usually doesn't have the time.
    – ojs
    Aug 21 '20 at 7:32
17

You can check http://they.whiteboarded.me/ which has the list of companies with whiteboarding interviews.

3
  • 4
    That's an interesting resource (and presumably useful for those who are bothered by this kind of thing, though without many more submissions the chances of finding any given company on there are slim). I'm not sure it's quite a 100% fit for the OP's question, though, as they don't mention it's whiteboarding they object to, as such. But related, certainly. Aug 20 '20 at 11:15
  • 1
    Their list of whiteboarding companies includes a whole lot of fine companies. Maybe candidates should just admit that that is how things are and play along with it. Aug 22 '20 at 20:49
  • 1
    @QuoraFeans yes, I like that list, but contrary to the author's intentions, I consider it a positive signal that a company does some whiteboard tests at all. They still can be done wrong, but I for one find them helpful in interviews, because as an interviewee they also tell me something about the interviewers. Sep 1 '20 at 7:27
6

When you find a company you'd like to interview with, you can go to Glassdoor and search for the company. From the company page, you can see user submitted reviews, salaries, and interview questions. Here is an example of Google interview questions.

If there have been a lot of user submitted interview questions for the company, then you can get a good idea of what kind of questions will be asked, including the types of coding problems that need to be solved. Obviously if it's a smaller company with few user submissions, then this may not help you.

4

I mostly agree with Helena's answer and would assume most decent companies expect some level of algorithm experience from people that want to fill a lead software engineering role. However, there can be a few exceptions where the project mainly requires to deal with the nitty gritty details of component and dependency management, the role leaning into the managerial direction, the business being directed towards very light weight applications without any algorithmic complexity or the company not being 'decent' in the sense that they got their terminology as wrong as your current one^^. From your description at least, you seem more like a team lead that also develops with a focus on designing APIs and algorithmically straight forward software (nothing bad about that, picking the right tech is also an interesting part of the job, just not all of what I would expect from a lead software engineer). So to me you seem to be a team managing developer. Perhaps you are also particularly good about picking frameworks or designing APIs, then you might focus on that.

A few things I would look out for in job descriptions to land a fitting job and increase the chance to not be confronted with (too much) algorithmic questions would be these:

  • a focus on libraries, frameworks and technology buzzwords
  • a mention of team leading (personal management) responsibilities
  • a focus on API design
  • a focus on lightweight web applications
  • a focus on technology/infrastructure architecture
  • a startup, self-learner culture*

So in principle for jobs that lean either 'upwards' towards design of the outer shell of applications and how they work together without looking at the algorithmic complexity or for jobs that lean 'side-wards' e.g. into the business domain or into team or infrastructure management. Sometimes there can be roles mostly for designing APIs or "front-runners" that discuss with people who know the business domain how a software should work on the business and API level, the details then will be designed by software engineers.

* Why a startup/self-learner culture? Because - clichè, yes, but I've often enough seen it - those often don't properly know what they do (technically), they often hire who they can get and who can implement stuff fast without much concern for algorithmic performance. Sometimes they fail after a while, sometimes they succeed and then may need to clean up the mess once they exponentially grow and their small scale algorithmically naive solutions don't scale any more, but they can still provide a good job for years. Sometimes that isn't an issue at all because their target market doesn't need algorithmic performance just someone who writes some program with a nice UI for that niche area no one took care of yet.

3

Only apply to senior, principal or lead roles and in your resume state that is what you are looking for and as often is truthful, express your experience in the resume and cover letter and e-mail correspondences as such.

At least in my neck of the woods, Junior to "No Prefix" get these questions. Seniors and above, not.

2

I've almost always gone via a recruiter and a recruiter will know what the interviews are like. First, they'll know from experience, second they'll ask the hiring manager, and third they'll debrief any other interviewees they've sent in. (I've had recruiters literally try to give me the test questions that they heard from candidates they've sent in previously.)

So just tell the recruiter not to bother putting you forward for such interviews, if you really don't want to do them.

2

How do I tell companies that I'm not interested in fiddling with algorithms in order to interview with them?

An alternative is to have your own open source software portfolio on platforms such as github or gitlab (or on your rented VPS). Contribute to existing open source projects (like GCC or FLTK or RefPerSys or thousands of others). Once you are as famous as Linus Torvalds or Guido Von Rossum or Xavier Leroy, you'll be well paid, and you will have job opportunities. Notice that most developers of GCC or of the Linux kernel are paid for their work (see LWN about this, and perhaps write there...). Once you have designed and implemented a programming language which have a few users (this is really hard as Simon Peyton-Jones explain) you could have interesting job opportunities.

Another alternative is have at least a public blog where you explain some architectural views of software you have developed (or technically leaded). Be sure to get prior permission for that.

A third possibility is to have a high score on platforms such as StackOverflow. Be above the top 1% there.

A fourth alternative is to have written and published some technical book on your topic of excellence (or at least public draft reports, such as this one).

A fifth alternative is to make a PhD and/or publish academic papers -with peer review- in e.g. ACM conferences. Related is to get paid (part time) to give some teaching about software development and programming and manage and mentor interns.

Another alternative is to give voluntarily (and unpaid) talks about programming and software development (like this one I gave in French). It might even be videos on youtube about programming and software development (once they have been viewed thousands of times, e.g. this one).

Be aware of Peter's principle. Read The Mythical Man-Month or better yet, write a better book.

0

An alternative could be to have a very polished CV/resumè. One that shows how good you are.

If possible, also give them enough code for them to have an idea of how you write code, fix bugs, work on APIs or with databases (E.g.: a personal Github repository, unrelated to the current company).

And if presented with a LeetCode-style question, just face it as part of correcting a bug you found and needs to be fixed. This may show them that you do know the basics.

Please note: using Google to freshen on some things you forgot isn't bad! (Unless your code is 100% StackOverflow copy-paste-glue.)
An example: I had an interview where I forgot how to connect to a database in PHP (my heart was racing and I slept poorly that day).
I just freshened up on a few examples and wrote my own thing, without copy-paste.
The goal was to write a database + PHP script to store and fetch the information needed for a restaurant, based on a written descriptive text.


But, if you are really uninterested in solving those "fake" problems, then you can try to negotiate an alternative method for them to evaluate your skills, and see how it goes.

Just keep in mind that this may give a less-than-optimal view of your coding skills to the person interviewing you (I certainly would have my doubts about your coding skills).

You must log in to answer this question.

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