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 (23)
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!
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 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.
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.
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.
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 wonder how brain surgeons are recruited.
While I was writing my comment I had the exact same thought.
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