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 comp...
For further actions, you may consider blocking this person and/or reporting abuse
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?
Exactly.
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.
I share your thoughts.
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.
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.
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.
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.
👆
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.
Indeed.. my GF (which is HR) told exactly the same.
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!
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.
Worth pointing out that in Ruby,
returns
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.
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 askedObject.freezeandrequestAnimationFramesounded 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.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: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)
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
explanation:
stackoverflow.com/questions/683259...
Or in one line
`
Or just do something like "2.1.0a" becomes " 2 1 0 a", then it will sort correctly.
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!
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.
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.sorttaking 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.
stackoverflow.com/questions/683259...
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.
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.
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.
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.
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.
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. 🤷♂️
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
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! :)
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?
Hey.
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.
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
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:
stackoverflow.com/questions/683259...
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.
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. :]
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.
Sorry to hear that.
I hope this article I wrote on coding interviews can help you with your next interview:
dev.to/codinglanguages/how-to-ace-...
Take care.
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.
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.
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.
Indeed.
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
The industry is in a weird place. We've never truly had a "way". There was never a Tao for developers or technical people in general. The educational paths are inconsistent and often dated. The interview processes do not answer fundamental questions like "Can this person do job A?". Salary is often tied to intangibles and is mostly based on soft skills and timing. It has been brain washed and established weird corporate cult followings.
I've been fortunate to be in the hiring position and I was privileged to be able to sit down and meet with many developers in my career. When I first started hiring and doing interviews, I didn't know what I was doing — so I went off the playbooks that the industry recommended and that HR peddled.
None of that works. It's cruel. The people that do well at those are people who have become really good at interviewing — not people who will be good at the job.
I decided that was not how I was going to hire people.
Rules:
The goal was that at the end of the interview, I should be able to confidently say "This person can do the job, because they did it in the interview."
Stayed away from asking about degrees. Stayed away from academic questions. Became more interested in applied knowledge and demonstrated experience. Focused on things that were only relevant to getting the jobs done.
Lo and behold, the interviewers were happier, because if they didn't qualify it was apparent as to why. Interviewees were happy for the exact same reason.
Our quality of hiring went up, our pipeline for hiring filled out.
It also allowed us to frequently gauge where we needed growth internally because we'd have to look inwards about what we wanted and what we already had, and whether or not there was a discrepancy.
Remember that when you interview at a company, academic questions are probably a red flag. You are also interviewing them. If they demonstrate that they don't know how to interview, they may be demonstrating that they may not be worth working for.
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.
As algorithm interviews go, this is very much on the easy side.
Typically when people say coding interviews need too much algorithm knowledge which are not required in daily life, they mean stuff like dynamic programming and Dijkstras. This one can be solved without any sort algorithm knowledge at all. Just need to provide a custom comparator to the standard sort.
Thanks for sharing! Technical interviews can be the worst.
Sigh* This just sounds like a typical failure of the hiring process that's broken. The only reason I can think of is that they might have another candidate who happens to do a bit better in the interview than you, and they have to think of an excuse to not hire you.
I also had similar experience, where I applied for a frontend position which asks me to solve the traveling salesman problem...I failed that too. In fact later I asked another senior backend developer for help, it also took him quite a while to work out the solution and the code was quite long as well... I can hardly think anyone can finish this and another two questions within 2 hours, unless they have deliberately practiced this solely for a few months.
So... unless the company is like Google or Spotify that has enough fame and pays enough money to merit for such torture, sometimes I just pass that. I know I'd fail so why spend time on that, instead of learning/doing something useful? I'd rather go for companies that has a sane test, such as making a MVP app that's likely to be my real potential job, and has slightly equal engineers exchanging conversation and giving feedback.
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 🤷♂️
happens to me, I'm able to answers React and JS related question smoothly, but when it comes to simple algorithm challenge, the anxiety kicks in and I get stuck (I was not prepared for this). I thought the live coding challenge would be React related challenge and I was prepared for that.
You know the feelings after the interview was so freaking bad. Like, I was shipping multiple production-ready app and bruh, can't resolve simple algorithm challenge hahaha,
am I really that dumb?
But I learn from that mistake, and I agree to always be prepare for all possibility during hiring process.
p.s I am actually not officially failed yet (the result will informed in next week), but if I do, I know which part that I am failed at.
wow! I am glad to see this info. As a developer i have been following up with trending dev news but could not pass my last interview maybe I had a little experience then. I recently applied for a job at recruitmentformat.com and I will really have to work on the latest algorithm before the interview.
Cara, que azar! Honestly reading your article from home, my hunch on solving it was right, BUT I don't think I would've been able to solve it if I were in the same environment. It's something I also struggle with. I feel like I'm a very competent (albeit junior) developer when I'm allowed to work at my pace/environment, but these technical interviews are always the opposite of that.
Thank you for writing this post - as someone in the job search right now, it's comforting to read what more senior developers go through and how it's not that different.
Boa sorte Raul!
Thnaks for thos feedback ! it will help more than one, good luck for the next shot.
Algorithms are totally useless in web dev interviews IMHO. They are a big red flag to me, it's just a sign of the company being almost clueless about the development process.
Nice article! Thanks for sharing :)
I had a very similar experience this week, I even gave a few ideas about how to fix it: dev.to/endymion1818/the-pain-of-fa... ...
Just read your article Ben and I really like it.
I do agree with you in the points you made there about other ways to evaluate people. I always wondering if, someday, we we'll find a good way to evaluate better people in a sense that respect different abilities and considering a lot of situation than just throw them into a box and saying: "go, fit in there if you want to pass"
Like you, I've been dealing with complex solutions for a long time and still get frustrated by issues like the one you described. I understand and believe the importance of a good algorithm, but measuring a person for a 30 minutes [supervised] test may not the best way. It's even more strange when you are not allowed to rethink your solution using time and research, when some tests come from a google search. Even worse when the applicant is analysed by Devs most of the time less experienced or not concerned about the overall objectives of the role (once I was interviewed for a Team Lead position with ability to read Python and the Dev kept asking algo questions about Javascript). I see HR professionals getting better over time, but relying on wrong methods or IT analysis.
You're not a failure! I'm sure you'll get a new job soon :) Gotta keep on keeping!
Thanks for sharing!
Glad to help with! :)
Thanks for the invitation.