I have heard a couple of folks complain that the hiring process is broken in tech. I personally have experience with this and will like to know from the Dev community what's your take on this topic?
- Do you think something better can be done?
- How do you feel about Data Structure / Algorithm challenges people have to pass through to prove you know what you're doing?
- Care to share your experience?
Top comments (22)
In my humble opinion, and this is just an opinion (based on my recent events) I can understand that big companies like Amazon, Microsoft or Google to name a few, have a complex hiring process, for example, simply because the number of candidates they need a way to filter somehow. I'm not defending it, but I can see a few reasons behind it.
But the rest of small startups and companies that imitate the same process, it just doesn't make sense at all. People copy, without a thought about why they're copying. Just because Google does it, does that mean that it is also good for your company? I don't think so.
Data structures and algorithms are for a developer like a scalpel for a surgeon. For example, a ruby developer the least you could expect from him/her it's a good control about arrays and hashes.
I'm not against challenges, in fact, I think it's a good (missed) opportunity for both parts to check if that role is a good fit for both, the company and the candidate. The problem is the execution of the process, which in a big number of places it's indeed broken.
Yes, I totally agree. Hiring for big companies has to work differently than for smaller companies. Both have in common the risk of false positives, i. e. hiring someone who doesn't fit. So filtering these out is what the process should do.
But they do not share the same requirements profile. So having the same requirements strategy doesn't make sense.
I was only hired so far, so I can not speak how I do it. But I can speak of the processes at companies which hired me or of my personal requirements for people working with me.
What all had in common was that they were focused on personality and potential. So far I was not qualified (in a narrow sense) for my jobs:
What I brought to the table was mostly a general ability / willingness of learning new stuff. This was valued in all jobs I had so far.
I know that I wouldn't survive a traditional (whiteboard) coding interview because of my gaps of knowledge in some areas. I can't code a BFS from the top of my head. I know what kind of problem could be solved with that. And if I ever need to solve such a problem, I could look it up or ask colleagues about it.
So jobs demanding people knowing that from the top of their heads, aren't for me and I wouldn't get hired for those. So far so good.
What advice I would give smaller companies: ask yourselves whether your hiring process gives you the people you require to do the job.
I'd give this comment 1e6 hearts if I could ;)
As a (former) iOS tech interviewer, I like to mimic how the team is working during the whole process.
Do you do code review? Ask the candidate for one! The code to be reviewed should be quite short and some of the errors should be obvious but it act as a quick filter for your team.
We tested for:
Are you looking for someone who can make ship features very fast or are you looking for someone who can make good architecture choices? Don't ask for a code sample if you are looking for the second.
An interview should be more than the interviewer just asking questions. A selection of my personal questions that I like to ask:
As an interviewer, I also like to ask:
Always remember that the candidate have a life aside. I like passionate people and it doesn't have to do with work. It can be about bikes, cars, video games, animals, plants, sport, ... I always try to spend 10 minutes about nothing "important". Same for any technical tests, leave the candidate as much time as they need.
For Data Structures, I'm only asking the bases (array vs map vs stack vs queue), except if you need them, no need to know about trees and graphs.
For Algorithm, I don't like them as they can be very easy if you already know the solution. Moreover you won't need them on a day to day basis.
Some notes from my interviews:
This seems like a great approach. Especially like the idea of mimicing (as much as possible) how the team actually works in the interview. If only everyone did that.
This sounds like a dream interview process 👍🏽
My ultimate take is that most people don't know what they're doing. They might think they do, but they don't. I've been doing this for 15 years and can say that everyone is just trying something, anything to find the person they think would be right on their team.
So, with that being said - what can you do to make it pleasant for you?
1) Apply for jobs that you want
2) Look at it as a collaborative process (unless you feel they don't match what you're looking for)
3) Interview the interviewer
Yes. Internally, companies and teams need to know what they want and define the criteria more explicitely. This isn't on you. It's on teams and companies to do this - and usually if the interview was uncomfortable - thats a sign they don't really know what they want.
Data structure and modeling is important. Algorithm's not so much. The only time you want to gauge someone (not test) their expertise in that area is if they have a need for it. Think AI, machine learning, etc...
If they toss an algorithm question and you're caught off guard - toss it back to them. Some questions I use:
If they pressure you to move forward, and you don't want to do it, be honest:
If they just want you to do it, without further question: just leave. If they're not willing to be accomodating then no point in sitting through a painful interview that they have already made a judgement call on.
Yeah totally. I can tell you one experience where the interviewer asked me: "If you could fill this building with water, how much water would fit in this building"? I straight up knew you would calculate the square footage of the building and space out the calculation so that it would take into account walls, piping, etc...
But guess what? It was a stupid question. I was going in for a Principal UI Engineering role and this question just signaled to me that they 1) didn't know what they wanted, 2) didn't take the interview seriously and 3) they might have hade some elitism issues.
As an Engineering Team Lead now, I try and avoid the regular interview process because ultimately it's a shifting paradigm that requires you to think through your current problem, future problems and if you have the capacity to really help that person succeed. It's not always successful and there is definitely room for improvement - but definitely not interested in the typical interview process.
Hope this helps! Definitely ping me if you ever want to chat on this subject.
Cheers!
I think it's broken in some ways, and at some companies. I've seen this from both ends of the interview table.
The ways in which I think the process is broken is when interviewers place too large an emphasis on computer science trivia, and not enough on real world experience and pragmatism. I once had a phone screen where the interviewer gave me a trivia question copied directly from LeetCode, and insisted it was representative of the work they do there every day (spoiler alert: it wasn't.) This is the laziest way to interview. What if I had solved that puzzle a few days prior, or Googled the answer and finished it in record time? That's a poor way to measure ability.
I've also had interviews where you're forbidden from looking at the docs and can't use your IDE of choice. That's not how any software developer works. Why place these artificial constraints on someone? Interviewing is already a stressful experience; making it harder for the candidate doesn't make much sense.
On the flip side, the best interview experiences I've had all involved the company asking about challenging projects I've worked on, had me work on coding exercises that were representative of the work they do day-to-day, and let me work with the tools of my choosing. They weren't testing my rote memorization ability, they were testing my ability to reason about a problem, communicate clearly, anticipate edge cases, and solve real issues. Even if I didn't pass these interviews, I still greatly appreciated how they were administered.
When I was the one doing the interviewing, I did have candidates do some whiteboard exercises, but they were problems that myself and my colleagues had to solve on real projects. Even then, I wanted to remove this part of the interview. I'd rather pair program with someone on their machine and with their tools of choice to see how they work.
HR is often not technical and it gets good candidates dropped before they get a chance to chat to the hiring team.
The more "urgent" the posting is, the worse the company is going to be IME.
If they have no reasonable room to work with on your start date, then it speaks to their culture.
It's also aggravating to have to repeat yourself for question lists you answered in the application.
HR regularly proves to be the weakest link in my experience.
I have already written a post about how I think that the processes are alienating minorities but I also am going to extend that and say that they are alienating senior developers. My experience is that many of the companies that use this long winded process don't look at a developer skills as a whole. It's very much if you fail one question then that's it, even if you have other skills that you're stronger in. I almost think that those just out of university have more of an advantage with this type of interview as they've just been through learning algorithms, those of us who have been working for years most likely haven't used them for a while.
I think that the process needs to be shortened. Candidates should not be expected to put in far more work than the companies. I've seen people prep for months for whiteboard tests.
Interviews should try and get the best from people, not be there to trip people up. The places I've been to with the best interviews allowed me to solve problems like I would in my job. That meant I could use Google, I could ask for help and I wasn't being watched while coding. Could you cheat? sure but then you're asked to walk through your solution and explain what and why you did things. It's pretty easy to spot someone who doesn't know their stuff.
Allowing for mistakes too. Interviews are nerve wracking and not a true representation of someone in their day job. I've completely forgotten things in interviews just due to nerves, I've seen people do the same when I've interviewed them too.
Finally I think that other skills (Communication, teaching, leadership, emotional intelligence, etc) should be emphasised too. I feel like some companies just want to hire coding machines rather than people.
In my experience, I'm out of the norm as far as the typical developer mindset goes. I had one of those coding assignments - they came back with "there are no [unit] tests", having completely ignored the fact that it was completely automated end-to-end tested. That's because, as a developer, I believe end-to-end testing provides business value, and unit tests don't. That kind of thinking doesn't typically get you a job.
The way we were doing it at my current job, we have three seniors interview the candidate for an hour - a series of pre-packaged questions that provide some value, but for me, if a conversation kicks up and we excitedly go back and forth comparing different technologies... Well, in the end, between the three of us we're able to gauge the experience level of the candidate. We answer two questions:
Does that experience level match what we're looking for?
Is this the kind of personality we want to introduce to the team?
No additional interviews. No coding exercise because we don't care how good you are right now with a specific stack, but rather that you can learn new stuff. You have your yes/no same day.
What I really dislike, from experience, is contract-to-hire. Switching benefits is really inconvenient.
Feedback for applications would go a long way.
I've made it to some last round interviews only to hear nothing...which I take as a hint that I wasn't selected. This is after in-person interviews (which they always seem to want to set up ASAP) and a take-home code challenge. Clearly, I'm missing something, but it's unclear what it is.
Feedback at the first stage is hard, I'm sure, but even a blanket "we've moved onto other candiates" is better than nothing.
My experience is mostly in email developer/manager roles, as I have rarely gotten a call back for software engineering roles. This puts me in the same loop of, what am I missing?
It's all very tiring.
Oddly enough, I just heard back from a recruiter on a job where I turned in the code test 2 months ago. Apparently, there has been a restructuring and that position is on hold/not moving forward at this time.
Sorry about your experience. I also think feedback is really important from recruiters and you shouldn't be left hanging.
I've recently blogged about why I think the interview coding challenge part is broken and how I think it should be fixed. The dev post is a very shortened version of the blog post.
What if your interview coding challenge would look like this?
Zohar Peled ・ Sep 26 ・ 1 min read
I wonder how brain surgeons are recruited.
While I was writing my comment I had the exact same thought.
What I dislike the most of the current way of doing recruiting in tech companies(small ones) is the step where the candidate is given a mini project to do in 2-3 days.
I dislike it because I've been in both sides. Giving a take home assignment to a candidate and doing lots of them(in 2018 I think I did 4-6 just in four months)
When and where this kind of recruiting started? Why are we somehow pressured to have side projects to have a GitHub portfolio?
Just until recently, I've been trying to understand why this part of the process is done this way and how to improve it:
Any ideas?
I think they're OK if the job one is going to do requires them A LOT. If you're building web forms for not life critical web apps, they shouldn't matter in an interview.
The process I've liked more and felt comfortable were the ones where I could speak to current developers of the companies I was applying for. They would ask technical questions and sometimes they would from me and viceversa.
With an interview this way they were able to figure out, up to some degree, how fit I was.
My experience is a little skewed, in that all of the companies I have worked for in “recent” history (let’s call it the last 7 years), have needed to be small, scrappy, and highly effective.
Whether a product company, a consultancy with a delivery department, or a more traditional software vendor relationship, every company I work for has need for a small number of developers to produce new / rebuilt / renovated products, in a few short months.
Because of this, when I interview a candidate, I find the canned algorithms to be utterly useless. I don't need to know that they have memorized Cracking the Coding Interview, nor that they have memorized the minutiae of a given language.
I need to know that the person can learn, regardless of where they are in their journey (with different levels of expectation, based on the role). As such, I generally try to go on a programming journey with them; whether they do the typing, or I do, or we whiteboard, I will start with a completely trivial problem like “How would you add 1 to each element in this list?”. This is a “can you write any code at all” litmus (because I will have offered to type, they just need to give me the gist of their algorithm), which has actually caught a couple of people who were completely unfamiliar with code, whether imperative, declarative, FP, OO, or just old-fashioned structured programming statements. I try to make clear that there is no single “right” answer I expect, and that there are no trick questions.
Assuming they are capable of answering the question, or typing a solution, I don't really care how they solve it; my goal is now to build on and evolve their solution.
I want to slowly get them to the limit of their comfort zone, in some small way. Never used recursion? Let's try. Never mapped over a list of data with a transformer? Let's implement a map function. You know all of this stuff? Move onto recursive, variadic auto-currying, or architecting a library to automate bumping semver based on commit messages — wherever the path leads (again, role/experience/salary bracket in mind).
I want to see how a person reacts to learning something new. Even if I have to hold their hand through the explanation, or the implementation. That’s fine, too.
The next step, then, is to pose a problem that requires the learning we just went through. It doesn't need to be a massive challenge; if we invented a map function with a transformer, how might we make a filter function, with a predicate that takes the same input, with this predicate, and returns this output?
In my head, I am keeping tabs on how the person responds to being out of their element. Are they terrified? Are they going to throw their hands up, and storm out in a huff? Are they going to be dangerously stubborn, and antagonistic? Are they inquisitive, or curious, or eager?
See, on top of coping with the unknown, learning, and applying the knowledge, how the person responds in these situations is important, when they are put in a small team with a known culture. I have said no to some of the smartest interviewees, because they had meltdowns when we did something out of their ordinary, or I questioned their programming ideology (not contradiction, just “why do you think that _?” or “tell me about why you chose to _.”) within the journey. “Because if you don't do it my way, you are stupid” is generally a no from me.
At the end of the day, I expect this person to be faced with things they have never even heard of before, and in a short timeframe, they will have to gain an understanding and make progress. There will probably be support, but if the person is going to be fatalistic, or feudalistic, it isn't going to work for a team with a limited number of seats and a limited amount of time.
The rest of the interview is standard fare.
Like I said, not everyone’s experience, but this is how I approach interviews and why.
Yes, something better can be done! I put together thoughts from the community in this article.
How to Fix Your Tech Interview to Increase Diversity
Veni Kunche ・ Jun 24 ・ 8 min read
"Talk is cheap, show me your code"