Hiring Is Broken?

https://software.rajivprab.com/2019/07/27/hiring-is-broken-and-yours-is-too/

by rspivak • 7 years ago

189 189 7 years ago

software.rajivprab.com

nafeydev• 7 years ago

Whats the general consensus on take home projects? How helpful are they?

shados• 7 years ago

Anecdotal survey in my city's community across a couple of companies say 30-50% of people never turn them back in, so while its a powerful tool that gets rid of a lot of issues with typical screens, it introduces friction a lot of people don't want to deal with.

They'd be more useful in a buyer's market.

jethro_tell• 7 years ago

Also, I can set aside an hour or two during the day to chat with you. If you ask me to spend hours implementing something on my own time, I will assume you also ask your employees to do that and will completely blow that off.

What you'll end up with is people who are desperate for your job, which may or may not be a great sign.

sys_64738• 7 years ago

I'd bill the company asking for them a minimum of eight hours at contracting rates. My time isn't free.

gravypod3• 7 years ago

I haven't been able to find a better screening method than take home projects. A major issue that I find when watching hiring take place is people don't separate learnable/domain specific skills from the "inherent" skills you need as an engineer. Hiring someone who has a 10 year track record as a software engineer in systems software for a web-stack backend role should be an easy "Yes" if they are a skilled software engineer. Because of this I usually encourage people to make take home problems that are limited in scope and follow the restrictions:

  - Should not take longer than 3 hours for an inexperienced developer.
  - No learnable skills tested like tooling, language, and domain experience.
  - Simple to understand problem 
  - Problem should be obviously mappable to a solution
  - Provide sample input and sample output data (only 1 case).

I then score using the following questions

  - Did the code work on the sample I provided?
  - Were edge cases in the spec accounted for?
  - Has the engineer followed a language standard (PEP/PSR)?
  - Were docs (install, compile, comments) provided?
  - Were unit tests provided?
  - Were sample cases the engineer ran manually provided?
  - Was the code "elegant"? Could another engineer at the company look at the code and maintain it in a year.

I think the actual project should have low bearing on completion and the state and cleanliness of the code has a higher mapping to quality.

hysan• 7 years ago

Would you be able to give an example of how limited in scope you're talking about?

Is it just a single "write a method that does this" type problem? I ask because I did a take home very recently which I know I could knock out quickly, but it took much long because everything you listed ballooned the amount of time it took me to complete it. Specifically:

  - Has the engineer followed a language standard (PEP/PSR)?

For JavaScript, it takes some time to setup a new project from scratch with linting and formatting configurations. Then documenting it in your README.

   - Were unit tests provided?
   - Were sample cases the engineer ran manually provided?

Once you go beyond a few "features" to write, this balloons in time due to both writing it with good descriptions and documenting it for the reviewer.

   - Was the code "elegant"? Could another engineer at the company look at the code and maintain it in a year.

If what you ask is of sufficient complexity, it would just be normal to take time to think about what the interviewer is expecting here. Like what future features could there be? How might this be used in a larger codebase? etc. Then once you've decided on this, you'll want to spend time commenting and/or writing up an explanation in your README about your design choices.

Lastly, this isn't mentioned but I did this on the take home I recently completed - using version control and properly branching & merging on each deliverable. Doesn't take time, but if you are making atomic commits with good comments, that's just another way for you to lose time. Of course, I don't think the fact that I did this is going to be noticed as it wasn't written out as a requirement.

If you notice what I'm nitpicking, it's all the setup and writing that becomes a time sink for most. In isolation, it wouldn't break the bank, but with all those requirements combined, you've lost much more than 3 hrs. When I'm given take homes for interviews, this is where I've burnt the most time - taking the time to document well.

Stratoscope• 7 years ago

Mobile-readable copy of your lists...

Restrictions:

- Should not take longer than 3 hours for an inexperienced developer.

- No learnable skills tested like tooling, language, and domain experience.

- Simple to understand problem

- Problem should be obviously mappable to a solution

- Provide sample input and sample output data (only 1 case).

Scoring:

- Did the code work on the sample I provided?

- Were edge cases in the spec accounted for?

- Has the engineer followed a language standard (PEP/PSR)?

- Were docs (install, compile, comments) provided?

- Were unit tests provided?

- Were sample cases the engineer ran manually provided?

- Was the code "elegant"? Could another engineer at the company look at the code and maintain it in a year.

scruffyherder• 7 years ago

If you like to roleplay as a tenured professor, sure it's great.

Otherwise it's a total waste of everyone's time.

Extra points if you have a tweed vest and a smoking pipe.

n_ary• 7 years ago

Take home has two sides to it.

Group A: People who excel at face to face interviews(extroverted) will complain that it is waste of time and disrespectful, because it demands significant time commitment compared to a 1 hour in-person interview.

Group B: People with interview anxiety(introverted) will excel at this type of test because they have the freedom to set aside their own time, do things at their own pace and environment.

However, people from Group-A has a point, because certain take-home assingment are notoriously complex and will take multiple days of effort if you want to meet all requirements, which are not an option for people with family & existing job.

djhworld• 7 years ago

significant time commitment compared to a 1 hour in-person interview.

I don't think I've ever been in a software engineer interview where the face to face portion is less than 3 hours (at minimum!)

AnimalMuppet• 7 years ago

I don't know that I'm extroverted. I'm still in group A, though, because I don't have interview anxiety.

My problem with take home stuff is that it's asymmetrical. That is, if we're doing a phone interview, it takes my time, and it takes your time. Ditto an in-person interview. You're serious enough to commit some of your time to it, so I'm willing to also do so. I know you're looking at other candidates, but if you call me in for an in-person interview, I figure I've got at least a 30% chance of landing the job. That's enough for me to be willing to invest the time.

But with a take-home assignment, it costs me much more time than it costs you. So you could be giving it out to tons of people. How many? I have no way of knowing. So you're asking me for 6 hours (which may turn into 12), but what are my odds on getting the job? Are they still 30%? Or are they now 1%, because you just gave this assignment to 100 people?

I'm not going to plow 12 hours of my time into a 1% chance at a job. Just no. And the problem is, if you tell me "oh, we're only looking at a couple of people", I have no reason to believe you. But if you're actually interviewing me, I believe you, because it's too expensive for you to interview 100 people to hire only one.

mjfisher2• 7 years ago

Really helpful, as long as they're done well and respect the candidate as much as possible.

In my experience, they provide a great way of understanding a candidate's skills. It also lets them work in a low-pressure environment with their own tools, which tends to let people achieve their best.

