Should Senior Developers Refuse Interview Coding Challenges?

Whether on a whiteboard, a timed challenge at the office, or a take-home project, many senior-level developers and engineers are asking themselves if coding challenges are still something they should have to participate in.

It’s an understandable consideration if you’re an experienced tech professional. Should you, a ten-year veteran of fill-in-the-blank-language, be asked to show your work? More to the point, should a company still consider you if a coding test is rebuffed?

There’s no clear path forward here. If you refuse any part of the interview process, expect the company to stop the process altogether. Put yourself in their shoes: Why would they want to hire someone who refuses an industry-standard practice for the interview process?

If you refuse to do some coding as part of the interview process, this is the likely scenario. To a potential employer, your refusal to show your skillset is not a ‘gotcha’ moment; it shows them you’re willing to be difficult about something fairly standard. In addition to skilled tech professionals, companies are hiring for culture. By refusing to do any coding at all, you’re drawing lines in the sand before you’ve signed an offer of employment.

Some “industry standard” indignities shouldn’t exist. If you’re asked to stand at the whiteboard and invert a binary tree or some such nonsense, most hiring managers would likely accept your counter-offer of a coding challenge or take-home work. But rather than say “I’m not doing that,” position it like this:

I’m not sure a whiteboard is the best showcase for proving my knowledge. I understand why we have them, but I’d be far more comfortable with a mini project where I can use every developer’s two best friends: documentation and the web.

(Many interviewers or hiring managers haven’t thought beyond whiteboards. It’s entirely possible they hate them as much as tech pros do, so offering up an alternative may give them an ‘out’ they didn’t know existed.)

Beyond the whiteboard, there are two core options for hiring firms: take-home projects, and on-site testing. The on-site coding challenges are typically what you’d expect: they sit you down at a machine, explain what they’re looking for, and give you a timeframe to complete the project. Sometimes the company is just looking to see that you know some basics. Other times, the projects are impossible. They just want to see how much you can accomplish.

The on-site challenge is, to us, a fair compromise. It’s not the indignity of a whiteboard, but helps your potential employer see that you grasp core competencies. Take-home challenges are a bit more comfortable, but have their own considerations.

First, consider if the company is asking you to do work on their platform as a ‘test.’ Are they asking you to write code they can reuse or slip into their stack? Did they ask you to squash a bug or add a feature for an existing app or service? That’s not a challenge – that’s work.

Second, take-home coding challenges can be lengthy. Some companies give you a wink-and-a-nod that you should only spend a few hours on your project, knowing you’ll invest as much time as is necessary. One Redditor claims to have successfully billed companies for take-home projects, though we’ve not heard of anyone owning up to this beyond the anonymity of Reddit. But, if a project yielded results the company could use in production, or you’ve been asked to spend a day or better on said challenge, you wouldn’t be out of line to inquire about compensation of some sort.

Refusing any coding as part of the interview process will most likely end the process. This isn’t great unless you’re looking for an easy way out of interviewing for a company you’re unsure of. Asking for projects where you can sit at a computer and actually code are better options, though the company may not be set up for that. A take-home project is far more comfortable, though the scope can be wider, and we’re not a fan of tech professionals spending hours on something that will get the once-over from a busy team lead.

You know your skillset. Potential employers simply want to know you’re the right person for the job. Your best move is to find common ground so they see what you’re capable of, and you don’t feel taken advantage of.

