What's your take on the Hiring Process in the Tech Industry?

twitter logo github logo ・1 min read

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?
twitter logo DISCUSS (27)
markdown guide
 

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:

  • I worked at a Microsoft shop though being a Linux guy
  • I worked at a Javashop though I had experience with C#
  • I work currently as a Python/JS developer

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.

 
 

My 2 cents: having a reasonable grasp of when and how to use hashmaps is one thing, asking for you to develop a fair hash function is a completely different thing.

 

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:

    • Blocking network calls
    • copy pasted code
    • non testable code
    • very bad naming
    • dead code
    • int overflows
  • 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:

    • What's the day to day?
    • What's the last time do did late nights? (this is a question because I value my personal time)
    • How does the company goes from idea to actual product? (to check that engineers are consulted before)
    • How often do you do 1-2-1/ have meetings with your manager? (so you know that there is someone who can help you with your problems)
    • What's the biggest tech debt? How/When are you fixing it?
    • What do you like/dislike the most here? (Every company have issues and I like companies where you are open to talk about it)
    • What is your perfect candidate? (See if you fit)
    • What's the last time you did something fun? (fun is very broad here as each person have a very different of fun, for me solving very complex tech debt is fun)
    • Why are you looking for a new developer?
    • What do you do at lunch? (do they eat at their desk alone or eat as a team?)

As an interviewer, I also like to ask:

  • What do you want to become and how can we help you?
  • What's your perfect position/company?
  • Why are you considering leaving your current position?
  • What are the things which will make you quit? (to see that your company is aligned with the candidate)

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:

  • Not knowing is fine, Google exists and we are aware about it
  • Knowing wrongly is worse than not knowing.
  • Be yourself as an interviewer and interviewee, I'm just here to see if we can work everyday together for the next X Years.
  • Don't lie, the probationary period is here for that.
 

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.

 
 

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

Do you think something better can be done?

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.

How do you feel about Data Structure / Algorithm challenges people have to pass through to prove you know what you're doing?

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:

  • How would this be relevant to my daily work?
  • Are you encountering issues where this algorithm is needed?
  • Why did you choose this specific problem?

If they pressure you to move forward, and you don't want to do it, be honest:

  • This isn't something I would be interested in doing. Can we move forward?
  • I would need to do research and this isn't right environment for me to be successful, can I think through it and probably get back to you on this?

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.

Care to share your experience?

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

 

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.

 

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.

 
 

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:

  • Technical interview with a questionnaire(from basic to advanced questions)
  • Two paid weeks/months doing real work(this would need a pre-selection process to not hire too many false positives)

Any ideas?

How do you feel about Data Structure / Algorithm challenges people have to pass through to prove you know what you're doing?

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.

Care to share your experience?

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 first real software development job was for a Sr. Front End Dev position. Prior to this, I had been working in IT in non-dev roles. So, having no dev experience on my resume, I brought my laptop and showed off some of the work I had done on my own. I had great exchanges with the interviewers. They asked questions about how and why I built things the way I did. They even made suggestions for improvement. I got the job.

I would prefer that interviews be conducted in this manner more often. Have the candidate bring their laptop with them to review code/apps that they have written or review code on their Git repos. As an interviewer, I would first spend some time (15-20 minutes) to review their code privately before we do the actual interview.

  1. If its their code/app, then they will be passionate when talking about it, defending it, stepping through it
  2. The interviewer will have a much easier time detecting BS by asking how and why the candidate made certain decisions
  3. The interviewer will gain better insight into how the candidate thinks and makes decisions. It's not just the "what" or output of predefined coding challenges.
  4. Interviewer can gauge level of openness if you make meaningful suggestions, recommendations and see how they react - a good indication of collaboration skills
  5. When you see a well-designed, well-coded application for the first time, it's very evident and immediately clear. The rest of the time would then be spent asking about the path they took to get there.
 

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.

 
 
 

"diversity"... who gives a damn. Hire the best person (or at least any one that fits your team), regardless of their race, creed, colour, politics, religion or fashion sense.

 
Classic DEV Post from Mar 1

What was your win this week?

Got to all your meetings on time? Started a new project? Fixed a tricky bug?

Gift Egwuenu profile image
Software Engineer with a passion for making the web accessible.

dev.to now has dark mode.

Go to the "misc" section of your settings and select night theme ❤️