I actually recently launched a service to help make managing take home tests through git more efficient: https://candidatecode.com

It's still early stage, so any feedback is appreciated

esotericn9• 7 years ago

This article appears to be an extremely long-winded way of stating that you don't have to pick from the top-end.

Which is true. Companies know this.

Most of the stuff I read here is basically made up of people who aren't quite the best moaning that they couldn't get a job at Google or whatever. Life goes on. It is impractical and not a good thing for every software developer, even the very good ones, to pile into the same companies.

Not everything is set up as a perfect procedure for you.

And even if it was - OK, so you get the job and the Stanford grad doesn't. You swap places. Does that make a better world?

I encourage new developers reading these sort of posts to just ignore the fluff and plug on. You'll get there.

And if not? In five years you might want something else entirely.

I wanted desperately to work at an investment bank as a new grad.

I'm very happy with the path my life has taken instead.

o104493663• 7 years ago

Could the system be better? Yes. But there's also a ridiculous amount of entitlement in the tech industry. There are very few other industries where someone with a bachelors degree or no college degree at all can obtain a low to mid six figure job with no prior work experience + benefits. Even for the average experienced hire, who's compensation can easily exceed that of the average doctor, it isn't like things get worse as your career progresses.

Many of these "hiring is broken in tech" posts are like you said: moaning or a remarkable lack of self-awareness.

esotericn9• 7 years ago

I don't think of it as entitlement so much as a refusal to see the world as it is.

There are a trillion arbitrary signals that will help or hinder your success in various ways.

Physical attractiveness, gender, race, parental background, your nationality, where you can work, your accent, language... the list is honestly almost endless.

You can wish for a world in which none of this were true, or do your best to find a place within it. Sure, don't lose sight of justice, but recognise that you can't change the world alone.

phkahler• 7 years ago

> moaning or a remarkable lack of self-awareness.

As someone who has spent more time on the hiring side than the job seeker side over the last 10 years, I find these articles funny. I ask myself if each method could tell me what I need to know about a candidate. For many, the answer is no. Then I ask myself if I think the remaining method are fair and often the answer is no. Then I think about how much hassle they are for the candidate and the best methods seem really onerous for the candidate.

I always come back to the way I handle it. And now that I'm looking for a job again I had one interview where the technique impressed me enough to change my style a bit in the future, or at least add some options to what is a dynamic process.

z3t4• 7 years ago

Google would have no problem paying out 7 figure, they would pay out 8 figure if they had to. But its a market and no other pays that well. Just go outside SF and the market is different, much lower pay, but they are just as picky.

maxaf• 7 years ago

Your implicit assumption seems to be that Google and its ilk hire the absolute best engineers. This is simply not true, for one very simple reason.

There is no proven method for sorting a pile of candidates such that the absolute best engineers will float to the top. In the case of high-profile employers, a significant percentage of hires will be those who have trained themselves specifically to beat the hiring process at that company. Those people aren’t the absolute best software engineers.

esotericn9• 7 years ago

They are the best at obtaining positions at Google.

Which is what people talk about here.

No-one ever mentions the fact that say, you're barred from cracking out `git clone` and making the next Linux.

It's always commercial employment, which always has been and I am willing to bet always will be primarily a political field.

Obviously Google doesn't have the best devs - or at least I bloody well hope they don't - because they're mostly working on ad conversion shite. That excludes a ton of people I know right off the bat.

SonOfKyuss• 7 years ago

Those people aren’t the absolute best software engineers.

There’s no proof that they are but there’s also no proof that they aren’t

alain94040• 7 years ago

There is no proven method for sorting a pile of candidates such that the absolute best engineers will float to the top

[for the sake of argument] -- yes, there is a method, if you want to find out the top few best engineers. Look at their experience. Jeff Dean, Linus, John Carmak. I think my algorithm fulfills the letter of your search criteria by finding a few 10X engineers in an ocean of regular people.

Unfortunately, the 10X (or arguably, 100X in this case) engineers may not be enough or not be interested in the job opening you have.

Frost1x• 7 years ago

There's an impression that this problem is only at a few places like Google which is not the case. As someone recently browsing the market I've seen this process adopted rampantly and without reason or rationale.

So many companies I would consider mid-tier, lower, or not even technology companies have outsourced have adopted similar if not the same hiring models of FAANG or outsource hiring/recruiting/assessments that follow suit. It's an absolute mess.

zug_zug• 7 years ago

Meh. I don't buy it. I agree with the parent that it's usually people not getting hired being mad about it.

- "interviewing is broken" is a meaningless linkbait title. All you can really say is it's less efficient than it could be.

- In fact, interviewing in tech might be the best of any industry. Look how good we are at hiring minorities, people without college degrees, people who don't wear suits, people with verbal tics, or even tattoos. That wouldn't happen in investment banking.

- If your point IS that hiring could be better, then instead of winging, propose a fast and simpler and cost-effective alternative, and then try to give some hard evidence that the method you propose is better than whatever you're winging about (usually leet code).

bengale• 7 years ago

Odds are those places are going to be a nightmare to work at anyway.

mixmastamyk• 7 years ago

Yes, it’s endemic. A greeting card developer on app engine recently put me through the wringer. To what end? Could have done the job with one lobe tied behind my back.

sharadov2• 7 years ago

Exactly, every company here in the Bay area, however crappy their technology stack or the actual work you will be doing, will put you through a process akin to FAANG. As much as I love tech and have kept my skills up to date, this ridiculousness has left many truly creative engineers demoralized. I have reached a point where I want to leave tech altogether.

Retric2• 7 years ago

I have generally been rather disappointed with Google/FANG software developers. These companies generally though not always avoid the bottom 1/3 of the talent pool, but that’s about it.

Effectively they simply select for people willing to hack their hiring process, which also excludes most actually talented developers. Resulting in a few very talented people, and an overall average workforce.

This is also why most internal projects at these companies are about average for the industry and these companies focus so heavily on acquisitions. Consider the differences between iOS, Android, and Windows phones was not so much about software quality as much as business models.

esotericn9• 7 years ago

Wouldn't surprise me at all.

Fundamentally, companies do not hire for raw technical ability.

Would you hire Linus for your bog standard dev role? Of course not. He'd be bored in days.

You probably wouldn't want a supermodel as a life partner.

The whole thing is about selecting model employees. People who will rock the boat in the correct ways; need money, but are neither impoverished nor independent; are reliable; and so on and so forth.

It's not "hiring is broken". It's "you misunderstand what employment is".

