Somewhat of a venting post, though I will try to maintain a constructive tone.
Today I was contacted by a young company, a Startup that has survived the early years and now seeks to expand their team.
So far, so good.
The recruiter was exquisite explaining both the current situation and what are they specifically looking for.
Then she explained their hiring process:
- [✅] initial HR call
- Cultural fit: 1h conversation
- First Tech Interview: 1h tech conversation
- 30 min call with the CTO
- Code assignment: between 3 and 8 hours - take - home assigment (up to the candidate)
- 1h Code Review with the Teach lead discussing the solution.
- Final interview with the team. (30m ~ 1h)
Look, I get it. Finding the right team fit is crucial. But seriously, this marathon of a process feels like it could do more harm than good.
I just didn't start this road.
These kind of processes may work for those shiny FANG-level companies. In this case, this particular company wasn't offering a salary over-the-top.
Possible changes: remove the code assignment and its review.
initial HR call
Cultural fit: 1h conversation
First Tech Interview: 1h tech conversation
30 min call with the CTO
- Code assignment: between 3 and 8 hours - take - home assigment (up to the candidate)
- 1h Code Review with the Teach lead discussing the solution.
- Final interview with the team. (30m ~ 1h)
+ You're IN; just a friendly conversation with the team, not part of the process.
Does this hiring process seem like the usual approach to you?
--
Thanks for reading 💛.
Top comments (25)
Unfortunately, that process sounds relatively normal. In the software industry us developers/engineers are expected to prove ourselves much more than in most other industries. I do wish personal portfolios held more weight, but I at least understand the argument why they don't. While from 1 perspective, this can seem "over the top", from other perspectives it's understandable.
From Your Perspective
You are one person with limited hours in a day to get things done. When you decide to interview with a company, you are deciding to invest some of your limited time into them. And often you're not just investing in one company at a time. You might be interviewing with 3-4 at once. So 3-4 1 hour meetings + an 8 hour assessment for 4 different companies can definitely add up to a lot of time being freely given.
From this perspective, the whole process can absolutely seem like overkill.
From the Company Perspective
The company typically has a budget for a role and just like anyone, they want to get the most for their investment. Keep in mind their investment is significant. It's not just salary they're paying. They're also paying for benefits, resources and materials, and the time of other employees to onboard and train...this all adds up to a pretty large price tag.
Think of this like buying a car. If you were to walk onto a car lot intent on buying a vehicle for over $100,000.00, wouldn't you want to do your research? Most people wouldn't just buy the first car that looks nice. They would probably want to look up the specs, see what others have to say, take it for a test drive or 2, compare it to other cars, see what it's capable of and what kind of contract can be worked out.
I think the best case scenario we can hope for is that both sides respect the other's perspective and try to meet in the middle somewhere.
I'm a recruiter and I don't agree.
When a company has a recruiting process which sucks for the candidates,
it should fix it because
Not all companies are like Google which can afford to be very generous in wasting the time of the candidates.
As someone who is currently on the job hunt, I agree with you...companies should "fix" it. The challenge I see is defining what "fixed" means. There's no standard, and every company's needs are different. Some companies just need to make sure you will work well within 1 team, but other companies are more cross team focussed, and they need to make sure you can work well with multiple teams, or clients. What would your vision be of having this "fixed" so that needs are met on both sides?
You got it exactly right.
It's like in a couple, the most important thing to do is to figure out what your real needs are.
Once you know that, you define 5 hiring criterias directly related to your concrete needs, and you laser focus on those, simplifying everything else.
I'll prefer take-home technicals over the white-board, non-sensical, contrived, jack-assery, problem-solving riddles any day of the week. I actually have fun with take-homes and its the least stressful part of the interview process.
I don't think there is any getting around some kind of practical coding exercise and it's important to be able to talk at depth about work you've completed. I know talented engineers who can't explain their great work to save their life.
This would not be the step I would remove if I was trying to optimize the process. I too loathe these as a candidate, but as someone who has been a hiring manager, this is an essential step to ensure that you're hiring a team of similar caliber.
How I would change the process:
could work too definitively !
I read an argument that we should accept shitty practices because we have to "See it from the company perspective".
I am a dev & recruiter, so let me offer a counter argument.
A company that does hiring properly should focus on having a good developer experience, meaning whether you are the one getting hired or not, the process should not suck.
What you describe is a developer experience that sucks.
Hiring process at those startups sucks because :
1) those startups suck at hiring
2) they are too ego-driven to listen to their customer and learn how to do it properly.
Let's consider Google, which is the mother of all ego-driven startups, it was famous for its 11 steps interview process.
We could totally "see things from the company perspective" like you propose and delude ourselves to believe they knew what they were doing.
... or we can listen to Google's customers, the devs, but Google is notoriously bad at doing that.
... or we can "look at the data". Which should not be necessary because we are dealing with humans and not traffic performance. But OK.
So what do the data tell us ?
I have specific styles of modern tech interviews in my sights as worse than others. Specifically, the whiteboard interview, the trivia/brain-teaser interview, and the “Knuth Fanatic,” algorithm-obsessed interview. These serve mainly to make the interviewer feel smart, rather than to reveal anything about candidates. But don’t take it from me. Laszlo Bock, former head of Google HR, said this:
And also this:
Deploying Guerrilla Tactics to Combat Stupid Tech Interviews
So that's pretty much where we stay.
top response here (sir, 🎩)
in the end, the hiring process is the first real interaction with your - maybe future - employer. It's really important.
Yes, it's often said that candidates have only one chance to make a good impression, but that's also true for companies because hiring is a two ways street.
First, a disclaimer: I'm in academia, so I'm involved in hiring, but hiring of faculty with a far more complex and lengthy process.
Now on to your hiring process question:
I think their process seems quite reasonable. The stuff you want to cut all sounds important. Actually if you cut all of that, you create a scenario where one person makes the decision (the first "tech interview"). The HR step isn't likely that involved in the decision. Unless the CTO sees a red flag, they will likely leave decision mostly to the tech people. So, I find the final interview with the team rather important. No longer one person deciding in a silo.
The take home assignment allows them to see what you can do. So that also seems important. From what you describe (i.e. "up to candidate"), it sounds better than what some do with obscure puzzle problems.
The followup code review allows them to not just see end product but to also get insight into your problem solving process. It allows them to also observe your communications skills in technical context and not just conversational. It also is a sign that they aren't just looking at your assignment in a correct or not correct evaluation. They are likely at least as much interested in your process as they are in whether your solution is correct. A buggy solution may pass interview step if they like your approach and skill in explaining it. A fully functioning one may fail if you lack skill in presenting it.
I've seen these kind of processes. But for a GitHub-level company. That's my point. This is a 40 people startup offering what they can. Lets tune the company itself with the investment.
One thing that I didn't mention because I don't know worldwide; in Europe, there are 6 months of "free-firing".
Companies tend to over think a NOT final decision. If the person turns not to be a good fit, there is a 6 month trial period. During this period (within 6 months you can tell if you made a mistake), there are no economic penalties for firing a new emplooyee
Here in the U.S., in most states, most employment is "at will" which means a company can fire for any reason at any time (as long as reason isn't illegal such as your age, race, gender, religion, etc), and not just limited to the 6 month period you indicate Europe has.
Anyway, I would think for a 40 person company, this type of hiring process is even more important than a large company. That new hire is 2.5% of their workforce. There are costs associated with onboarding, training, etc. Those costs are likely a higher percent of their budget than in a large company. A large company likely has regular turnover on an ongoing basis so may be better equipped to eat the costs associated with a poor hiring decision.
I've worked for agencies, start-ups and scale-ups and can say that I've been part of (and contributor to) some pretty bad hiring processes. Your assessment is spot on, and is pretty much the exact process my workplace employs.
We're a startup so can't compete in salaries or perks with larger companies. It was important to us that our hiring process was short and extremely transparent. Eventually we even combined the cultural and tech chats; anything unsaid was sent via email, and it made us better at prioritising our questions. The candidates knew what they were signing up for, and the hires were (almost) always stellar.
Investigate GitHub repos and contribution may take 1-2 hours and can erase the whole tech part in cases of an active account.
sadly i have (almost) no contribution to public repos (some thing here and there , but it's not relevant). Since my company has the code on GitHub i have 6-10 daily contributions every working day... but you can't check the repo itself.
Of course not everyone has lots of public contribution but I think that if someone does, it gives very good insights on the level of their code quality. If I would be HR I would definitely make use of it.
I would say that the recruiter acted correctly to tell you what the process would be. If you have a job and are satisfied with it, then no harm no foul - you can politely decline. If on the otherhand someone is desparately looking for a change - they know what they have to face and its up to them to decide if they want to invest the time and effort.
Also, in my experience, a home assignment and a tech review afterwards are a good way to see that the candidate is willing to invest the time (has the desire/drive to join the team) and check how they react to feedback and what was their thinking process (why they picked framework A instead of B; why they wrote a test here and not there). Some companies may skip that part if the candidate has a solid CV and has passed the initial interview with flying colors. A github/gitlab/etc account (if provided) with solid repositories can help a lot as well.
At the end of the day, if they (the company) are getting a decent number of candidates, then the process is probably fine. If not, I assume they will adjust as needed and remove some steps.
That said, articles like yours probably help readers (esp. recruiters) take this into consideration, so its good that you share your opinion.
I'm no fan of large-scope take-home assignments, but cutting out any reasonably-practical application of skills? That's silly. Sure, we can hire and hope for the best, but our investment in onboarding and evaluation is a lot more than the hours expected by the assignment.
My process is normally to take a recent project and ask the applicant to map out their approach to a subset of that project. Usually, we focus on basic architecture ("we're building a webservice with these inputs for further processing later - how would you approach data modelling, API design, and the management frontend for this?"), and let the applicant show what they want to focus on, how they would solve the architectural concerns, how they would structure the application, and (for fullstack) how they would break down the mockup into a component-based framework.
Takes about an hour with most applicants and gives me a very good understanding of the skillset I'm looking at. Haven't hired the wrong person yet. 🤷
It doesn't sound so ridiculus at all. But lately I am in a lot of processes for companies which I really like but one of those big-*ss companies got me so much stressed out that I had to give it a break.
I started this process in April...
I had a process like this:
Now after all of this it looks I am in and then suddenly they start to talk:
"The project for you is delayed",
"The client decided to slow down on the process",
"The client has limited budget, so you will have to wait",
"The client doesn't respond to our emails" and in the end
"Ours are first, then when we fill all of ours own Engineers you will get your chance".
Now you think that we are done. Nope. After all of this I have to convince the client himself that I am material for the role.
I get another 1.5 hour call where we talk testing, QA itself and team leading...
And this is what hate the most. Most of the recruiters say. We will get back to you in the next business day. I wait and then after about 2 weeks time I get a "NO. He is too stubborn for this role and not good for us".
The next couple of client calls with this company sound the same. They tell me that we will talk again or they will call me back. Months go by and I get actually a no.
Oh and my experience is that when I try to talk to them they respond that it is very rude of me to ask if they are interested.
This whole experience made me think that somebody should take care of this cause they are killing the processes themselfs and then cry that no DEV or QA wants to join them and we as IT people are judgy and iresponsible.
This is a very common approach, but the durations seem long.
I'm too giving a lot of interviews currently, so I don't find the above process completely unreasonable. But at the same time make sure the companies conducting this lengthy interviews should compensate for your time.
The steps doesn't seems that bad for me. It's just the way they are listed that make it crazy. Here is another view:
1 HR interview, 1 Tech interview, 1 exercice and a final debrief with the team is quite standard nowadays.
Okay, it all depends on the compensation they are offering. If it's a startup with significant growth potential and the job aligns with your preferences, I believe you should consider it.
The issue might lie in the HR department's ability to effectively communicate that the startup is an appealing place to work and a rapidly growing company.
They should show to you the strongest points about them like this:
"For instance, we've been in operation for about 2 years, have a team of 40 skilled programmers, and have generated over $40 million in revenue since our inception. Here, you'll witness our commitment to high code quality and have the opportunity to learn from our highly skilled team."
Just dropped by due to the title. Reminds me why I work contracts only and do not go for permanent roles. I do not envy the pain and suffering of going through such processes.