24 Responses to “Should Senior Developers Refuse Interview Coding Challenges?”

  1. It’s become a strange, useless process. The interviewer has no training on how to interview so they go to Google and get a set of coding questions. The interviewee knows this so they study the same questions. What has this proven? That they can use the internet. When I interviewed candidates I would start with what they actually have done. Usually, a coding or design question will fall out of that. Now it’s some kid out of college asking a 25-year coding veteran to reverse a string in C or python or java or whatever the language du jour is. And those stupid out-of-the-box questions are useless too. A vanishingly small number of people have the understanding to interpret the answer. A mango, goat and cheese doodle are on one side of a river. A frog with a scorpion on it’s back is your only way across. How many bananas will balance on your average weather vane?
    Companies need to free up a few dollars and pay to train their people to interview and to understand how to interpret the answers. Just assuming someone knows that is a waste of time. This is how we get really poor hiring practices of only hiring people like yourself. A mango eating goat herder is going to lean toward hiring similar even if the job is banana rangling.

  2. Fred Bed

    I have never agreed to a whiteboard test. If my prior work, resume, references, and/or reputation isn’t sufficient for a company to determine what I can do, then that’s not a place I want to work.

    I (sort of) get whiteboard tests for graduate hires. But experienced devs? No way. Not now, not ever. F that. Full stop.

  3. Mia Kennedy

    Asking a senior engineer with 10 years of experience to complete a coding challenge is stupid and a waste of time. No other industries do these things. Teachers and professors don’t take home quizzes and such neither do accounts etc. Its an old barbaric practice that should be tossed.

  4. It’s fine to challenge a question on level or realism. I’ve done that with FAANG interviews and still got an offer so long as I identified the class of problem and could speak towards the solution.

    The other side of that is, i’ve been in plenty of interviews where they were looking for justification to hire outsourced grunts and wanted a local stalking horse they could poorly rate for their documentation. That type of mono-culture panel beat down has to stop.

    • Chris

      Agreed. Companies are fighting for experienced help from people with proven track records. I’ve had multiple 30 min phone interviews with Fortune 100/ 500 companies where I received a great offer while on the initial call. I laugh at these wanna be contenders who think I am going to waste my time with a code review, take home projects or taking off of work multiple times to go in and interview.

  5. Let’s think this way. Seniors have instinct how to solve problems and perform work. If they forgot the commands or formula, they know how to get answers. They dont memorize things. If you memorize 20 years of experience, you will be crazy or dumb. Juniors who just out of college, they are fresh for memory. It is unfair to put two together for the process. All is matter to hire who has motivation, passion to do jobs well. I see these juniors after get into the jobs, only work 3 hours for projects, the rest, having fun with free food. I also hear many projects are not successful. They might know how to code, but seniors foresee the designs and structures. Seniors will accomplish the projects’ goals. Will you say you are bigger than your parents?

    • I have been at a company for over 10 years and am the one person in our department that does Front End Development. Mostly Html/CSS, JavaScript, PHP, and JQuery. Every project I do is different though and I am always learning. I’ve never focused on one language. I’ve built angular apps on my own for keeping up to date on new tech but never used it at work. The rapid rate at which languages evolve is crazy. Lately I’ve been looking at relocating to another state. I’ve seen some positions asking for senior react and angular devs with 5-10 years experience. It’s funny because they are fairly new languages. I believe Google started on its version of Angualr 2 in 2015-2016. Out of the remote Jobs I’ve applied for I’ve received 3 phone interviews and each one has wanted me to take a test. First one sends me a test that should take 1:30-2 hours. Right after starting it I realize it is for backend development. So I write back and they say they made a mistake but didn’t want to send the other Front End test because it is about 3 hours long. I’m like wtf. The other companies also sent test and they were like 1:30-2:30 long. I gave up on working remotely. I’m looking for an onsite position now but that has also been a challenge since I’ve been turned down since I don’t live in the state I applied a couple times. As for programming, I think you either understand logic and can figure out a language after looking it over or you just are not a coder. I’ve had some good interviews for onsite positions but they have been taking forever to get back. For me, my memory sucks after sustaining a TBI and I can’t memorize every language but I can understand languages and figure things out. But who actually memorizes everything? By the time you learn something a new language has already taken its place.

  6. I took a code test for a job back in 2010. It was really stupid. I succeeded and was offered the job. Then when I saw the quality of code in their repositories I didn’t know whether to laugh or cry. Absolute garbage code everywhere. And they had the audacity to give a senior engineer a code writing test?

    I refuse to take tests or write code on white boards during interviews. As a senior engineer whose code is currently used by a branch of the US military as well as by a major US research university, any company who is too stupid to recognize this along with all of my other accomplishments is not worth my time. That indicates a lack of common sense and I have no interest in working for them. If it’s a case of believing that everything on my resume is a lie and must be proven, then call my former managers on my list of references to corroborate. Ask them anything. That will take a lot less time than wasting my time and theirs with silly tests and white board antics.

    In my career, I have interviewed a lot of folks for various positions. Not once have I asked an experienced software developer to write code on a white board or take a test. If you verify their previous employment and technologies BEFORE THE INTERVIEW, you save a lot of time during the interview for meaningful questions, such as, “Do you think the move to agile development has helped or hindered software development, and why?”

  7. The issue is the coding challenges are based on situations that have nothing to do with real world problems. Also the challenges typically include some problem that no one in their right mind would solve anymore because they would use a library or open source resource to solve rather than deal with low level stuff. However if what you want is a newbie from college who has just been through these things in algorithm class go for it. He will be cheaper. You won’t make many deadlines but go ahead. What I wish we could do is show a portfolio of code we wrote and have to talk about it or code review it. Kind of like you would for a different kind of artist like a graphic designer.

  8. Bradley Beach

    I like it when I get asked to do stupid things during an interview. Whiteboard an algorithm, how many ping pong balls can fit in an 747, you know the drill. It let’s me know really fast that I have no interest working at that company. I politely thank them for their consideration, inform them of the uselessness of their question, and walk out.

  9. Wes Hatley

    I am a senior developer and being tasked with destructuring someone’s “new” way of writing FizzBuzz or Bubblesort guarantees that LinkedIn conversation ends up in my trash. I always advise I’m happy to share code I’ve written with other senior software engineers, showcase things I’ve created, have discussions about theory, structuring, methodology, decision making, etc. If you insult me with busy work I’ll entertain any of the other 10+ messages a day I get in my LinkedIn inbox from recruiters that aren’t looking to waste my time. This article seems to overlook that the demand these days is so insanely high for senior devs that they don’t have to debase themselves like animals in a circus.

  10. The guy that wrote this article is just a writer. He doesnt lnow wtf hes talking about and preaches a gospel of conformity. What kind of person does it take to advise professionals on their profession when you’re not in it yourself? Pretty sure it takes a douchebag.

  11. Shadowncs

    Never really understood what is wrong with coding challenges.
    Is it not something senior sw devs enjoy? I sure do after 20 years, every time I get one whether in an interview or not.
    Is it not an opportunity to springboard the discussion to the real points like scalability, efficiency, portability, maintainability?
    And you know what – plenty of top notch developers think like me. I hired quite a few of them.
    So I respectfully disagree:
    – if it is just busy work, get to the business of making it interesting! Throw in some curveballs at yourself to make it reallly challenging so you can amaze.
    – never write code on a whiteboard because of course the “coding challenge” is in fact a design challenge. Guaranteed, always.
    – If you get stuck say so and work it out after the interview and follow up.

    It really is one of the fun parts of the interview so treat it like that. Unless of course you are intimidated by writing code in which case I’d reassess your seniority level.

    • Algorithm development is not a race, to be done on the spot and in a microscopic amount of time. Most engineers take time to think things through, consult reference materials, and try more than one algorithm before settling on the final version. White board exercises prove nothing. I’ve written code that I thought was a good solution, only to rework it the next day after getting an epiphany while laying in bed that night. Tests and white board coding cannot separate good engineers from bad ones. Thoughtful, cerebral questions by the interviewers do a much better job of that.

  12. Vivek

    Do you ask a handyman to do a sample project before you hire him? NO!!! You decide based on your conversation with him and look for his online reviews. Do you do the same thing with other professionals like Doctors, Lawyers, etc?

  13. David

    I’ve passed nearly every test but some interviewers want to be difficult. For example one guy gave a 90min test that I finished in around 30. Then he failed me on an algorithm that I used.
    There’s others who start asking text book definitions so these type of people I just tell them on their face to ask relevant questions because their goal is usually to kill some time or show who’s better

  14. Ritchey Mulhollem

    NO! Absolutely NOT for senior level developers! If you don’t immediately like what you see on my resume, how is a code challenge going to change your mind on anything?

    Let’s put it this way. Has anyone ever been hired based on a code challenge? Anyone? Because I haven’t.

  15. Joe Siczpak

    Some years ago, the two tech bullies on an interview asked me to go to the board and write code for a recursive descent parser. I didn’t want to, but tried anyway. The two tech bullies kept interrupting, so I stopped and erased the mess I’d begun to write. Instead, I drew a binary tree and explained the algorithm. Later, one of the tech weenies whined, “He didn’t want to go to the whiteboard and write code.” No offer.

    For a recent interview I did a hackerrank two-hour test about tic-tac-toe. Due to the countdown timer, I found it difficult to concentrate. Fortunately, I had practiced on several other hackerrank problems in advance, so was very familiar with the UI and its quirks. The hiring company rejected me out of hand with no discussion. Too bad for them.

    A few weeks later, I had an on-site interview where I met three different developers, each armed with several programming and log questions. I found that much more tolerable. What I did was scratch out my solution on a sheet of paper, while making small talk. Then I merely told the interview that the code would not compile, but they are looking to see how I think. I guess I did about four coding tests and discussed several logic problems. I left the interview not expecting any further discussion, but got an offer the next week.

    I think it’s more important to be willing to discuss the toy problems and attempt to write some code, rather than discount it out of hand.

  16. Actually, a company I interviewed with asked me to do a presentation about some code that I had already written. Talk about the design, show where it may be lacking, what was done to ameliorate any problems, etc. This was all pre-arranged so I had time to prepare everything.

    At first, I thought it was a bit crazy. But, y’know, it worked out pretty well. I was able to talk about something I know a lot about and was able to work with co-workers so that they understood what I talking about. We could discuss the design trade-offs and why I had made those decisions, etc. Sort of like a formal code review. They could get some ideas of my personality, how/if I would fit in with the group, etc.

    I thought that went much better than “solve this problem.”

  17. Harsh Reality

    If a senior developer is willing to waste their time on white board hoop-jumping, “timed office challenges” or (worse… far worse than ANY of those) a take home test, they are clearly desperate and will tolerate any number of indignities and pointless lunacy.

    They represent a few good ways to identify future employees that will allow the company to use them as a door mat but are entirely useless otherwise.