tanilama• 7 years ago

Who they hired are good enough for the jobs.

Not everyone in FAANG are in charge of shaping the industry.

In fact, even with such hiring process, I would say FAANG problem is still having too many of such talented people but not enough internal growth so that they can't retain them.

ptasci67• 7 years ago

This is one of those statements that is too broad to be true. We can't wave a wand and just say developers at FAANG companies are better than the bottom 1/3 and no more.

You do have a point here which I do agree with which most of those companies would refer to as "culture fit". Agree with it or not, having an employee that gels with the team is a critical aspect to hire for. You could have 10 Jeff Deans and get nothing done if they refuse to work together.

A significant problem I see here is that we are trying to define "good" on a linear scale which makes no sense to me. Is candidate A better than candidate B based on 6 hours of interviews about the same topics or a single take home test. Even Madden breaks down a person into dozens of traits and uses that to compare people. Tech companies like to flaunt how data driven they are but why hasn't that made it into hiring. For the most part, these decisions are still made on personal feelings of the interviewers which...yeah, that's not going to be very consistent and reproducible.

metoprolol• 7 years ago

I’be noticed similar. I have some brilliant friends who don’t bother with FANG because the interview process is a pain. They are highly compensated at their startups, though, and have good reputations from their open source work anyway.

ravenstine• 7 years ago

You don't have to be the best at what you do, either. Being pretty good is just fine.

I'm glad that I'm not the best at what I do. I'd be working more hours, given too much responsibility, picking up the slack for people, subject to more meetings, etc. None of that is for me.

esotericn9• 7 years ago

Right.

One thing is for sure, and that's that I'm the best me, and you're the best you.

I spent most of a day yesterday trying to get openssh 8.0 working on Debian 2 (with 1998 era kernel, glibc, etc). Because I can.

Genuinely more fun than all the toys money can buy.

It didn't even work. Fuck.

gridlockd5• 7 years ago

I encourage new developers reading these sort of posts to just ignore the fluff and plug on. You'll get there. And if not? In five years you might want something else entirely.

No offense, but this isn't good advice. You just contradicted yourself within two sentences.

Here's the "true" version of this statement:

You may not actually "get there". You may or may not want something else entirely, after that potentially traumatizing experience. You also may be six figures in debt now, good luck!

In software development, we have this tendency to not take things seriously. Career choices are some of the most serious choices you make.

I'm afraid we're luring all these otherwise uninterested people into this career path by promising them lucrative and future-proof jobs. What eventually happens is that an oversupply of underqualified candidates flood the market. Meanwhile, other trades that aren't always in the headlines are starving for workers.

Despite what you may want to believe, many companies are afraid of hiring sub-par developers, because the narrative is that they will eventually ruin you. We can argue about how true that is, but that is irrelevant to the outcome. What matters is the perception.

esotericn9• 7 years ago

The point I am making is that a qualified software engineer will eventually figure out something to do with their life.

Not, however, if they stick dogmatically to the idea that it's Google or bust.

I'm not talking about a lucrative job; a middle class existence; a big fancy company; any of that shit. I'm saying that an intelligent human being needs to realise that the world is not necessarily set up for them and they either need to fit in, or carve their own path.

And about debt? Yeah, don't do that. The US college system looks like a racket to me.

paulsutter• 7 years ago

The key is to find the gems systematically overlooked by FANG, etc. It's actually great that so many companies use the same criteria because they all share the same blind spots.

AdrianB1• 7 years ago

Sometimes you need to pick at the top end. If you just hire from the middle and bottom, there will be nobody there to show the right direction and to organize what the less qualified people should do. It will rot. So you need at minimum a few very good people to keep the organization alive and well.

otras2• 7 years ago

One thing I’d add is that live coding exercises can vary widely in quality.

If you solve the problem, you’re scored highly. If you don’t, you’re scored poorly.

In my own opinion, this is a terrible way to look at these problems, though many people do use this metric. This is further emphasized by HackerRank-style exercises where you have to pass all test cases. This is robotic and not empathic at all.

A more fluid and dynamic approach that focuses on the candidate’s approach, ability to clarify, and problem solving, even if the correct answer isn’t reached, can still give valuable signals

Disclaimer: I work and give interviews at a large tech co that uses exercises.

jcims2• 7 years ago

I wonder if there is any value in having a few candidates do a group project. Would probably be a mess but might be informative, you could at least identify the bullies and dickheads pretty quickly.

kvonhorn• 7 years ago

I could imagine that this would be the worst way to evaluate candidates I've ever heard, especially if not everyone got hired. I think this would only be an appropriate evaluation metric if your end product were actually a reality TV show focusing on this process.

Maybe do it Survivor style, have 12 candidates/new grads start, give them the goal of producing an MVP CRUD app, and start voting people out of the scrum after a couple of days. Winner gets a 6 month contract to hire, 3 people have their careers ruined, and the rest bump around the valley for a few years before moving back to wherever the hell they came from. The memes that come out of this alone could make this show a valuable cultural contribution.

dredmorbius2• 7 years ago

There's an organisation that operates like this.

https://en.wikipedia.org/wiki/Recruit_training

akhilcacharya2• 7 years ago

This is a popular sentiment but it’s still false. A hiring committee isn’t going to pass you if you don’t finish the problem (ideally multiple problems) optimally.

otras2• 7 years ago

For a counter example, I know that I didn’t finish a problem but did make it through. I’m not sure such blanket statements apply.

mobjack• 7 years ago

It depends on the committee.

I am more looking into how a candidate thinks than if they get the problem correct.

It is more telling when someone is able to logically work through a problem they never seen before even if it isn't optimal or even correct.

I am more skeptical of those who blow through a hard problem getting the optimal solution right away. It likely means they memorized it or had lots of practice on such type of problems. I don't hold it against them, but often have to throw in some curve ball follow ups to see if they really know there stuff.

watwut3• 7 years ago

What is wrong approach and is good approach? I agree that ability to explain and clarify matter in many positions and are real thing. But I never understood what is meant by "approach".

adamredwoods2• 7 years ago

+1. The variation between companies is part of the problem, IMO. When a company gives me a coding test, I don't know what will happen next. I don't know if I devote my time to a coding test if it will result in either a pass/fail examination (meaning instant rejection, no follow up) or a live post-discussion to talk about my mistakes or methods.

I'm currently interviewing, and I have to say I've taken enough pass/fail coding tests to start to shy away from coding tests, especially if they don't tell me what to expect.

bentona• 7 years ago

