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
- Stage 2: Human Resources (aka HR)
- Stage 3: The managers
- Stage 4: the HR (again)
- Stage 5 (latest): The devs
- The last HR Call
- Thoughts about hiring X our skills
- Learnings
- Conclusion
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
itortestin 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:
- 20~ min to get know about what I currently do;
- 30 min to answer and explain technical concepts;
- 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.
GETPOSTDELETEPUTPATCH
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.
Eg:
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'];
expect(sortVersions(versions)).toEqual(output);
});
// 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 = [
'1.3.0.9',
'0.2.0',
'3.1.2',
'0.1.6',
'5.0.0',
'3.3.3.3',
'3.3.3.3.3',
'3.10',
'0.2.0',
];
const output = [
'5.0.0',
'3.10',
'3.3.3.3.3',
'3.3.3.3',
'3.1.2',
'1.3.0.9',
'0.2.0',
'0.2.0',
'0.1.6',
];
expect(sortVersions(versions)).toEqual(output);
});
And here I just got stuck.
My previous solution didn't cover cases like this. It just returned:
[
'5.0.0',
'3.3.3.3.3',
'3.3.3.3',
'3.10',
'3.1.2',
'1.3.0.9',
'0.2.0',
'0.2.0',
'0.1.6',
];
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.
Learnings
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.
Conclusion
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!
Top comments (88)
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.
π
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.
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.
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!
Some comments may only be visible to logged-in visitors. Sign in to view all comments.