Cover image for I failed an interview because of an algorithm

I failed an interview because of an algorithm

raulfdm profile image Raul Melo Updated on ・14 min read
Photo by Siora Photography on Unsplash

Hello, devs.

For the last couple of weeks, I've been participating in a hiring process for a big company.

It was a very nice experience and it gave me a lot of insights about hiring, code challenges, and how (possibly) to become more prepared for interviews.

As you already saw in the title, I didn't pass, but I went through all the stages of it. So it might be interesting for you if you're trying to get your first job, or even if you're thinking of switching jobs but don't do interviews for a couple of years already.

I'll explain all stages, with some details and thoughts, but my main focus here is to tell where and why I failed in the last part of it.

Hope you like it and I hope my experience can help you somehow!

Table of content

Stage 1: Getting an interview

A very common practice in companies, in general, is to motivate people (with money) to recommend professionals to fill opening jobs (that's a good reason why you should build good connections as much as you can with people in and out of the internet).

A friend of mine recommended me to work in his company. Good salary, very well structured and it seemed a very good place to work in, why not try it out?

I just needed to do some adjustments to my online CV and I was ready.

Stage 2: Human Resources (aka HR)

The HR from the company just called me to know a bit about me.

They asked about all my experience, things I've done in my life, whether I had some specific knowledge (like React, testing, Redux, etc) and also questioned about the company I'm working on.

To be honest this call just seemed to be a filter for people who lied on their CV, because everything was very basic and trivial.

I was pretty confident in all the answers I gave to her, and at the end of the call she just gave me a positive feedback and then she'd schedule the next phase with the tech lead and team manager.

Stage 3: The managers

The following week, I had a 1-hour meeting (now with webcam) with the "managers".

Their job was getting to know about my soft skills. A lot of questions like:

  • What is the proudest moment of my career
  • What was the worst technical decision I have ever made
  • How I deal with conflicts
  • How I deal with top-down decision
  • How I handle hard discussions

And in between these questions, they constantly asked me to give examples of it, some situations I have been passed that prove I think or solve a problem in the way I was doing.

It was very nice because I could remember some good and bad moments in my career which made me grow up a lot as a professional and also as a person.

When I turned the call off, I was still very confident about the final result.

After a couple of days, the HR called me saying the managers liked me and the way I answered their questions (maybe someday I can share in details some situations I've passed and my current way to deal with people and job).

The only feedback she gave to me was: "I needed to be less of a follower".

And... of course, they thought I was more of a follower than a leader or something because, to be honest, I'm almost 30 and I kinda lost the energy to keep fighting pointless discussions about technical tastes and personal ways to code.

I have my opinions and I always can argue why I have them, but to be honest, when the discussion reaches the moment where it's an ego thingy or personal flavor, I just give up and let people do what they want.

I do not care about:

  • what's the best JS framework;
  • what's the best state management library;
  • if we should use reduce or map + filter
  • if we should use it or test in jest assertions

I do care about:

  • what solution fits best for the problem;
  • good naming;
  • tested code;
  • a simple solution when it's possible;
  • ship the product;
  • my salary at the end of the month;

In the past, I used to have endless debates about what's best, what's the worst. Nowadays I still have these discussions but if I notice that we're not going anywhere, I just agree and live my life.

But of course, don't be a fool. If I'm convinced that some bad decisions are being made and I can prove that, I'll go until where's needed to defend that.

From a company’s perspective, what's the most valuable personality? We can have a long discussion about this.

Stage 4: the HR (again)

The next phase was again a HR call and she asked me some questions the managers made to me the week before.

She wanted to see for herself my soft skills.

Well, I didn't lie in any of the questions I gave the same answers.

I also tried to explain why the managers thought I was more follower like and it seemed she had got it.

She gave another positive feedback and then told me the next step would be with 2 devs to test my hard skills and a QA manager would be present just to watch the process.

Stage 5 (latest): The devs

This one was the trickiest stage and I want to give you full details about how it went. I want to recommend to you guys some articles that might answer those questions if you don't know.

I received an email with some topics they could ask like JS, CSS, Testing, State management, React, and Http but still wasn't clear how they would approach those concepts.

It was scheduled to be 1h30m short but it started 10 min late.

When I joint the chatroom, as always we did some round presentation and they explained to me how it would work:

  1. 20~ min to get know about what I currently do;
  2. 30 min to answer and explain technical concepts;
  3. 30 min to do a code challenge.

About me

Here again, I had to explain what I do in my current job, but more technically.

Well, it's only me and another guy responsible for the entire web ecosystem so I kinda know what the product is and how things are structured.

I had explained to them in detail about what's the platform, my responsibilities, what’s my daily tasks to give to them an idea and how we're handling them, etc.

Sometimes they asked me to dive deeper in some topics but it was easy at the end.

Technical questions

Here starts to become a bit tricky because they started a certain quiz. I'll try to not dive deep into explanations and solutions but instead, just give my impression, a short idea about it and share an article explaining in detail those questions and concepts.

JavaScript questions

Can you explain the difference between var, let, and const?

It can be indeed tricky, especially if you have started learning JS recently. I believe people just say: always prefer const but if you need to reassign then use let.

Luckily I've passed the transition from var to let and const and remember clearly it's about scope.

To explain that I used the object mutation even when we use const, so they got a second question from here:

How can you freeze an object?

I know this concept because I caused some bugs while learning ES6. After a few hours trying to know why my object was being mutated, I've found documentation about the native API Object.freeze.

It's very straight forward. When we freeze an object any operation which will mutate an object does not change the object itself. Be aware that this freeze only happens at a shallow level (1 object-level deep) and does not freeze objects and arrays nested.

Can you explain what DOM is?

I think that was the easiest one, despite the fact I forgot what the acronym means (Documment Object Model).

Can you explain how events propagate in the DOM?

I knew this question because before I learned React I've created my own JS framework (it was a nice experiment) where I learned a lot about capturing event in different levels and also how bubbling works.

What's the advantage of using a single event to capture events?

It was still related to this question and to be honest, I wasn't sure.

I remember when I had implemented that in Vanilla JS where I had a form and instead attached onChange to all inputs, I just did in the form level and had some sort of switch to decide what information to update or what to do but... I've forgotten why this was good. My assumption was about performance.

The dev told me it was exactly about this and gave me a very good example. Imagine a table with thousands of records. If we attach a single event to each row we would have for sure performance issues because the DOM will have thousands of events to dispatch.

I really liked this example.

Do you know what the Request animation frame API is and why we would use that?

I think I've used Request Animation Frame (RAF) API once or twice in 5 years so I was not sure why such API exists, then I tried a guess: “tell the browser that we're gonna do some animations and get some performance.”

They told me it was correct.

CSS questions

Do you know about the different displays?

Didn't get much this question. I wasn't sure if I needed to explain each display or just say: "yes, I know".

But my answer was saying I have a few displays we have like inline, inline-block, block, grid, flex, etc.

To my surprise, it's what they wanted to hear.

What's the difference between display inline and display inline-block?

This I didn't know by heart.

I knew the difference between inline and block because it's a very common thing to do in CSS but I couldn't remember the difference between inline and inline-block.

The dev explained to me that when we have inline-block we can define margin and padding to the element while in display inline we can't.

How can I center something vertically?

Also another tricky question and maybe because we have several ways to do that.

The way I know by heart is using display: flex combined with justify-content: center and align-items: center.

My answer was good enough.

HTTP questions

Can you tell us what methods are available in HTTP?

Not that difficult since I sometimes play with backend in Node.

  • GET
  • POST
  • PUT

Then they asked me if I knew the difference between PUT and PATCH and that's tricky.

I remembered one replaced the entire data with the new content and the other just updated the information sent, but I didn't know which one did what.

They told me it was right but who does partial updates is PATCH and a full replacement is PUT.

On top of this question they asked if I knew about other methods, like OPTIONS and to be honest, I didn't.

Often I see OPTIONS requests in my network tab but I have never asked myself what hell was that.

How the HTTP status codes are divided?

Basic HTTP things.

I just remember that by heart because since I started building apps that consume APIs, I was curious to know what's the thing about these codes and I found this https status dogs which it's an amazing way to understand each code. 😁

Technical Challenge

I had the feeling I ruled the quiz questions and I was much ready for the technical challenge.

"30 min might be enough to solve something." I thought

Then they sent to me a link to a Code Sandbox with a single JS file:

// index.js
We have lots of deployment dashboards where we have drop-down UI to select an application version to deploy. We want to ensure that software version numbers delivered to our UI from the back-end API are always ordered with the newest (highest) available version at the top.

const input = [0.1.0, 3.2.1, 2.2.3, 0.1.1];
sortVersions(input) should return [3.2.1, 2.2.3, 0.1.1, 0.1.0];

const sortVersions = (unsortedVersions) => {
  // code

export default sortVersions;

And a test file with some assertions to ensure it was correct

// index.test.js
import sortVersions from './index';

it('should sort correctly numbered versions', () => {
  const versions = ['0.2.0', '3.1.2', '0.1.6', '5.0.0'];
  const output = ['5.0.0', '3.1.2', '0.2.0', '0.1.6'];

// Other assertions

Rules to solve that challenge:

  • I could use google to search about JS APIs
  • I couldn't use google to search for the problem specifically.

The first assertion was very easy. My solution was simply:

const sortVersions = (unsortedVersions) => {
  // code
  return unsortedVersions.sort().reverse();

And it passed! :)

Then I had to solve the second assertion:

// index.js

it('should sort correctly numbered versions with different lengths', () => {
  const versions = [

  const output = [


And here I just got stuck.

My previous solution didn't cover cases like this. It just returned:


And the reason is kinda obvious for simple string sorting. By default, it goes alphabetically where 3.3 comes after than any 3.1. But in semantic versioning, we know that 3.10 is greater than 3.3.

After playing around with sort methods, I had an idea about making all versions the same size based on the largest version.

To be honest, at that moment I was already nervous because I couldn't think in a way to solve that "simple" problem and consequently I started to get anxious.

I had some tips from them about how I could solve that but it was a bit hard to understand. Not because they didn't explain exactly but because I was trying to figure out many things at the same time.

While I was doing some code to make all versions in the same length, time was over.

The dev asked me if I had more time how would I solve that and I explained that my ideas were making all versions in the same length so I could compare per blocks.

I thank them for their time and we turned off the call.

If you're curious about how to solve this problem I recommend you take a look into this answer in StackOverflow. I just tested it and it solves all specs.

After the test

To be honest with you after I turned the call I felt myself a failure.

In the past 5 years, I've already solved so much harder problems than that and at the end, I was beaten by a sorting problem, what was wrong with me?

But I tried to comfort myself: "Ok... I went well in all previous steps, even when they asked me technical questions.. this shouldn't count too much".

The last HR Call

After a week waiting to see if I was approved I would be accepted or not, the HR person called me saying:

"Unfortunately we won't proceed with you"

I only could feel very frustrated.

Then I asked why and if I could have feedback about what I could improve and she told me:

"The devs really like your communication, your energy while doing the interview. They liked that you answered most of the technical questions correctly but they thought you didn't go well solving the last problem.

hmm... ok, I said.

I could argue in many aways against this decision but let's be honest, the decision was made. It wouldn't change anything.

I turned off the call, stopped for 5 minutes to digest the feeling of failure, and tried to think about all this process.

Thoughts about hiring X our skills

I don't know if you already have had the chance to be the interviewer in your life. I had and I can say for sure: it isn't an easy task. And that's because the hiring process is very hard in general.

We need, somehow, to define steps and things to evaluate a candidate and despite our goal of being transparent and analytical, it isn't by far a perfect method.

People think, learn, solve problems, communicate differently from each other, and in a hiring process, we try to create some guides and filters that we expect about people.

It means that if someone just does not fit in what you expect, it might be a good signal that this person isn't ideal for the job. But... does it mean that this person would be a bad professional?

I don't think so.

I remember when I finally could get my first job as a developer, I made a similar code challenge and I just ruled that.

Do you want to know the difference between me 3 years ago and me now? At that moment I was constantly practicing solving algorithms in the FreecodeCamp platform.

After I got the job I proved myself a valuable employee and I can say for sure that the hard thinking I used to pass in the interview was not by far what made me ship product, because there were rarely moments I could not use Google to look how people solve this problem to create another solution on top of it.

I had some challenging problems to solve and I solved them all in a short or long time, sometimes with others' help, sometimes by myself.

To get my current job I had to create a React APP which consumes a public API, add tests (E2E), infinite scroll, animation between pages and host somewhere, explain my solution, my struggles, and do a pair programming to solve some problems I had.

And it's basically what I do most of the days to earn money.

Does not being able to solve an algorithm mean that I'm not a good developer?

I don't think so. In my mind, it just says I failed into solving a problem in certain conditions. But again, this is their metric of how to evaluate a professional.

My point here isn't to complain about why I was not hired but to make it clear for you that: failing in an interview does not mean you're a failure as a professional.


Overall, doing all this process taught me a lot.

For the next interviews, I'll be prepared to easily answer questions about soft skills. I'll never forget the difference between inline and inline-block or what is the HTTP OPTIONS method and the difference between PUT and PATCH.

But my biggest learning was: try to be prepared for everything.

You might be requested to implement some APP using React, Vue, Angular, whatever, or even solving some tricky problems in JS.

For that, I already started spending few hours per day trying to solve problems in platforms like Codewars, FreeCodeCamp Learn and Codility.

While I'm still implementing new things on my personal website and get sharper in how to create a robust front-end application.


Hope my experience could give you some insight into what you could do differently to get your first job or at least to be prepared to rule a hiring process!


markdown guide

That's why tones of devs are asking across the net to change the interview process into something more reliable and realistic, which also will be more fair with experience:

Create a little project with a back-end and a disengaged front-end, then if you are hiring a back-end you'll give them the API contract and let them code for a morning. If you are hiring a front-end give them the API contract and let them code for a morning. On any case, give the instructions and be clear with the requirements. Let them google what they want, even let them put music in their ears.

At the end, what IT dpt. and the company need is someone who can produce a valuable output from its job on a given time, not someone who knows algorithms that will never (or almost never) been used on a real use case.

For adding context I'm coding since 10 years ago (near 11), I don't remember how to code the Fibonacci algorithm because TBH, I know what it is because some teacher told us to solve it without googling 11 or 12 years ago but who the f*** uses Fibonacci algorithm on their everyday tasks?


If you want me to code this useless algorithm (for my current job) let me google it and you'll get the answer on less than 5 minutes, same with any algorithm or coding problems which are not near to the reality.

You can say that's not good for any reason but you'll need to learn things to get your job done better, i never saw a person who knows everything related to their job (languages, framework, architecture, analysis, life cycle, business, market, growth options, competence and so).
For me it's much better getting someone who can solve things by its own while learning than someone who wasted him/her time on memorizing algorithms that are used into specific fields. Moreover most of this people who memorizes algorithms don't dig deeper;

I'd a teammate who told me "look, I did Fibonacci succession on 7 languages" I said "nice, do you plan to develop your own agile planning app?" He looked at me disoriented and said "...no, why?" I asked where he plan to use this already coded increasing number sequences and the reason was "nowhere, it's only for fun".

Yes, it could be nice but the fact is he didn't see the relation between agile development and Fibonacci, even he memorized and coded it 7 times (at least).

Own conclusion: Memorizing concepts is okay, memorizing algorithms out of context is not, and that's what most companies are asking for on their HR processes and this needs to change for their sake.
If you understand the context and you know how to code with at least one language, you will easily perform tasks on almost any language with almost every architecture on that given context.


Couldn't agree more.

In these 5 years I had to solve some problems I couldn't find on the internet just because it was a company problem. I had to do a "glue" between Rails and Create React app which took me quite some time and I used a lot of scripting and algorithms but again, I composed the solution on top of a lot of existing things.

It's nice being able to understand the solution and why it's good for that but I think for 95% of devs we indeed does not need to know implement those things by heart without even search.

Good comment :)


Thanks, a bit large on word count but I felt the need of adding all those info bunched together haha

As this comment received visibility I must specify that It's good to know the existence of different algorithms and the reason for them to exist, because you will be able to use them to solve real issues. My advice was for memorizing them without context or further acknowledgement about this algorithms.

Most of them are meant to solve specific needs on a given field. I mean if i like to work as developer on a NASA project I must learn and know some basics to benefit the effectiveness of sharing information between departments but at the end, the professionals of a given field will give me the calculus to implement and I'll be a bridge between this scientific and the computer/machines, I don't really need to know or understand all the implicit science about something to implement a given algorithm on a method.

Cheers! :)


Being able to understand the problem is what matters, he failed at that when he tried to sort by the length, the problem was sorting by the version.
You don't need to know algorithms or fibonnaci, but they teach fibonnaci so you learn how to use recursion to solve problems. And they teach you to make BubbleSort so you learn how to use any sorting algorithm. They need a comparator, you can easily get it if you implement the simplest algorithm.
You will never need to write a bubblesort algorithm in the real job, but the less in solving problem is an useful one.
(unless you work in the browser team, then you need to know algorithms like quicksort from the hearth)

Sorry but i knew (and being trained) about recursion time before being asked for Fibonacci at college, applying this algorithm is only a way to implement it on a specific way.

Moreover the tech tests when applying for jobs are the same for juniors than for seniors on most companies which is a bit weird, don't you think so?

By the way if you want to know if someone can apply recursion or whatever you could ask for a real use case instead on pretending people to memorize algorithms, remember than on most interviews you cannot google anything (which also it's a bad practice and poor realistic, if i hire someone I like to see people are able to search properly and how each person handles the information they found, which is more important than being memorised things)

We can argue all about Fibonacci being a bad way to teach recursion. The thing is that it is not useless because you don't use it in the real work.
Its just a teaching tool, its not even a good one, not everything should have a purpose of directly being used at work.

I do agree that those interview tests are kind of useless. I would fail a person based on how they try to solve a problem, and how they grasps it, not solely on remembering trivia.

Memorizing algorithms is useless, you do have to implement then at least one time just to grasp how to use it, unless you're super-intelligent and come up with bubble sort on you own, as I did.
I implemented the B-tree record exclusion in a exam in the University without ever implementing any of the B-tree insertion before, just from reading the textbook, it was not even memory, I just looked at the data structure and I saw what I needed to do to it, but then I had 5 years of experience as developer.
I could invert binary trees by head, this would be easy.
I wouldn't expect any candidate to do that. Also, I'm a Research Engineer, not a web developer. I still do need to interview them for my projects that have frontend, I don't expect them to know CS thingies.

But I do expect someone with that many years doing JS to know that sort takes a comparator. Massaging data is basically what a programmer does, sorting included, you don't need to come up with sorting algorithms, but you do need to know how to use them.

Also, I do agree that not being able to google the solution is a bad thing.
I would let him search for the solution, as long as he said to me that the problem was "sorting by the version". Instead of just trying to come-up with random algorithm.

Just to clarify, I don't like doing those tests on people. I like to leave them a problem in open scope and then see the result of what they can do.

So we agree on most things, there's no much point on repeating the same things all over again. Of course we're talking about web development (if I didn't catch bad the OP). We could even being talking about whatever field of development process and target (which could be insane).

Glad to see you are a theoretical learner, that's nice, each one have our own way to learn things, mine is mainly pragmatic (i usually put my hands on and let the theory for later), others are reflective and so... (I just published a post about that this morning, you can find it on my profile).

All this is about the precision of job interviews on our matters, IT is a science which it's job doors are handled by human resources people, who obviously knows nothing about. Then I even found companies on which tech interviews are handled by IT department and are even worse than those handled by human resources, because HR people at least look (or should) for abilities and behavior on each individual while some IT people that performs this tasks have zero idea about and mostly have no motivation for it.

A change is taking place on this thanks to internet and some companies experience but TBH I've seen continents moving faster than the evolution of IT interviews 😅

Yes i catch your point of view and i also read your answer to the sorting issue (converting into string is a bit tricky here, you'll need to change dots for a value that makes 3.10 sort as bigger than 3.3.3)

Another solution could be split this data into a matrix and assume weight for each array position decreasingly, then you sort each array inside the matrix by it's weight value.

There are some valid solutions i figure out for that problem but well, it's all about practice. I've been commenting here to show a bit of hate about IT interviews (I've to do so once a month for keep breathing 😂) but the OP's tech interview is not that bad, he needs a bit of practice and he'll make it for sure.

I only suggested that because some beginners seem to have it easier when working with strings, I would allow that as a solution to the interview, If I was obligated to do one.
I remember solving this once with a format, but the language already did the tricking "masking" on the "." dots to me. (I think it was VBA, lol, I used to work on that)
The weight solution would be more correct as working with strings is kind of bad for performance usually.
And its really all about practice, and you can't disqualify people because based on failing such a trivia if they create good code in the end. Those things won't pass code review anyway (or you company has other problems, and tech interview is one of those). Those are the sort of things that more people working together always get a better solution, because everyone know a bit of different trivia.

I started with an HTML course using windows notepad when I was 14, the first backend language i used was ASP Classic (which was not too different from nowadays trendy python after all 😂)

Whatever language gives you skills :)

And yes, all companies have issues with IT, specially due to the fact you need to adapt IT to the company but also the company must adapt it's processes for being more efficient and effective while using IT, and most of them only wants IT to adapt things to the way business is driven.
Also the change factor it's important, there are companies hiring junior devs to cut costs and asking them for big products where they have no experience, then you got a poor result of course. I've been coding professionally since almost 11 years and I even could be scared if I had to manage a whole big product for a company with no IT background (learn about the business, understand the needs of each part, pick requirements, deep analysis, define the project architecture, organize the team, break the project into tasks and milestones, guess the timings for each task, prepare the server and the repo, add CI/CD, make a readme, set agile cycles, start coding and pray for all to be ok on each milestone and for the Requirements to remain same as were on the beginning and that if there's any change that this changes don't make your initial architecture and design useless so you need to patch it how you can or rebuild some parts of the already coded app).

I'm tired after thinking on that all but excited for doing it again too 😂 it's a love-hate relationship


Totally spot on, the obsession with memorizing algorithms which are never used in real life is absurd ... the reason why it's popular with recruiters/companies is laziness, it's an easy way to put together some tests.


To me, it seems that half of the questions they ask can be easily found on Google. What a developer is doing half a day is Googling stuff.

I mean we can't know everything, and knowing how the HTTP status codes are divided by heart sounds useless, for example. Worst: I'm sure many of us, who are good developers, can't really explain something because we are so used to do it. It's part of our muscle memory. We don' need to think about it. We don't need to remember it.

Only my opinion of course, but the hiring process in our industry could be much better.


I've got some problems with Google, especially when I worked with rare and big library/framework, because any bug was ungoogleable and you had to think for yourself or wait for devs' response(if they even reply in Slack). I can see why they ask not to google to solve the problem itself.


I happened to me too, but I think it's pretty rare. I'm curious as well if you have any technique to just cram every possible things an interviewer might ask you.


I just glanced quickly over the failure reason let's say, and all I can say is that I am 100% sympathetic and solidary with you. Interviews are really horrible and measuring the potential job performance or position fit with a shady sort algorithm that is almost never used in practice is borderline disgusting... It's a true shame that industry can't do better than this overall :(

I wish you all the best in the future and that you're happy and feeling accomplished at your current job.


Thanks for the comment, Bruno.

I think the thing is: large companies need "solid" processes. They need some sort of script to tell them: "do that if you want to find a good candidate". But doing that they exclude a lot of good people.

Maybe someone isn't that sharp solving algorithms but he/she is amazing in breaking big product requirement into smaller tasks.

There are tons of possibilities and those processes does not consider them.


Indeed, and seems like in code, the industry only cares about minimizing the false negatives, and it doesn't care about false positives: a developer can be amazing solving algorithmic questions, but, really a lousy team player or unable to work under pressure, etc.

My main pain point (and it hits close to home because well I also suck at algorithmic interviews under time pressure) is that some of the algorithms that are required, are actually very far away from the real work, or, as in your case, even if there is indeed a useful use case, it's usually pair-programmed or researched carefully over 2/3h or something.

And I'm 100% sure you would nail it while on the job. And you didn't get the chance because of almost some "gatekeeping" algorithmic questions, that honestly, just tend to get more and more disconnected from real workflows, especially with microservices, docker, CI/CD on the rise, the spectrum of tasks and scope of the day to day work becomes more intense in a very different direction. It just baffles me that we all as an industry can still NOT SEE this, in 2020.


Interviews are hard, and feedback is minimal to minimize liability.

But I can see why they would been concerned if the radix transform required for that problem wasn't obvious to you.

It also may be that they just came across someone who performed better for the same position, and might have accepted you otherwise.

So when I see someone who has trouble with that problem, my first guess is that they don't understand radices, which means that they don't have a good understanding of sorting, which means that they have holes in their theoretical background large enough to drive a small truck through.

Either that, or the interview just made them stupid, because interviews are like that -- but when the interview is the evaluation tool you have, it's the tool you have to evaluate people by. :)

CS theory may not be directly useful for most web development, but it provides a set of tools for thinking about problems which can be invaluable -- so it's worthwhile keeping up on it, even if you never expect to make direct use of it.


You can't expect a normal front-end web developer to know something like a radix sorting and other complicated CS stuff. IMHO there's nothing wrong in not knowing CS-level complicated algorythm and other stuff as a web developer, you aren't going to need them unless you work with science/AI related stuff.


While you may not need them directly, lacking competence in the basic language of computer science is a red flag, for any kind of software engineer.

Although, if your attitude is that web developers aren't real software engineers and shouldn't be expected to do real software engineering, then I guess you might have a different view on this.

But I think it would be sad to relegate them to some kind of second-class code-monkey status.

Well, imho a web developer is not a software engineer, there is nothing in my job that makes me think I'm a software engineer. I do no maths, no big o algorithm stuff and no cs-level data structures.


Especially if the company has a simple CRUD application where you could do the whole Frontend using pure JS alone. The needs of the company should be reflected in the interview, and we still have "balance the binary tree" type of question for the the simplest (and sometimes useless) software you can find.

Except no one asked to work on binary trees, the browser does that and provides the DOM for you to use.
He failed because he didn't knew that sort accepted comparators.
You don't need to know quicksort and CS stuff, but knowing that sort has a comparator input is essential to being a programmer.
Every language that ever has a sort will have an input for a comparator so you can sort "by radix" or anything else.
He failed because of the way the approached the problem, randomly trying to throw things at the wall to see if the stick is bad way of solving the problem.
Even, if one of my candidates correctly identified the problem as "sorting by the version parts", he would pass the test even with wrong/incorrect code.
Knowing how to solve problems is the thing.

I don't believe that "you need to know X to be a programmer". Because everybody has its little X, it makes the interview tests a bit like a Russian roulette.

What I believe is you need to be able to adapt, to learn and to be ready to dive into a business domain to be a good developer. The knowledge you have now will be deprecated at one point anyway.

He failed because of the way the approached the problem, randomly trying to throw things at the wall to see if the stick is bad way of solving the problem.

And maybe he did that simply because he was doing an interview. Maybe his coworker could have helped him quickly if it was a normal working day. Maybe he would have searched on Internet and find the correct answers. Maybe he could have learn from his mistake, grow, and increase his value for the company.

Context matters.

I don't believe that "you need to know X to be a programmer".
No, to be a programmer you don't need to know X, but if you say you know JS, then knowing Array.sort and how to use it is pretty much a given.

Context is precisely the problem. Interviews are a totally artificial context.
The probably just did random things because of the interview, the time limit, that's not how you approach any problem.

Ironically that's how lots of bad companies work, so by doing some interview like that you get to know that they can't manage and only work on time pressure, not on results.

Also, base knowledge like sorting is so commom and basic to being a programer, it will never become obsolete. Javascript will, but all programming languages (given the same paradigm) will have some way or another to sort things.

So I do disagree that you don't need to "know X" to be a programmer. Its like saying a plumber don't need to know any "X", X being pipey thingies.

You don't need to know trivia about the language. JS has a lot of quirks, but you do need to have some foundations in programming, sorting is one of those.
We do have to have some standard of cut, that's the entire purpose of the interview, its just a "search problem" , I do concur that some processes are stupid, like whiteboarding.
No, its not a russian roulette, because there's all the other "human" aspects, not everything should be about programming.

Actually in some cases you don't need to know "X", if you are doing SQL, for example, or Prolog. Sorting is done by the tool, you do need to know relational algebra in case of SQL, or propositional logic and unification in case of Prolog.
I'll all depend on the context of what's being done, of course.

But sorting is a basic thing a programmer need to know (at least how to use it), its together with things like conditionals and looping/recursion.


It also may be that they just came across someone who performed better for the same position, and might have accepted you otherwise.

Indeed.. my GF (which is HR) told exactly the same.

CS theory may not be directly useful for most web development, but it provides a set of tools for thinking about problems which can be invaluable -- so it's worthwhile keeping up on it, even if you never expect to make direct use of it.

Do agree. My degree was not full CS but I learned those algorithm and data structure in the college.

I do see value on it but it's kinda hard when we don't often use this knowledge. I mean, I do some sorting in some common tasks but I either have more tools and/or more time to solve that.

I was practicing algorithm solving for a few days the result for this job would be so much different but the practical result in my long term career would be minimal.

For me it felt like those physical exams where you had to do 30 pushups, 30 squats and run 4km in X amount of time. If you train to do that you'll be able to but it would not make you an athlete.

Thanks for sharing your thought. Very valuable!


As someone who has bounced around the tech industry for decades and has sat on both sides on the interview table, I would say don’t worry about it. If I am in on an interview team and someone misses something, I will drill down to see if this is a lapse or a lack of knowledge. I really don’t care if you know what a bucket sort is. I do want to see you walk through a problem logically and explain to me how you would solve. Do I want you to write out the code, forget it.

I’ve written code in more languages than I can count, I’ve managed programming teams and have done far different. Managed a help desk, repaired hardware, have done systems administration. I currently have an informal advising role in my organization’s Python User’s group. Python is in the minority but we still gave over 200 members. With 7-8 years of python experience, I’m one of the more advanced engineers.

With that after decades in one sector, decided in a change. Hadn’t seriously sat for interviews for a while but skills come back. Got into a company known for their difficult interviews but not a good fit. After a few months, decided this wasn’t for me, too many hours and a manager that couldn’t decide what he wanted.

Before I restarted, I though hard about what I wanted. Then I started interviewing. The worst were the interviews that required coding exercises or knowing some obscure algorithm. With a bunch of languages bouncing around in my head, hard to keep track. This is what google is for and I explained this. Wishing them luck on their search, on to the next.

Then got a call from a nonprofit, largest in their sector with almost 20,employees. Set up a couple phone interviews and then an on-site with my managers and 2 senior managers. Very relaxed, asked what my expectations were, I mentioned no insane hours, they laughed.

This was a fit interview, I passed. In many cases sitting on both sides, you will find that the most technically brilliant candidate can be passed over for someone with no where near the knowledge. The last thing a team wants is a bunch of geniuses who can’t get anything done for debating over the best coding style or algorithm. I am a stickler for well written code and logical structure but I don’t need a debate about why I should write a project in Java instead of Python. I might just write in Bash to irritate you. If I interviewed you, might wash you out in the process. All about the fit.


As a self-taught web developer going on 25 years now I am sympathetic and if it helps you out at all I would have failed that question coming at it the way you were coming at it -- but I wouldn't have come at it that way.

Below is a super simple solution, using the Intl.collator; a built-in Javascript comparator. I offer it not to make you feel bad, but because the other questions they asked Object.freeze and requestAnimationFrame sounded to me like they were more interested in your breadth of knowledge over Javascript and some of the more esoteric APIs than computer science; maybe? Don't get me wrong Object.freeze, Request Animation Frame, etc. are all useful but not something I deal with every day or even every year -- not in the corporate space anyway.

const sortVersions = (unsortedVersions) => { 
  return unsortedVersions.sort(new Intl.Collator('en', {numeric: true, sensitivity: 'base'}).compare).reverse() 

Strictly speaking I would instantiate the comparator externally, but it looked like they wanted it all inside the function body. ¯_(ツ)_/¯


Wow, brilliant 1-liner solution! I didn't know anything about Intl.Collator. I investigated a little bit more about it. This also works:

const sortVersions = (unsortedVersions) => { 
  return unsortedVersions.sort((a, b) => b.localeCompare(a, 'en', {numeric: true}));

This is the original solution I came up with in 17 min. (I timed myself to make sure I don't go over 30 min)

const sortVersions = (unsortedVersions) => {
  const vers = unsortedVersions.map((ver) =>
    ver.split(".").map((v) => Number(v))
  vers.sort((a, b) => {
    for (let i = 0; i < Math.min(a.length, b.length); i++) {
      if (a[i] !== b[i]) return b[i] - a[i];
    return a.length > b.length ? -1 : 1;
  return vers.map((v) => v.join("."));

You are all still thinking in Numbers. (including those who interview)
The localCompare won't sort "2.1.0a" properly

Key is to convert Numbers to Letters, so 2.1.0a becomes cbaa and then sort


Or in one line

const sortVersions = (x, v = (s) => s.match(/(\d+)|[a-z]/g).map(c => c == ~~c ? String.fromCharCode(97 + c) : c)) => x.sort((a, b) =>v(b) < v(a) ? 1 : -1)


Or just do something like "2.1.0a" becomes " 2 1 0 a", then it will sort correctly.

const sortVersions = (unsortedVersions) => {
  const format = (n) => n.split(/[.a-z]/g).map(c => c.padStart(5)).join("");
  return unsortedVersions.sort((x, y) => {
    return format(x) >= format(y) ? 1 : -1;

sortVersions(['', '1.0.0', '0.5', '0.4.1', '1', '1.1', '1.1a', '2.5.0', '2a', '1.1a-final', '2.5.10', '10.5', '1.25.4', '1.2.15'])

Yes, indeed. Same concept: sort characters.
It also shows why tech interviews are required. You need a balanced team of developers to bounce ideas around like a soccer team bounces the ball around and one person (and the whole team) scores. So Raul was declined the job because:
A. He did not fit in the team (they already have enough people who can't sort)
B. They are a company who only want Guru developers (in which case they will eventually fail, because a team of Guru developers will never ask the "stupid" questions that drive innovation) Its the famous Think Different Apple video. You need misfits in a team.


Oh, thanks for sharing. I still haven't used Intl API yet so I couldn't imagine there was such a thing to do this easily.

I'll definitely take a look on it, appreciate that!


You're going to kick yourself here: A localeCompare()-based function is probably what you should have passed to sort(). You can tell localeCompare() to handle digits it encounters inside the string as numeric values. Replace '.' with '|' in the callback to avoid decimal issues. It'll (probably) handle all of your test cases like a champ and can be done in one line of code. Although spanning a couple of lines of code and some comments can't hurt either during an interview.

The restriction of not being able to look up information specific to a problem is total cheese. That means they didn't make the problem interesting enough and is a red flag. A better interview coding session is to take a ~2,000 line widget or application that has a specific past bug in it from a real internal application, show the bug report to the interviewee, show them how to replicate the bug one time, and then watch them go through the process of fixing it without any restrictions on what they can do. That's something that can definitely be done in a half hour and is a much better test of critical developer skills: Can you digest a completely foreign application or widget, reverse engineer all the way to a specific URL and then its path on the system, dig in with various dev tools to debug the cause, and finally apply a one or two line patch to correct the bug? Plus you would get a taste of the actual code they write there and can decide if you like that coding style or not.

Little piddly tests about "do you know all 1 zillion functions and features of unstable language XYZ that changes every 6 months" that are pass/fail are largely pointless except to whittle out perfectly fine devs. The official ECMA Javascript specification is a 600+ page long technical PDF partially designed for backwards compatibility with NCSA Mosaic in mind. Neither you nor anyone else has actually read and comprehends the whole thing and, even if you did, your knowledge would be outdated in short order. I've been writing code for a REALLY long time (and I'm a pretty solid C/C++ dev to boot) and MY eyes started glazing over after the first dozen pages. HTML and CSS have similarly long, technical W3C specs.

Keep in mind that hiring is a two-way street. You are evaluating them and whether or not you want to work for them as much as they are evaluating you and whether or not they think you can do the job (and work with them). If you aren't going to enjoy working for them, the interview is the best place to identify that and then just part ways amicably at that point.


Worth pointing out that in Ruby,




I'm sorry that you had a frustrating experience with your interview process, but my overwhelming gut reaction is that you don't actually want to be working for a company that thinks high-pressure algo regurgitation is a reliable litmus for quality dev team candidates.


BTW, I pointed out the Ruby example not to be an ass but to make the specific point that it's a stupid interview question. Unless they are hiring you to live code language-level algos on Twitch, why not spend the interview time talking with you about how you solve problems?

Their loss.


Raul, I really feel for you!

These multi-part interviews are frankly awful and put people through a lot of anxiety. The point when I'm the least creative (in coming up with a solution) is when I'm stressed!

I think there should be more emphasis on working out if you are a problem solver, good at finding the right information, etc. For my current job, I was given a project to go and solve. It got me the job. There is no question if I wrote it - only I knew why I implemented it that way ;)

After 3 decades in software development, I've learnt to chill a bit and remind myself that companies are lucky to have me (and you!). Oh and it's 23:00 and I still on my computer :).


More than candidates and job applicants, companies and interviewers should generally be the ones learning from your experience, and such articles.

After 10+ soon 15 years of experience, I am interested in people who value who I am as a person, what experiences I bring with me, to the table and in my ability to tackle real/concrete problems.

Any discussion that'd purely focus on solving an theoritical algorithms, gravitate around big-O notation... etc. would be showing me big signs of an interview funnel built for the masses, that isn't worth it, and that therefore I shouldn't even be investing any of my time in and towards.

Value your time. Value your energy.

Make it clear with the hiring manager, very early on, how you'd like to be interviewed, what you know is relevant and what you need/want to be assessed on. Companies are as much in need of talent as you are of your job, and you shouldn't be afraid to express your preferences and have certain parts of the interview to be conducted on your own terms.

Over time, with enough of such feedback, hiring practices and processes will adjust.


This sounds like a classic case of testing for rote memorisation of algorithms that seems almost designed to hire either junior devs fresh out of college, or other people who specifically study for the kinds of unrealistic tests encountered in bad interviews.
While I agree that you want to probe for basic computer science understanding, I find these sorts of interviews needlessly stressful, unrepresentative of the normal working environment and most of all, incredibly ineffective.

The sad thing is, a lot of the time the interviewers themselves know that the process is bad, but feel compelled to go along with it anyway. For the most part it's a waste of time for all participants.


The best technical interview I had is summarized in this: I went in, they greeted me and they told me that the person in charge was coming ... He came, greeted me and said, please solve this problem and handed me a list of continuous printer paper with a data exception of Cobol Cics. I found the error, I marked it with my pen and when this person came back and saw my notes he said to me: You start tomorrow Welcome aboard !! . He was the best technical leader I ever had and I was fortunate to replace him when it was time for him to be promoted.


The way I see it is using a custom comparator function in Array.prototype.sort taking care of the details. For example: split by dots . and compare each positional number with each other.


That's the solution anyone would expect, you don't need to know any algorithm for sort, but passing a comparator is such a basic thing.
You don't even need any algorithm to solve the problem.


Typical example where humans fail. When they see numbers they want to calculate with numbers. Almost all 30+ answers in the mentioned SO thread do so.
I just added my answer. And probably would have failed every job interview if they only excepted the solution they themselves came up with.



Hey Raul,

You learned so much from this process that I'd challenge you to not think of it as a failure, but as a life experience. I'm searching for employment now and I have to try and remember that every rejection is a chance to learn something new about myself. Unfortunately, most companies don't seem interested in sharing why they reject candidates and we have to play detective, but I personally believe there's always something there for me to discover.


Hey Scott.

Actually I didn't fell myself as a failure, I just failed in the process. This text was more about a reflection about my expectations.

I had a breakdown situation 2 years ago that taught me exactly what you're saying: every single experience in life, good or bad can teach us some lessons and help us build a better person.

Thanks for the message.


Great article; thanks for sharing your experience in-depth, as well as your insights/takeaways from it all.

And I especially liked the interspersed Dev.to articles and code snippets dealing with all the questions you were asked. :]


Coding tests are a practical, and often valuable method to matching a candidates interview, resume and technical skills.

They are useful when they are domain specific, not entirely time boxed, and less specific to CS fundamentals.

If your day job is basically working in a CRUD application, and very little in algorithms, then this is a bad technical interview. Then again, they may we looking for someone with that sort of background.

I've done interviews with and without technical tests. I can say without a shadow of a doubt that the resume is the most important tool you have for landing a job. It needs to clearly communicate your skills and exposure to various technology - and achievements, in a concise and meaningful way.

When you get to the technical side, you have a technical test as backup, something that is designed in house and reflects the sort of work you do on a daily basis.

The reason why algorithms are used in technical tests is because it tests your understanding of syntax, language, comprehension, knowledge and mathematical skills. The thing is, you won't often use those sort of algorithms.

I've always loathed on the spot, time boxed coding tests, because they test the wrong thing. Everyone works in different ways, most don't do well in that situation.


Well said.

The impression I had doing the interview they were following some sort of "steps to interview people" guide. Somehow they conclude that those steps would be a good fit for whatever developer position they have. 🤷‍♂️


Wouldn't it be nice if a code challenge allows the interviewee to search on Google? At the end of the day, all we want is a solution. It would be nice to figure out the solution by yourself, but if that takes 10 times longer than a Google search, it just misses the point completely. Code challenge is just a highly biased IQ test.


Thanks for the post, Raul. I followed your exercises and also stack at the last one, whilst arriving at the same conclusion as you are. I have around five years of experience writing code in production and I haven't encountered such task, I immediately thought to myself that the first thing I would've done in real environment as probably asking backend team to implement sort, there's never a reason to burden client with sorting data. But anyways, I kept wondering what sort of position you've applied to, i.e. junior, middle, senior? All other tasks seem much much more easier than a final one, what would solving that one gave to you?



I kept wondering what sort of position you've applied to, i.e. junior, middle, senior?

Actually they didn't specified a level. They just said: "Front-end developer" but by the salary I could imagine it was something from medior to senior.

All other tasks seem much much more easier than a final one, what would solving that one gave to you?

Indeed, have no idea. I felt they were following some sort of "interviewing people platform" and getting the steps from there.


Thank you Raul for sharing! This is really helpful and it also shows me how scary this industry is with their interviews. I am a student hoping to get a coop job starting in January and I will treat each interview as an experience even if I don't get the job. You are so amazing and I wish you all the best!! :)


Thanks Lily.

I'm glad you could get some of this article. That's was my goal with it.

With you a good luck! :D


To be honest I have a feeling you did great in this process and it's a shame they made up their mind mostly by judging the very last part of it.
Plus, I always feel like there's a lot more to a coding exercise than the exercise itself: how the candidate is behaving, whether they're being honest (or not) about what they know and humbly don't, etc.

What bugs me a lot when jumping through the hoops of hiring processes is when companies focus more on what you know by heart/already learned than on your actual potential for what comes next. We don't spend our days solving problems by heart without internet or colleagues to collaborate with, and being a developer is not about being alone with one brain only in a cave. Thus, the coding exercises often feel unrealistic compared to our day-to-day as developers, and not so relevant.

Of course, people who ace them are very good and competent but does that mean we can (or should) rule out other applicants?


I had the exact same feeling "Despite the challenge, I did super well".

The theory which makes most of sense in my mind (which some people comment it out) is that they had another candidate with the same profile as me but he/she went much better than me on the code.

We don't spend our days solving problems by heart without internet or colleagues to collaborate with, and being a developer is not about being alone with one brain only in a cave.

That's totally true, even when I'm working a by myself and I don't have someone to ask help I have much more time and resource to figure out the problem.

The best interviews I have ever had was about implementing a tiny project or debugging apps to solve some bugs in a pair programming mode. I think it was much more closer with what I was supposed to do if I were hired.


It is only going to get worse, Raul.

Just wait till you have been in the Internet business for 30 years (Yes, I started with Gopher) then get interviewed by a 27 year old Lead Front-End Developer who has done React for "all his live".

I was given a full day challenge and didn't get the job because I:
A. didn't use a separate document for every component (he didn't understand JavaScript scopes)
B. Used (windows) .exe to replace content in files instead of a grunt script (he had never seen that used)
C. Used technologies that didn't run in IE10 (modern W3C Custom Elements API) (he was so into React he never checked new developments)

These challenges are not about a solution, but how about you react (pun intended)

Even the 30+ answers on the sorting problem give the incorrect answer (IMHO)
I have added mine:


Hey Danny.

lol... that's crazy.

I just take a look on it, it's well explained, thank you for that!


After every coding challenge I feel like a failure, but I just accept that is not my thing to code with a clock ticking. Sometimes the correct thing to do is take 15 minutes to think, to understand the problem, throw away everything you did and restart with a clear view, but that is impossible in timed tests.

I just finished a HackerRank test minutes ago and I was stuck in an edge case for 20 minutes or more and could not understand why the test was expecting a different output. It did not take 30 seconds after I submitted for my mind to understand what really was the problem with the edge case.


Other websites that are really good for practicing algorithms are Exercism.io and Interviewing.io. This last one allow you to schedule a mock interview with actual recruiters of big companies like Google and Amazon, you can check some recordings here: interviewing.io/recordings/.

I think it all depends of context and the company hiring. If the job position requires algorithms skills, ok. But there are companies that doesn't require that level of algorithms and are ok on just giving a challenge focused on the role and the skills required for the role, in instance, a BE developer will receive a different challenge that a FE developer, same for a DevOps and Data Science for example. It is true that being a developer that also is knowledgeable of algorithms might be able to create code that has more performance and etc, but is this developer a nice person to work with? Are they dependable? Are they resourceful and have a good communication? These things cannot be discarded and often times should mean more than an algorithm solving skill IMHO 🤷‍♂️


I love this post, fantastic summary of the whole interview procedure and I love your thought process. I also recently went through an interview with a large company, and as someone who has been in the same job for 10 years with no "technical interview practice" I was very worried about being asked to produce some obscure algorithm. In my case I was lucky and the problem I needed to solve was very achievable. Regardless, I think these things need to be more about process than end result. People don't always perform well under pressure like that!


Thanks you, Rose.

Indeed, time pressure and 3 people evaluating your thinking does not help much while solving a non trivial problem.

But that's life. At least it helped me to see hiring process with a different perspective! =p


You didn't failed because an algorithm. Array.sort() is fine for the task.
You failed because you don't know how to use sort when the data isn't a single atom. You need to know how to sort by weight.
Sorting is such a basic usage. If you didn't knew that you could at least format the strings as "005002001", "001000000", so they would be sorted and that would be a valid solution.
No, developers don't need to know how to implement BubbleSort, but you need to be able to use it effectively, and you failed on defining the problem.
I wouldn't fail a candidate solely on this, but I expect them to not go randomly trying to create algorithms, I would let them google for the solution if they at least explained the problem, I expect them to understand the problem, its not about going doing things and trying to make the test pass (I use DDD, not TDD, you would immediately fail for that reason alone, the way you solve problems).
And the problem was sorting by the version, you can either pass a comparator for version, or convert version to a normalized string or even to a integer, either way of solving the problem would be valid.

Heck, even giving up would be a fine answer if you understood that you needed to sort by the version and didn't knew how to.


Feels like they are going after a chimera. They want some superintelligent dev that is able to tackle any problems with ease and give him some of the backlog tasks that nobody were going to do because they don't have time.

You dodged a bullet anyway.



And it's funny because in my previous company they had some sort of the same processes and when people were hired, they asked them to build some UI in React, maintain an existing project or fix some CSS lol


Thanks for sharing this kind of experience with us, Raul. I'm in a middle of a bunch of hiring processes right now and that kind of story gave me hope of gathering as much experience as possible even with an undesirable outcome. We must never forget to keep on learning!


I'm glad to hear, Thiago.

Wish you good luck in your processes! :)


most of those questions are terrible. Asking about stuff that can be found in documentation is extremely stupid way to go about hiring process. A developer does not need to carry the documentation in his head. Ultimately it can amount to nothing, when a technology stack can and ultimately definitely will change in the course of the next few years.

Hiring is definitely hard, a good developer can see how so many companies fail at it completely. For example an interview such as the one described in this article easily leads to hiring a subpar developer, that prepares for interviews on portals like this one. Here you constantly have articles about trivia interview questions etc. So if somebody, who's not really even an experienced dev goes through these articles would probably ace that interview and be hired, despite the fact, that when you'd give him work to do, he'd be just hopeless.


Sorry to hear that.

I hope this article I wrote on coding interviews can help you with your next interview:


Take care.


Don't be harsh on yourself. I got rejected once because I didn't knew what a React Portal was, which in case you don't know it's something you learn in 30 seconds by going here: reactjs.org/docs/portals.html

When conducting interviews I give more importance to the human interaction since I think anyone can learn how to code, but it's harder to teach someone how not to be a jerk.