I wonder if people describing hiring as "broken" have only experienced the process from one side. Hiring is a one of my favorite things to work on at my software engineering jobs, because it's a super-hard problem that is always available. It hasn't been "solved" and lots of people do it in ways that are obviously sub-optimal, but I don't think anyone knows how to do it optimally.

I think this is what TFA is getting at.

projektir2• 7 years ago

Being on the other side of the process has only convinced me more of how broken it is. There are lots of baseline errors, biases, and insufficient attention given to the process that are quite obvious but a lot of people either fail to see them or refuse to see them because they don't want to admit that their hiring process is not better than rolling dice.

As a basic example, in a lot of places you get very little advance warning that you're going to interview someone.

Test problems or assignments are often not tested or even looked at by existing employees, so often you don't even know that your current team would do well on them.

Sometimes interviews happen without any intention at all to hire the candidate (wtf).

drchewbacca• 7 years ago

Another related question is how would you evaluate the quality of hires? So you hire for a team of 5 people who complete 83% of the tasks you set for them that year.

How do you know if you hired well? Is this an excellent result or a terrible one? How do you know how well each of those 5 did and how well the team would have done with other people in the roles?

okaram• 7 years ago

What makes this even worse is that you have no info on false negatives ... How would the people you didn't hire would have done?

PaulHoule• 7 years ago

Wasn't that headline written by content marketers working for triplebyte? It is popular for medium articles and if you use it on the programming section of Reddit you will get downvoted into oblivion.

ddebernardy3• 7 years ago

The biggest issue isn't one mentioned in the article. No amount of hiring tricks and hacks will work around the fact that hardly anyone (including most managers and HR pros) gets trained on how to review a resume, conduct an interview, and evaluate a candidate.

humanrebar• 7 years ago

That presumes there is teachable wisdom and technique in that domain.

codingdave• 7 years ago

This does not ring true based on my experience. Where have you worked where you found this to be the case?

ddebernardy3• 7 years ago

Maybe you got luckier in your career than I have been or you've only ever worked for very large businesses. Once you've learned the types of questions that tend to work better you immediately notice when whoever is interviewing you isn't asking them. Interviewers who mostly ask these types of questions and go on to dig deep enough to understand your contributions and the rational behind them are few and far in between.

tidepod12• 7 years ago

