DEV Community

Cover image for Startups with crazy Hiring Processes: please don't.
Manuel Artero Anguita 🟨
Manuel Artero Anguita 🟨

Posted on

Startups with crazy Hiring Processes: please don't.

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.
Enter fullscreen mode Exit fullscreen mode

Does this hiring process seem like the usual approach to you?

Thanks for reading 💛.

Top comments (30)

tnypxl profile image

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.

wraith profile image
Jake Lundberg

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.

jmfayard profile image
Jean-Michel ( • Edited

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

  • it's the right thing to do
  • it hurts their employer branding, which means it will be harder to attract the right candidates in the future.

Not all companies are like Google which can afford to be very generous in wasting the time of the candidates.

wraith profile image
Jake Lundberg

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?

Thread Thread
jmfayard profile image
Jean-Michel (

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.

jmfayard profile image
Jean-Michel (

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:

On the hiring side, we found that brainteasers are a complete waste of time. How many golf balls can you fit into an airplane? How many gas stations in Manhattan? A complete waste of time. They don’t predict anything. They serve primarily to make the interviewer feel smart.

And also this:

Years ago, we did a study to determine whether anyone at Google is particularly good at hiring. We looked at tens of thousands of interviews, and everyone who had done the interviews and what they scored the candidate, and how that person ultimately performed in their job.
We found zero relationship.
It’s a complete random mess.

Deploying Guerrilla Tactics to Combat Stupid Tech Interviews

So that's pretty much where we stay.

  • Hiring processes are a complete random mess
  • Bad practices are everywhere.
  • Good practices exist
  • People are either too lazy or feeling to smart to follow a proper training.
  • As a developer, if the developer experience of a given startup sucks, you should probably leave and focus on companies that are less generous about wasting your time.
manuartero profile image
Manuel Artero Anguita 🟨

top response here (sir, 🎩)

in the end, the hiring process is the first real interaction with your - maybe future - employer. It's really important.

jmfayard profile image
Jean-Michel (

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.

theaccordance profile image
Joe Mainwaring

Possible changes: remove the code assignment and its review.

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:

  • Initial interview with the technical recruiter (30 mins)
  • Code test (take home)
  • Meeting with hiring manager (30 mins)
  • Meeting with potential coworkers/other leaders (30-60 mins)
manuartero profile image
Manuel Artero Anguita 🟨

could work too definitively !

cicirello profile image
Vincent A. Cicirello

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.

manuartero profile image
Manuel Artero Anguita 🟨 • Edited

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

cicirello profile image
Vincent A. Cicirello • Edited

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.

mokiat profile image
Momchil Atanasov

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.

jankapunkt profile image
Jan Küster

Investigate GitHub repos and contribution may take 1-2 hours and can erase the whole tech part in cases of an active account.

manuartero profile image
Manuel Artero Anguita 🟨

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.

jankapunkt profile image
Jan Küster

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.

fjones profile image

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. 🤷

ademagic profile image

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.

8ucik profile image

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:

  1. Call with HR ~30 minutes
  2. Another call with the HR manager ~ 1 hour
  3. Call on teams with the QA manager ~ 30 minutes
  4. Technical call with the deciding QA Lead ~ 1.5 hours
  5. Additional call with the deciding QA Lead about coding and automation ~ 2 hours

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".

  1. I get a call with the QA manager we start to talk about possible project options. This is where I get something quite funny. They tell me that there is another process in a process which I have to take to join a project. We start slowly with: Call with the Project manager ~ 30 minutes Call with the Product owner ~10 minutes Call with the clients technical team ~ 1.5 hours

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.

sidswirl profile image
Sid Probstein

This is a very common approach, but the durations seem long.

sohailshah profile image
Sohail Shah

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.

tandrieu profile image
Thibaut Andrieu

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:

  • HR Call: ~1h, when we talk about our culture and your personality.
  • Tech Interview: ~1h. You may discuss with our CTO during this interview.
  • If your profile interest us, we might send you a Code assignement you can do during your week end. Take your time to do it.
  • Last debrief with the team. If you reach this point, you're probably the right candidate 😉. Let's meet the whole team and your future colleagues.

1 HR interview, 1 Tech interview, 1 exercice and a final debrief with the team is quite standard nowadays.

kallarari profile image
João Vitor Minosso

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."

steferdlisaer profile image

Certainly! Some startups have unconventional hiring processes that might not be the best fit for everyone. It's important to focus on finding the right fit for your career goals and lifestyle, just like choosing the best home workouts for women that align with your fitness needs and preferences. Prioritize a hiring process that values your time and skills.