I worked at one of the largest global consulting companies (and I have enough friends in the other major consulting companies to know it's the same in most of them).

I was a relatively junior person working there in my early-to-mid 20s. It was common practice for me and my peers to be asked to review resumes and filter them, as well as be an interviewer every few months. I never once received any kind of training on interviewing or resume review. Not even the 10-minute-cheesy-corporate-video kind of training. Hell, not even a quick 1-pager or chat on tips or things to look for. It was literally just "hey here's a stack of resumes, please filter them".

neogodless2• 7 years ago

I've never been trained on how to write, test or debug code. But I've gotten pretty good at it - you can self-train and learn from experience.

Of course, the difference is that the feedback loop is at least two to three orders of magnitude faster for writing code than for figuring out if you did a good job hiring.

tyscorp• 7 years ago

How can someone get this training outside of their job?

ddebernardy3• 7 years ago

There are a few excellent episodes on the topic over at Manager Tools.

(I'd be happy to train your team if you don't want to go through their archive.)

maxyazhbin• 7 years ago

awesome, right on!!!

graycat• 7 years ago

It's easy for a person in good health, never arrested, never bankrupt, good credit score, native born US citizen, world class Ph.D. with one of the very best backgrounds for analytics and machine learning, with peer-reviewed publications in applied math, mathematical statistics, and artificial intelligence, having recently written .NET code in 100,000 lines of typing for an ambitious Web site, code that appears to run as intended and be ready for production, and who has shipped very high quality code to high end customers to be 100% completely, utterly, totally, permanently unemployable for anything beyond minimum wage, literally.

That's just the way it is.

strikelaserclaw• 7 years ago

and you've met such a person?

lubesGordi3• 7 years ago

If they're 50+ and live in rural America, yeah good luck.

GoToRO3• 7 years ago

The simple truth is companies value loyalty above all else. If you are the best or not doesn't really matter. It matters that you can pass some simple tests but nothing else.

In the gig economy it's important to be able to show to your client how the final product looks like. I.e. a portfolio. They have money just for one run, one try. Risk aversion is high.

Companies that truly want the best and have a process to filter for the best are exceptions. Maybe less than one in a thousand.

m0zg• 7 years ago

Yep, it's easy. All you have to do is stop applying for jobs. Although .NET and machine learning typically don't go hand in hand, as does ML and "ambitious web site" experience. I'd have someone review your resume and make sure you're not trying to be all things to all people. That's a major red flag.

eternal_intern• 7 years ago

Why not list the pros/cons of each method and let the candidates choose their poison. Whichever metric they think they would be best at given their constraints.

Still requires work and a subjective estimation of candidate skill because you have to make a judgment across metrics instead of within one, but I mean, everybody wins in this case, right?

borramakot• 7 years ago

I like the idea of multiple tracks a lot, but I think you need to be hiring at sufficient scale that each track has a fairly high rate of interviews, which makes it hard to support tracks that aren't commonly chosen.

If you don't had that scale, uncommon tracks will be full of interviewers who are out of practice for your question, and poorly calibrated to evaluate the candidate.

Also, some companies might not want to allow any of these methods, since they each have their own tradeoffs/blind spots.

oneepic2• 7 years ago

This debate will keep happening for years to come, but everyone's just repeating the same talking points over and over. I have to sum up my thoughts like this:

I really don't think we're ever going to find a perfect hiring method. You will always have a nonzero chance of false positives and false negatives, and there will always be downsides that piss people off. So, pick a reliable hiring method(s) (talk about experience, solve whiteboard q's, do take-home projects, or whatever) and try to make it better over time. If you don't like it, you can switch to another method and start improving on that. Etc. But your method will always fail some good hires and pass some bad ones. It sucks, but we are still able to hire mostly good/trainable people, so we should stop worrying and move on.

I hypothesize that there are a lot more interviewees than interviewers getting involved in the debate. I only have to tell the former group to keep trying and stop complaining. If you're not sure why you're failing interviews, that's a solved problem -- just do mock interviews with your friends or on interviewing.io. But stop blaming the process for your own failures.

ChuckNorris892• 7 years ago

but we are still able to hire mostly good/trainable people

Wow, you're actually training people? Kudos to you, I haven't seen that in a looong time.

In my current area, everyone only looks for seniors or experienced devs. New grads without connections can suck it basically.

oneepic2• 7 years ago

At this point my team mostly hires juniors. We train them on whatever they don't know that they need to know here.

We hired a mostly self-taught engineer out of college a year ago (I started ~2mos ago). Had almost no idea about webdev, or C#/.Net, or web APIs, but we taught her on the job. I'm similar, since I had no experience with web APIs before joining but I had experience with C#.Net, Asp, etc.

AJ007• 7 years ago

We will see the debate go on as long as humans are working. The problem is hiring is reflexive. Hiring is a marketplace, not a static measurement. Human behavior changes in reaction to other human behavior.

If someone found a foolproof method of hiring once it become widely known, it would no longer foolproof. Either employers would all try to hire the same employees or employees would find out which signals mattered and tried to game them. This already occurs to some extent with the Ivy League hiring approach. The general “college degree” part has already been over-gamed to the extent it is meaningless.

What employers should be doing is measuring the long term success and failures from interviews and seeing if the interviewer even has an above random chance of selecting good employees. If it’s worse than random than the interviewer is probably just terrible at what they are doing.

This would also require the employer to agree on what makes a long term successful employee, something I’m not sure many people even agree on. At minimum, I’m presuming you couldn’t make a judgement on a hire in less than 5 years.

GoToRO3• 7 years ago

Well, none of the above. Anytime you try to gauge someone by counting, it's not going to work well. You need the best developer at your company, to do the hiring. Filtered by HR for personality and so on.

gridlockd5• 7 years ago

Your "best developer" probably doesn't want someone better than them on the job.

dymk2• 7 years ago

What a weirdly insulting straw man of a developer you set up. Many engineers including myself would be thrilled to have somebody else highly skilled around, and "selfish/vain" isn't the default in our industry.

neogodless2• 7 years ago

I consider myself an above average developer. In the right situation, I'd even strongly suggest that I can be a 10x developer. But there are so many things I either don't know or could massively improve upon. I joined a team where I feel like the majority of developers around me are at least as good as me or better, maybe much better.

I LOVE IT!

projektir2• 7 years ago

Only if your definition of "best developer" is extremely narrow, maybe, since a typical "best developer" would want someone around they could learn from, no? And why would this issue be more common among "best" developers over the, err, non-"best" developers.

*ample use of scare quotes because I found "different developers work well in different situations or best with certain people" to be more true than "there's this 'best' developer let's clone them".

GoToRO3• 7 years ago

If s/he is any good s/he will also be a nice human being. In any case, for that particular company it's their only good and cheap chance.

There is an alternative, use an agency. The problem with that is that companies will simply reject the proposed candidates without justification because hey, they are the customer.

alexandercrohde2• 7 years ago

For those of you not reading this article (appears to be most) - this is a META article:

1. Main thrust is that all the HN posts on this topic are stupid and formulaic

2. Argues that numerous the OTHER posts merely list the negatives for one method of interviewing A, and the positives for another method B.

3. Lists every method of interviewing, showing glaring problems and advantages in each of them. Obviating the need for the discussion ever happening again.

4. Asks for something akin to evidence if we are going to drive the discussion forward.

necovek2• 7 years ago

I've read it, and while it starts with a request for a double-blind study, it immediatelly moves on to listing a subset of interviewing techniques. It is by no means exhaustive.

If the focus was to be on evidence, it would provide a framework for such a study. It generally sounds pretty hard to do anything of the sort.

alexandercrohde2• 7 years ago

> I've read it, and while it starts with a request for a double-blind study, it immediately moves on to listing a subset of interviewing techniques.

Uh, what? It start by saying "I can’t keep track of the number of articles I’ve read about hiring in the past few years. Inevitably, they all follow the exact same format"

That point is true.

The question then becomes "Why does the community generate spammy articles without making any sincere attempt at intellectual progress toward a better system?"

And the answer is probably that it's not in any individual's self-interest. HN members want to whine about not getting hired by google, companies want to promote themselves, people like me want validation.

The only people who have any incentive/interest in objective hiring are companies that specialize in that purpose (e.g. hired, interviewing.io). But there's really no reason for them to divulge their secret sauce, and even if they did, people would probably only upvote it if it let them feel less insecure about getting rejected by google.

ebiester2• 7 years ago

This goes back to the idea that there is a "fungible" programmer that is universally substitutable between companies. In some companies, I am a highly valuable addition. In others, I am mediocre at best. I think of this like a sports team - a highly performing sports team both needs people of the highest skill and complementary role players that are the best at a valuable skill even if they aren't the best at every skill. It would be great if every team member was excellent at code craft, debugging, collaborating between teams, researching new third party solutions, and whipping up prototypes, but your team may not need all of those.

I don't like the term "culture fit" because it is a proxy for people who are already on the team, and often gets confused for "white, male, and likes to drink with coworkers." That said, I highly value "work style fit" and "team need." Are you running into code quality problems? Find someone who thinks about code quality. Do you need someone who can get a prototype to sales quickly to close a deal? That's a skill, and it's not a generalized skill.

All of the cases above can be valuable, but only contextually. Figure out what your team needs first, then craft your interview process around that.

(As for me? I have been in management for a while, but I am at my best in developing high functioning teams, collaborating between teams to solve larger problems, and crafting high quality solutions. I am not at my best in deep debugging sessions and quick prototyping. If it isn't my own startup, I might not be the ideal choice for employee 1-5. I may be the person you bring in when your team is expanding rapidly and you're running into scaling issues.)

streetcat1• 7 years ago

So if you are not good at coding/recent tech, how do you know if a given solution is high quality or not?

ebiester2• 7 years ago

I am good at coding. I am a good enough debugger to get through most cases. I am good enough at getting a prototype out. However, if you are looking for someone to sort out some deep and ugly multithreading issues, there are people who are better at it than me.

If you are running an agency trying to drum up work, there are people better than me.

If you have a codebase with no tests and everyone is afraid to touch it, you want me. If you have three teams that are trying to sort out a problem but nobody will dig in, talk with everyone, and sort out the technical issue, you want me. That’s the difference.

Now, as for determining high quality code without having that basis, I would start with Robert Martin’s book “clean code.” At the very least, it can teach the basics of understanding a code sample. However, it can be a difficult problem. I might think about a consultant to judge those and use behavioral interviews to judge the rest.

track_me_now2• 7 years ago

What about focus on direct referrals who have worked with a current employee? The highest signaling characteristic I've ever found is someone who was recommended by a former coworker; there's a transitive relationship that seems to capture both the technical skills and a comfortable fit.

I realize this doesn't scale to the rapid growth of some companies, but most of us need a more modest supply of talent vs. giant pools of people.

CalChris• 7 years ago

The article has a lot of good advice. However, hiring doesn't end with the offer letter. There's also on-boarding which is largely left to the manager and varies considerably. Perhaps the writer could do a sequel on on-boarding.

dahart6• 7 years ago

Anyone can glamorize and exaggerate the work they have done, and make it sound a lot more impressive than it actually was

My personal experience interviewing is that people cannot easily glamorize their past projects when pressed for details. It might be easy to make it look good on a resume, but hard in person during a discussion with follow up questions.

I think asking about past projects is a fantastic interview question, and it’s very easy to get a good sense of what they did, what they were trying to do, how much was their leadership versus others, how successful it was, how much effort it took. All you have to do is ask questions about it, and not take the resume item at face value.

Personally, I find the open ended nature of the past projects question to be a better predictor of future performance than almost everything else on that list.

username905• 7 years ago

Or they could just lie and tell you from the perspective of another dev on their team, or even combining the achievements from several of them at once. Of course most people wont lie a lot but this style heavily favors those who do so you will get a disproportionate amount of liars on your team.

dahart6• 7 years ago

I think your assumption is incorrect, based on my own experience. I’ve never hired a liar, and I’ve hired a lot of people. I have, however, declined to hire people who failed to answer follow up questions honestly or appeared to not be able to explain their success.

Anyone who wants a job knows it’s a bad idea to lie because you find out immediately once you hire someone whether they are lying, and it would be grounds for immediate firing. Also follow-up questions weed out lies & half-truths very quickly. You should try it, see how long you can answer probing questions about someone else’s experience. I agree that most people won’t lie, and what does happen is almost always not lying but just spin, trying to glamorize rather than outright fabricate. My experience is that people get honest about their glamorizing very quickly if I keep asking more questions.

wslh• 7 years ago

You can discover the lie asking very technical questions on how the solved some issue. They will answer at the greatest level of detail if they did it themselves.

smsm423• 7 years ago

That is a very dangerous gamble though because the next question would be "you did all that? How cool! Tell me more details!" and my experience shows that faking the details, unless you've done at least something very close to what you claim you did, is not very easy. And generic bullshit is rather easy to detect - usually you can see when the person is genuinely talking about something they did and are excited to share and when they're just stalling because they have no idea. Of course, once in a while you can get a bullshit artist of high caliber - but those very quickly reveal themselves when you ask them to actually do something.

lubesGordi3• 7 years ago

Yeah it's pretty easy to tell where a senior engineer is at if you're in the same domain as them. Just discussing projects really provides much more insight than leetcoding them to death. It's shocking to me how many places are leetcoding senior engineers before talking to them about their past work or discussing design. Is it because we want to have hiring automated? Is it because of discrimination? Why is the leetcode interview process so widely adopted?

closeparen• 7 years ago

Behavioral, system design, coding, and problem solving interviews are AND gated. It's not a question of one being more important, but which ordering optimizes the funnel and employee time. There are many more calendar slots belonging to tech ICs than to hiring managers; you can run a higher velocity pipeline if you start with a technical phone screen.

The coding interview itself is an immune system against the surprisingly large population of candidates who have long resumes and can talk a big game but not actually perform. (I didn't believe these people existed either, until I started doing phone screens).

It's also a way to recognize smart people who will do well with whatever they're given, even if they're underutilized or in a different domain at their current job. Tech companies are typically hiring more for this than for tech stack or business domain similarity.

coding123• 7 years ago

At one (large) company I worked at we hired the guy that basically invented one of the technologies at Sun behind one of the larger JSRs - like an entire standard API for one of the Java EE products (not going to say which) for an architect role. I have no idea why we hired him. He basically sat idle all the time asking what he was supposed to do. He randomly would make charts and show people. He was older, out of touch with most of the team, and just kinda present at every meeting with no specific task or role. He had advice here and there that most of the people at the table were already thinking through. I left before I found out what happened to him. Nice guy though.

Hiring might be broken for keeping out the best of the best, but as long as you work at a company that isn't afraid of firing/laying off, hiring isn't fully broken.

eropple• 7 years ago

as long as you work at a company that isn't afraid of firing/laying off, hiring isn't fully broken.

Yes, it is--it is just broken in a way that privileges the company over its employees. Firing somebody (absent flagrant abuse and the like) is a failure of management and leadership.

adamredwoods2• 7 years ago

I'm actively interviewing. I don't think hiring is broken, but I think some companies get lazy or even abuse it. If we get the abuses down, and require less of a time commitment (no 8 hour take-homes), I think there'd be less complaints.

The key takeaway is that rejection hurts emotionally. Programmers who care about coding, take the rejection personally. Less time commitment, less hurt.

jimbob45• 7 years ago

While hiring is broken, let's certainly not pretend it was in a workable state in the past. Let's further appreciate things we have now that we didn't in the past. Previously, if you wanted a job in another state, you'd have to move there and hope you got a job before your bank account ran dry. Now, you can safely apply for jobs while at your current job until you get something.

cbanek• 7 years ago

While hiring is inefficient and biased (some would say broken, which I won't disagree with), I think performance reviews are equally so. Companies don't really know how to evaluate performance well, and without bias. Many of these same problems exist in performance reviews:

Ask them for references, Do back-channel references

Asking people for feedback, peer review, 360 review, etc. This is somewhat effective, but if people can choose their own reviewers, they will of course get only the good info, same as for interviews. If anyone can submit feedback, you're likely to get people who don't like an employee to write stuff about how terrible that employee is, which might be exaggerated.

Take home projects, Audition for the role as a contractor, Ask them to describe their past projects, Ask for source code from significant projects, Pair programming on a “real” problem, Live Coding Exercises

All of these are meant to try to get real signal on how the person would perform their job. But even when people are employed on a team and you can observe them at any time, it's hard to quantify their performance. Do you look at their commit count? Bug count? Lines of code? Any metric has its weakness, and people game them.

Interviewing is a game of making a decision with incomplete information. I would say we aren't much better having a whole lot more information about how someone works, when trying to give an accurate performance review.

If we can't accurately judge performance of the people we should know, I think that proves we can't accurately judge performance of people we don't know.

clairity3• 7 years ago

hiring is really simple: you can straightforwardly filter out the obvious no's, but beyond that, it's a crapshoot.

basketball analogy time! (my favorite =) the NBA employs 450 of the best basketball players on the planet, and at any given time, the league is evaluating a few thousand more (out of hundreds of millions of basketball players, out of ~7.5 billion people worldwide). all the easy filtering is done. every year, the 60 most promising players are drafted. and because they're among the most promising, most of these 60 players should become regular NBA players. in practice, only 5-10 will do so in any given year, and you have no idea which ones it will be as they all look promising (e.g., laker kyle kuzma drafted 27th in 2017).

in short, once you get down to the 10-20 candidates you think will fit a given job, you might as well just draw a name out of a hat, work with them for 3-6 months, and re-evaluate. there really is no shortcut to this (not even for google).

smsm423• 7 years ago

Fortunately, for smaller companies there's another option - use personal networks to find candidates, the chances would be much better. For googles, they can just afford some misses, it costs but not something they couldn't stomach.

clairity3• 7 years ago

yes, that can improve the odds, but i've hired people through my network (as a founder and an employee), and good hires (those who add productivity & efficiency to the team) still often boils down to the idiosyncracies of the individual human relationships involved.

going back to basketball, no team has yet to sign 10x nba all-star carmelo anthony this year, and 8x all-star dwight howard only just signed with the lakers (on an unguaranteed minimum contract) because of a season-ending injury to demarcus cousins. both players are individually very talented, but are reputed to be hard to play with (thus lowering team productivity & efficiency).

dredmorbius2• 7 years ago

Pro sports is an interesting comparison, in that it has a very long-chain training and recruiting system, starting as young as age 5-10, and including sport leagues and/or school teams to refine talent. Though professional recruiters may not be looking at younger players, sports leagues and schools are quite conscious of talent.

Professional lifetimes are also frequently quite short. For gymnasts, competing life is virtually over by age of majority, for Americna football, a few years in pros is typical, though some careers last longer. Baseball, cricket, tennis, and golf are longer-lived exceptions.

I'm not saying this as a rabid sport ethusiast, and the transfers to technical recruiting may be limited, but it's at least an interesting system to consider.

Other uneven talent/fame domains are theatrical performance (acting, music), and, possibly, writing.

clairity3• 7 years ago

yes, mainly, i'm using the nba to show that even among folks who are constantly and publicly evaluated for ~10 years (the time from discovery to draft), you have ~10-20% chance of hiring the right player at the right time.

so then, why would one expect to be able to evaluate a candidate for a few hours and do better than that? if anything, professional (office) skills are harder to evaluate than athletic ones.

reasonable folks should expect only 10-20% of hires to be good fits, regardless of the skill or integrity of the hire.

hackbinary• 7 years ago

Probably. Everything else seems to broken as well, housing, education, healthcare, justice, and politics. So it seems perfectly rational to think that hiring is broken as well.

tylerFowler• 7 years ago

As most of those bullets point out, nearly all of these are good indicators for some people and bad for others based on what kind of person they are or what their environment might be. It seems like the ideal would be to allow candidates to choose what format they think would best showcase how they work? Choose-your-own-adventure style?

Assuming you had some way of making comparisons across these different formats (easier said than done, I'm sure) it seems like you would end up with "truer" signals. It also seems like you would get an extra signal based on what the interviewee chooses. For example someone who prefers live coding/pair programming sessions might be someone who leans on and thrives more in ultra-collaborative/brainstorm-ish settings. Whereas someone who prefers take home assignments maybe is more productive being able to sit on a problem and iterate, then collaborating after being able to articulate the specifics in a code review type setting. Neither are wrong, nor are they mutually exclusive within an organization but in terms of team placement or general "culture fit" (whatever that means) it seems like something that's useful to know ahead of time.

Of course you might also allow people to choose which route they think they can hack more but I think that problem is more of an implementation detail of any given method. Asking for a solution to find the perimeter of a group of pixels at a video streaming company is better than asking someone to invert a binary tree at virtually any company. Asking someone to build something real-ish with a hundred valid solutions is better than asking someone to implement a trie with a thin search interface on top. And so on.

bartread• 7 years ago

I thought I was going to be completely infuriated by this as I've seen just far too many articles about hiring recently.

However, it's worth a read because it does a good job of summarising the trade-offs inherent in most of the techniques I've seen used to hire engineers. I might have missed it, but it didn't talk about any kind of software design assessment, which I have used and seen used reasonably successfully.

There was, however, one observation that ticked me off under cons in the "Live Coding Exercises" section:

Very stressful. Many programmers can’t handle the stress of coding under the clock, with someone watching them

If this is you I'm going to give you some advice that, if you can swallow it, will prove very helpful...

Grow up.

Seriously: grow up. You are (or will be) highly paid, and are supposedly a professional. So learn to toughen up and handle the pressure.

Because I guarantee you this: you will grow in any job that is worth having. Sometimes that growth will be forced. Even when it's not, it can still be uncomfortable and stressful.

Why?

Because you're doing things you haven't had the chance to become comfortable with, or there's some external pressure: deadlines loom; a teammate is off sick; a horrific security flaw is discovered in your code, or in a library you use; some terrible bug makes it into production (this happens at even the best companies) and you need to hustle to fix it; politics happens, and you have to navigate through it.

In this line of work you cannot avoid stress. You can certainly make every effort to run an orderly software development process with great teams, regular releases, great feedback mechanisms, interesting work, and all the rest, to minimise chaos, but that doesn't get rid of the stress.

We're software developers. Our stock in trade is dealing with really hard problems. Sometimes those problems are technical, sometimes organisational, sometimes commercial, more often a blend of all three (along with other factors).

Guess what? Dealing with hard problems is stressful. Easy problems aren't stressful (although boredom is for many), but if you wanted easy you chose the wrong profession.

So buckle up. Because if you cannot handle an hour sitting down and working either with an interviewer or under their observation/guidance on a problem, how are you going to handle it on the job when it all kicks off (whatever "it all" happens to be on the occasion in question)?[1]

[1] This presupposes the interviewer isn't an asshole, and can be depended upon to behave like a grown-up. I have borne direct witness to, or heard report of, far too many interviews where the interviewer appears to be on a mission to prove they're smarter than the candidate. If you are unlucky enough to be interviewed by somebody who behaves like this you may be better off looking for a position elsewhere even if you're offered the job.

dkhenry• 7 years ago

Whenever I see anything about hiring I always think back to this article

https://techcrunch.com/2015/03/08/on-secretly-terrible-engin...

yellowapple• 7 years ago

I recently got thrown into interviewing a bunch of NetSuite developers (so lots of JS programming), and so far my strategy has boiled down to:

1. A verbal pop quiz about some reasonably-complex NetSuite-related programming topic/task (i.e. "on a high level, how would you go about implementing $FOO, given the constraints $BAR and $BAZ?")

2. Digging into past projects/experience and gleaning info on how involved the candidate was with those projects

3. If available, look at an existing programming portfolio / GitHub account / etc.

I feel like these three things tend to cover my bases, knowing full well that they're flawed assessments (but flawed in ways I can control and adjust/tweak as necessary).

beeblebr0x• 7 years ago

I've interviewed many candidates for cloud native architect positions. None could tell me what important tools/patterns like TLA+ or CQRS and none could discuss the concepts once explained. Instead of recreating the binary tree from an array of in-order, depth-first-traversed nodes, which is an extremely narrow minded test of someone's skills, I want them to describe how they build reliable distributed systems. LeetCode, HackerRank and the companies whose interview process gave rise to these sorts of services misunderstand the idea of software engineering.

9nGQluzmnq3M• 7 years ago

If you want somebody to describe how they build reliable distributed systems, then ask them to describe in detail how they would build one for a specific use case, instead of quizzing them on alphabet soup.

ltbarcly3• 7 years ago

The older I get and the longer I do stuff the more I realize that everything is broken and there's nothing you can do about it but try to do the things you are doing well, learn from people that you think are doing something well, and teach people where you have figured out how to do something well. None of these things are blanket rules you can read in a blog and then follow.

awesome_dude• 7 years ago

The problem isn't limited to engineering hires, ever bought a house and had to go look for a builder to check the house is in good nick? What about the lawyer you use for the conveyancing?

How about an accountant to do your taxes?

Further, how do you define who is the best? Someone who does a so-so job in a short amount of time? Someone who checks every possible decision branch, explicit or implicit? Someone who writes code in a clever way.

You're only ever going to see the skills you understand. Anything that you do not understand you will miss.

brooklyn_ashey2• 7 years ago

Why is it that no one questions the system in which these —at best, ridiculously obtuse—at worst, totally corrupt, often nepotistic— “interviews” reside? The whole “interview/audition” culture comes out of a kind of gladiator/Olympic ethos that pits "commoners" against one another for the amusement of the powerful, while solidifying the collective deception that keeps them in power. It’s a lever workers hand over willingly because the other mythology—the one in which their genius and hard work “earned” them their position—is an identity narrative they can’t survive the despair of corporate culture without. But haven’t the critical thinkers among us agreed that when the starting bootstraps are of different lengths, we can’t trust our notions of “merit-based” reward? Celebrities bribing their kids into college is but one of the more languid manifestations of the bankruptcy of this belief system. When we play along in this gerrymandered Miss America pagent—what now passes for job interviews in tech—we legitimize and endorse these so-called “measurements". We need to collectively refuse to participate, with some vehemence and volume. We must stop trying to make fairer versions of this fundamentally dishonest bullshit. There is no fair Three Card Monty; it’s a trick! Back in the day, the only folks who would play that game around 42nd St. were tourists or kids who’d just moved to the city. This interview process is the same; you can only pull it on the green, which is why it selects for the young and desperate. Hey! Young and Desperate! You are way smarter and better than this.

For those looking for actual data, like the post’s author who says as much, one could turn to the classical music “industry”. This audition process where “the best man wins” was exactly that for many, many years, until someone thought to put up a screen and down a carpeted walkway, and well, what do you know?...when the candidates were truly anonymous, women started winning. Here’s an article http://gap.hks.harvard.edu/orchestrating-impartiality-impact..., one of many on this study. So that trick was revealed, but ultimately, the idea that they would select the “best” players of orchestral excerpts resulted in them looking for players who rivaled computers in accuracy. Unfortunately, that isn’t really what one wants in an art. Anyone there has the accuracy required in spades. Accuracy beyond that is just meat compiling. It turns out that classical orchestras populated by this kind of person lack morale, creativity and vitality and don’t evolve with the culture, so these organizations have become culturally dead and are going bankrupt all over the country—this after their members were forced to let go of any real compensation and all dignity. The problem is that most organizations like these and tech companies are top-down. They are run like the military; their basic training programs are even called “boot camps”, and like boot camps, they won’t get you much. We need to take a look at the whole system, I’m afraid, or it will suffer a fate similar to music in this country, because that’s what happens here, eventually.

brooklyn_ashey2• 7 years ago

The thing is, I’m actually interested in why we, a community of engineers and tech people, aren’t genuinely interested in evolving the fundamental failures of our system. We might learn something from classical music’s failures which led to its musicians being mostly unable to continue to be professionals. They used this same organization building system we are using now and it led to a collapse of their entire industry. If we “peer review” our code, why don’t we “peer review” the way we build our companies and the way we bring new folks in. We mostly only pretend to care about diversity and we only care about innovation when we are comfortable. It would be great to hear about why we look to the individual interview process for faults it can’t really accept responsibility for. Don’t its fundamental failures lie in the greater system and by extension, the (even unconscious) intentions of the folks who designed it? Ibram Kendi (youngest winner of the National Book Award) recently wrote a book “How to be an Anti-racist”. In it, he details how the SAT was written and how it was specifically and consciously designed to be eugenicist. I’m not claiming that’s the case with interviews, but don’t you think we should consider better ways NOT to redline certain folks out of the hiring process?

nabdab• 7 years ago

With all the focus on broken hirering, I never quite head the employing side being like: “we thought this person was the perfect candidate but (s)he turned out to be rubbish.” So on that side of things it seems ok. Mostly the people who seem to think the system is broken are people who don’t get the positions they believe they are perfect fits for. But they have an extreme bias and don’t actually know the state of the competition that end up getting the position.

devxpy• 7 years ago

The "cons" part of this list is filled with how a practise doesn't work for X class of devs.

So, why not randomly pick 5 of these practices and simply tailor your process so it works well for a majority of candidates?

Something like pick your poison?

erikpukinskis• 7 years ago

I don’t get how “Look at what University they went to” becomes “Check if they went to Stanford”.

There are lots of good schools. If you got a BS in Computer Science from UIUC, that means something to me. That’s a good school and you got through it.

Same with jobs, why does “Look at their job history” mean “Check if they went to any big name tech companies”?

You look at the companies, look at what the company does, what the applicant said they did for them, and ask them questions about what that was like. It doesn’t really matter if it’s Google or it’s Pet Food Express, the important questions are the role and the work.

Hiring Is Broken?

Related Stories