Hiring Is Broken?(software.rajivprab.com)
software.rajivprab.com
Hiring Is Broken?
https://software.rajivprab.com/2019/07/27/hiring-is-broken-and-yours-is-too/
200 コメント
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?
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.
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.
> but not actually perform
You're trying to measure how they'll perform on your work before you hire them? That sounds like you're trying to get free work from them. (Just a note.. this is on the words you used)
> recognize smart people who will do well with whatever they're given,
How does a take home coding test that is limited on time, and their own time + stress indicate that they are in that category?
You're trying to measure how they'll perform on your work before you hire them? That sounds like you're trying to get free work from them. (Just a note.. this is on the words you used)
> recognize smart people who will do well with whatever they're given,
How does a take home coding test that is limited on time, and their own time + stress indicate that they are in that category?
> You’re trying to measure how they’ll perform on your work before you hire them? That sounds like you’re trying to get free work from them.
I wish the hyperbole about trying to get free work during an interview would just die already. Nobody is getting free work by interviewing applicants, interviews are costly to most companies, but necessary to grow the team.
Just because interviews take time and are difficult and scary doesn’t mean someone is taking advantage of you. Try to put yourself in the company’s shoes — they have to evaluate you one way or the other. How would you do it?
A time limited stress test is extremely effective at identifying certain kinds of performers. Obviously being able to solve problems fast is an indicator of a certain kind of smart. This doesn’t identify all smart people, and nobody claimed it did, that’s why a coding test is almost always one part of many in the interview process, and people routinely get hired when passing some parts without passing all the parts.
I wish the hyperbole about trying to get free work during an interview would just die already. Nobody is getting free work by interviewing applicants, interviews are costly to most companies, but necessary to grow the team.
Just because interviews take time and are difficult and scary doesn’t mean someone is taking advantage of you. Try to put yourself in the company’s shoes — they have to evaluate you one way or the other. How would you do it?
A time limited stress test is extremely effective at identifying certain kinds of performers. Obviously being able to solve problems fast is an indicator of a certain kind of smart. This doesn’t identify all smart people, and nobody claimed it did, that’s why a coding test is almost always one part of many in the interview process, and people routinely get hired when passing some parts without passing all the parts.
I consider it a failure of the company and interviewers if they need more than a few 1hr sessions to determine candidate suitability.
Can you name a single company that needs 'more than a few' 1 hr sessions ?
Accepted definition of 'few' is at least 3 and usually between 3-5
Most companies have 4 sessions : 1 HR phone, 1 tech phone, 1 tech onsite, 1 HR onsite.
But bigger companies (i.e. bigger salary) increase the 'tech onsite' up to 4. Some companies replace one of the tech phone/onsites with a take-home challenge.
If you want more money, you gotta beat the other 100 people who also want more money. Simple case of demand and supply.
Most companies have 4 sessions : 1 HR phone, 1 tech phone, 1 tech onsite, 1 HR onsite.
But bigger companies (i.e. bigger salary) increase the 'tech onsite' up to 4. Some companies replace one of the tech phone/onsites with a take-home challenge.
If you want more money, you gotta beat the other 100 people who also want more money. Simple case of demand and supply.
[deleted]
[deleted]
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.
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.
Provided you or the arbitrary interviewer have the technical background to evaluate the answers! I once had reason to view the resume of a former colleague who took all credit for a major project I implemented. This project involved parsing and a particular parser generator. He worked on it after I implemented it, but he claimed it all. And he was knowledgeable enough to back that claim up!
> And he was knowledgeable enough to back that claim up!
If he worked on it and could convincingly fake it, I - as a recruiter - wouldn't care too much if he embellishes a bit and claims he also did it from the start. Maybe he factually didn't, but if he's good enough to make me think he did, there's a decent chance he would be good enough to actually do it for me. Not a certainty, there's never certainty, but a good chance. Of course, given the choice, I'd prefer the one who actually created it, but one who worked on it and knows it well enough is not bad either.
If he worked on it and could convincingly fake it, I - as a recruiter - wouldn't care too much if he embellishes a bit and claims he also did it from the start. Maybe he factually didn't, but if he's good enough to make me think he did, there's a decent chance he would be good enough to actually do it for me. Not a certainty, there's never certainty, but a good chance. Of course, given the choice, I'd prefer the one who actually created it, but one who worked on it and knows it well enough is not bad either.
The point is the hiring method attracts people who are both not genuine , to admit that they just jumped in on an impressive project and insecure enough , that they think they should claim everything as their own ... It doesn't matter if they actually possess the technical skill as there might be behavioural issues between this person and the rest of the team.
Note that we aren't talking about people who can't code, we are talking about mediocre performers who know what they are doing but are still far from top talent. Knowing how to explain a coworkers thought process is not very hard when you have reviewed their design documents and been on every meeting.
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.
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.
> you find out immediately once you hire someone whether they are lying
Do you really believe this? Lets say we have a mediocre person on a team who tells the story of him being a star performer. How would you catch that? He went on the design meetings, he know why every decision was made, he has worked on the project for years. There is no way you would catch it, and the halo effect would likely mean that you still think he is doing decent work but that the environment might have made him a bit worse but you wouldn't believe that he lied.
Do you really believe this? Lets say we have a mediocre person on a team who tells the story of him being a star performer. How would you catch that? He went on the design meetings, he know why every decision was made, he has worked on the project for years. There is no way you would catch it, and the halo effect would likely mean that you still think he is doing decent work but that the environment might have made him a bit worse but you wouldn't believe that he lied.
> Do you really believe this?
Yes, absolutely. I’m not lying. :) Like I said, I have lots of experience with it. I’ve interviewed people who tried to inflate their contributions, and it’s easy to tell over the course of a 5-10 minute conversation.
> How would you catch that?
Easily, they would fail to be a star performer, and fail to match the abilities they advertised. You can’t lie your way into good programming.
However, it’s bigger than lie or not. Seasoned programmers have mature philosophies, and you can tell by talking to them. And honestly, I don’t mean this judgementally, but your question does sound like it comes from a lack of experience. You will find out what I’m talking about in time; big lies are not in the least bit easy to pull off, and almost nobody tries that kind of thing because the probability they’ll get caught and have serious consequences is very high. Being present in design meetings and knowing why decisions are made does not make you able to talk about it fluently.
BTW, while I believe this myself absolutely, I don’t know for absolute certainty that I’m right. So if it’s easy to do and the payoff is large then you should do it and write about it! If you could easily lie your way into a job, then it should be easy to work your way into one of those super high paying jobs, making robots or neural networks, and get away with it for years.
Yes, absolutely. I’m not lying. :) Like I said, I have lots of experience with it. I’ve interviewed people who tried to inflate their contributions, and it’s easy to tell over the course of a 5-10 minute conversation.
> How would you catch that?
Easily, they would fail to be a star performer, and fail to match the abilities they advertised. You can’t lie your way into good programming.
However, it’s bigger than lie or not. Seasoned programmers have mature philosophies, and you can tell by talking to them. And honestly, I don’t mean this judgementally, but your question does sound like it comes from a lack of experience. You will find out what I’m talking about in time; big lies are not in the least bit easy to pull off, and almost nobody tries that kind of thing because the probability they’ll get caught and have serious consequences is very high. Being present in design meetings and knowing why decisions are made does not make you able to talk about it fluently.
BTW, while I believe this myself absolutely, I don’t know for absolute certainty that I’m right. So if it’s easy to do and the payoff is large then you should do it and write about it! If you could easily lie your way into a job, then it should be easy to work your way into one of those super high paying jobs, making robots or neural networks, and get away with it for years.
> You can't lie your way into good programming.
Agreed. There's so much more that goes into programming than just knowing a programming language or two, so even if someone does know basic coding or has medium understanding of a former coworker's acxonolishments, there's so much more in the domain that (in my experience) liars, fakers, and overhypers are exposed very quickly after hiring. Granted, understanding this doesn't help weed them out before the fact, but still I think most interviewees know this and are wary of spinning their stories too far out of control.
Agreed. There's so much more that goes into programming than just knowing a programming language or two, so even if someone does know basic coding or has medium understanding of a former coworker's acxonolishments, there's so much more in the domain that (in my experience) liars, fakers, and overhypers are exposed very quickly after hiring. Granted, understanding this doesn't help weed them out before the fact, but still I think most interviewees know this and are wary of spinning their stories too far out of control.
Nuance comes from experiencing constraints from implementing the solution.
Eventually the liar runs out of those details when pressed.
Eventually the liar runs out of those details when pressed.
Yeah all you have to ask is questions like why did you use A instead of B? Did you run into any problems implementing that?
It doesn’t take long before people start stammering and deflecting if they’re full of shit.
It doesn’t take long before people start stammering and deflecting if they’re full of shit.
"people start stammering and deflecting if they’re full of shit. " - I think what your evaluating there is charisma.
It’s possible you are interviewing that one charismatic fraud, but what’s more likely is that you’re just interviewing the mediocre developer caught in a lie.
Or a introverted developer who's nervous and not very confident at interviews. Which is very likely.
I have yet to meet the first introverted developer that does not open up and become enthusiastic when asked to talk about one of his (personal) projects. I’ll admit they may exist though.
Why wouldn't a person be able to answer those questions? You were on the standups, you know whatever issues they had, you were on the design meetings, you know what alternatives were considered and why they weren't chosen. Being able to walk through someone else's thought process is a lot easier than doing the actual work.
The end result is that you will hire people for high level roles like tech leads or architect who are very mediocre at what they do since they sound like a star performer at the interview. All you need to get a good career in such an environment is just to job hop a lot and at every job you mostly try to gather impressive things people around you do in order to sound impressive in the next interview. I bet a no small fraction of CEO's went that route, and I think it is a pattern we should avoid since it is so easy to test actual coding skills in tech.
The end result is that you will hire people for high level roles like tech leads or architect who are very mediocre at what they do since they sound like a star performer at the interview. All you need to get a good career in such an environment is just to job hop a lot and at every job you mostly try to gather impressive things people around you do in order to sound impressive in the next interview. I bet a no small fraction of CEO's went that route, and I think it is a pattern we should avoid since it is so easy to test actual coding skills in tech.
You keep mentioning design meetings as a source of technical insight that a person can co-opt as their own expertise. If you steer your interview questions more towards things that are 'solo' in nature then you might have a better job of identifying people that have more software development experience.
An example of such a question could be ... can you tell me about a time that you tracked down a bug that you at first thought was not possible but later identified and found a solution for?
An example of such a question could be ... can you tell me about a time that you tracked down a bug that you at first thought was not possible but later identified and found a solution for?
> Why wouldn’t a person be able to answer those questions?
Why would they? You’re making assumptions. Being in standup doesn’t mean you understand so well you can talk about it. Knowing why good decisions were made and actively making good decisions are two completely separate things.
Do you think you’d be prepared to be the lead singer or guitar player for a band if you memorized every note of every song of your favorite band? Would it help if you listened to all their podcasts, read all their books, studied their history? Would it help if you were their roadie or even their manager or producer? The answer is no, being near them and witnessing their output does not equip you to mimic their creative process, or to even understand it. Same goes for programming.
> Being able to walk through someone else’s though process is a lot easier than doing the actual work.
I’d say that’s true, and is exactly why you’d catch a liar in the unlikely event they made it through the interview process.
> All you need to get a good career [...] is just to job hop a lot
Yeah, it’s so easy. So do it! You have to keep lying and continue to convince every single company. You’d have to avoid people ever finding out and/or avoid companies calling each other for references. This takes so much effort, it’s literally easier to go to grad school and become an amazing programmer. What is making you think a lot of people are doing all this lying? Are there people around you that you suspect are lying?
> I bet a no small fraction of CEO’s went that route, and I think it is a pattern we should avoid since it is so easy to test actual coding skills in tech.
Multiple enormous problems with that sentence. CEOs don’t need coding skills, they need organizational skills, sales skill, communication skills and a host of other things, none of which are writing code unless you’re in a startup. (And then CEO is a goofy term anyway.)
You’re speculating. If a huge number of CEOs are faking it, then it should be easily demonstrable, so find some evidence. When CEOs fake it, the result is the company goes out of business.
It turns out we do avoid this “pattern” because it’s not really a pattern, it by and large isn’t happening, and there are many forces preventing it from happening that you’re not acknowledging.
Last but not least, coding skills in tech aren’t the most important. They’re very important, but not the most important. Teamwork, communication, attitude, and goals are all more important than actual coding skills.
Why would they? You’re making assumptions. Being in standup doesn’t mean you understand so well you can talk about it. Knowing why good decisions were made and actively making good decisions are two completely separate things.
Do you think you’d be prepared to be the lead singer or guitar player for a band if you memorized every note of every song of your favorite band? Would it help if you listened to all their podcasts, read all their books, studied their history? Would it help if you were their roadie or even their manager or producer? The answer is no, being near them and witnessing their output does not equip you to mimic their creative process, or to even understand it. Same goes for programming.
> Being able to walk through someone else’s though process is a lot easier than doing the actual work.
I’d say that’s true, and is exactly why you’d catch a liar in the unlikely event they made it through the interview process.
> All you need to get a good career [...] is just to job hop a lot
Yeah, it’s so easy. So do it! You have to keep lying and continue to convince every single company. You’d have to avoid people ever finding out and/or avoid companies calling each other for references. This takes so much effort, it’s literally easier to go to grad school and become an amazing programmer. What is making you think a lot of people are doing all this lying? Are there people around you that you suspect are lying?
> I bet a no small fraction of CEO’s went that route, and I think it is a pattern we should avoid since it is so easy to test actual coding skills in tech.
Multiple enormous problems with that sentence. CEOs don’t need coding skills, they need organizational skills, sales skill, communication skills and a host of other things, none of which are writing code unless you’re in a startup. (And then CEO is a goofy term anyway.)
You’re speculating. If a huge number of CEOs are faking it, then it should be easily demonstrable, so find some evidence. When CEOs fake it, the result is the company goes out of business.
It turns out we do avoid this “pattern” because it’s not really a pattern, it by and large isn’t happening, and there are many forces preventing it from happening that you’re not acknowledging.
Last but not least, coding skills in tech aren’t the most important. They’re very important, but not the most important. Teamwork, communication, attitude, and goals are all more important than actual coding skills.
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.
Yeah... or I have been working on that cool project six months ago and by the time we just have this talk I had a 100 other things on my plate which are not that cool. Then maybe I want to change job because we got new boss that was stressing me out for 3 months and I gave up. So I am rusty on the details and I am also intimidated when you bring in 3 people to have talk about it.
I would say it is OK if it works for you but it still might be that you drop off some good guys. Because it is environment that creates good employees, and if someone was working for months or years in a bad environment, he can be perfectly capable of doing work, but not being confident and feeling good about talking about his last job.
I would say it is OK if it works for you but it still might be that you drop off some good guys. Because it is environment that creates good employees, and if someone was working for months or years in a bad environment, he can be perfectly capable of doing work, but not being confident and feeling good about talking about his last job.
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.
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.
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.
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.
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).
- "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).
^ These are some of the reasons why I start in this industry. I’m a minority who is self-taught and hates wearing suits/business-wear every day (also, it’s so damn cool go from having an idea to having it built and seeing it in the wild in the span of a few weeks to months).
One of my most popular HN posts [1] is about how the job search sucks so I empathize a lot. However, I have little interest in working for “top” companies.
[1]: https://news.ycombinator.com/item?id=16127697
[1]: https://blog.webb.page/2018/why-the-job-search-sucks
One of my most popular HN posts [1] is about how the job search sucks so I empathize a lot. However, I have little interest in working for “top” companies.
[1]: https://news.ycombinator.com/item?id=16127697
[1]: https://blog.webb.page/2018/why-the-job-search-sucks
This is a mindblowing response to me. To say "look at how good we are a hiring minorities" feels like it has to be an obvious troll.
We are extremely good at hiring minorities, so good in fact that we stopped calling Asians minorities.
Asians don't count as minorities. We privilege now!
> It's usually people not getting hired being mad about it.
Or it’s a bunch of very competent coders annoyed that they’re made to jump through hoops.
Or it’s a bunch of very competent coders annoyed that they’re made to jump through hoops.
People doing the hiring are complaining, not just the people failing to get hired.
> Look how good we are at hiring minorities
Wait, what? Are you talking about the software industry?
Wait, what? Are you talking about the software industry?
In terms of providing high paying jobs with good career progressions to minority groups that doesn't necessarily discriminate on the basis of prior education, credentials, background (or lack thereof), yeah, I'd say software engineering is pretty decent compared to many other industries.
Aye. I've never seen a software team in my country that were all natives. Software doesn't care where you're from, at least when you're writing it.
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.
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.
Odds are those places are going to be a nightmare to work at anyway.
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.
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.
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".
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".
Very good point. The best developer I ever worked with said to me one time "I'm thoroughly unemployable", meaning his skills, motivations and long term goals did not match what-so-ever with those of a employee developer.
He was a great resource but hiring him permanently would be a terrible mistake for all parties.
He was a great resource but hiring him permanently would be a terrible mistake for all parties.
I've worked with some like that, they're easily bored and will work well as tech-cofounders, the ones who can rewrite the entire code stack in a weekend.
Your last sentence is the bullseye. On the whole, companies like FAANG hire for employees that supply the bulk labor throughput they need in large quantities with overall low risk. Their interviewing process very deliberately selects for this.
> Would you hire Linus for your bog standard dev role? Of course not. He'd be bored in days.
I've often wondered if Rob Pike or Guido Van Rossum went through the same interview process at Google that we all hear stories about. I'd be very surprised if they did and my guess is, for them, it was much more of a negotiation of what they were going to work on and what their compensation was going to be.
I've often wondered if Rob Pike or Guido Van Rossum went through the same interview process at Google that we all hear stories about. I'd be very surprised if they did and my guess is, for them, it was much more of a negotiation of what they were going to work on and what their compensation was going to be.
I asked a recruiter there whether someone like that (like the creator of a popular programming language) would have to go through the normal new-grad-style whiteboard coding hazing gauntlet (phrased diplomatically) interview process that they were expecting me to. The recruiter said no. I decided not to interview, because it turns out the hazing wasn't something "everyone" had to do, and I just didn't rate decent treatment.
The next time a recruiter from there cold-contacted me, I asked again. IIRC, that one said a person could skip at most only the first part of the whiteboard coding hazing (phrased differently), if someone at Google could vouch for them, but that everyone had to do the second part of the hazing, before they could advance to the interviewing phase of professionals with mutual respect (phrased differently). I decided not to interview.
So long as their process comes off as one-sided, arrogant, and negging, the company doesn't seem like a place I'd want to work.
It's like you're meeting a first date in the line at a cafe, and they're physically attractive and rich, but they're rude to the barista -- bullet dodged, we're not together, and I'd like my coffee to-go, please.
The next time a recruiter from there cold-contacted me, I asked again. IIRC, that one said a person could skip at most only the first part of the whiteboard coding hazing (phrased differently), if someone at Google could vouch for them, but that everyone had to do the second part of the hazing, before they could advance to the interviewing phase of professionals with mutual respect (phrased differently). I decided not to interview.
So long as their process comes off as one-sided, arrogant, and negging, the company doesn't seem like a place I'd want to work.
It's like you're meeting a first date in the line at a cafe, and they're physically attractive and rich, but they're rude to the barista -- bullet dodged, we're not together, and I'd like my coffee to-go, please.
At this point in my career I won’t do coding tests or problems at home or over the phone. I’ve done my fair share of hiring and I’ve never needed to resort to such things.
Being asked to perform these tasks is actually a pretty good litmus test to filter out companies. Also, I expect a certain degree of deference given my resume shows a 25 year history of implementing and delivering systems.
Being asked to perform these tasks is actually a pretty good litmus test to filter out companies. Also, I expect a certain degree of deference given my resume shows a 25 year history of implementing and delivering systems.
I have about the same amount of professional experience, and have done lots of hiring and leading of teams. A few years ago I took a job that interviewed me with a coding test. (Which was only one of many phases of the interview). The coding test was quite fun, the company allowed the test in the language of my choice, and it was mostly about implementing rules for a game, and for bonus points, some A.I. to play the game. Not very long after taking the job, I was doing the interviewing and administering the coding tests to interviewees.
There were applicants with a decade or more of experience who, like you, expected some deference and were annoyed or offended, and complained about having to take a coding test. But they were applying for programming roles, not management. Those people didn’t get hired; negative attitudes are a red flag. In effect, this particular company likewise used them as a litmus test to filter out applicants unwilling (or unable) to demonstrate their advertised abilities.
Note especially how the coding test is actually being used to evaluate attitude and things other than coding skill. It’s not valid to assume that being asked to do a coding test implies that someone doesn’t believe you about your experience.
That said, resumes are very easy to fluff up with big sounding projects, so talking through past project details and demonstrating your abilities with a coding test should be par for the course if you want to change companies.
I actually agree and I don’t think coding projects are necessary for hiring, but I do think they’re useful, not bad, and I don’t give deference to anyone when I’m interviewing, no matter how accomplished. I look for people who are smart, willing to learn, excited to do the job, excited to interview for my company, and willing to try.
There were applicants with a decade or more of experience who, like you, expected some deference and were annoyed or offended, and complained about having to take a coding test. But they were applying for programming roles, not management. Those people didn’t get hired; negative attitudes are a red flag. In effect, this particular company likewise used them as a litmus test to filter out applicants unwilling (or unable) to demonstrate their advertised abilities.
Note especially how the coding test is actually being used to evaluate attitude and things other than coding skill. It’s not valid to assume that being asked to do a coding test implies that someone doesn’t believe you about your experience.
That said, resumes are very easy to fluff up with big sounding projects, so talking through past project details and demonstrating your abilities with a coding test should be par for the course if you want to change companies.
I actually agree and I don’t think coding projects are necessary for hiring, but I do think they’re useful, not bad, and I don’t give deference to anyone when I’m interviewing, no matter how accomplished. I look for people who are smart, willing to learn, excited to do the job, excited to interview for my company, and willing to try.
I don't expect deference. I expect an experienced developer to be able to tell -- from talking with me, and from looking at open source work, and from asking my references -- that we are peers.
I'm happy to have real technical discussions and sketch out things, but I've seen enough negging "coding interviews" administered by smug people, and it seems to have little-to-nothing to do with legitimately assessing competence.
I'd also like to have an opportunity to get a sense of the people from talking with them. The FAANG coding theatre performance that undergrads now drill for doesn't tell me much about the team's personality, competence, and working style -- all it tells me is that apparently they are willing to play along with that dysfunctional one-sided game.
I'm happy to have real technical discussions and sketch out things, but I've seen enough negging "coding interviews" administered by smug people, and it seems to have little-to-nothing to do with legitimately assessing competence.
I'd also like to have an opportunity to get a sense of the people from talking with them. The FAANG coding theatre performance that undergrads now drill for doesn't tell me much about the team's personality, competence, and working style -- all it tells me is that apparently they are willing to play along with that dysfunctional one-sided game.
How much hiring and interviewing have you done? I've seen countless resumes with 25 years of stated glorious achievements, and they couldn't write a for loop.
I've done quite a bit and have never had any difficulty sniffing out "gloss" with just a few minutes of questions over the phone using the applicant's resume as a starting point for the conversation.
When you're focused on system implementation, delivery and maintenance you can pick one of the past projects listed and start probing. It's not hard to quickly get a picture of what the candidate did and didn't do on the project and whether or not they're blowing smoke.
When you're focused on system implementation, delivery and maintenance you can pick one of the past projects listed and start probing. It's not hard to quickly get a picture of what the candidate did and didn't do on the project and whether or not they're blowing smoke.
Exactly. Of course, we do have to be a bit careful how we ask about past projects, to avoid the appearance of being exposed to IP, but it's doable. We can also just talk about hypothetical design problems (and they can learn about us based on the questions we ask, even if we're not doing a collaborative exercise). But no whiteboard CS101 coding negging.
I read a book by Eric Schmidt, can't remember the name. I remember reading him say that "the way interviews are conducted right now, if I wasn't in Google and was interviewed then I'd probably get rejected."
Almost certainly not, indeed.
But then, if you ran a business, that's almost precisely what you'd do. It's completely rational. The hoi polloi need to be filtered aggressively, most companies need to select for hunger, etc.
By contrast, you might as well give a big name an honorary position if you can afford it. If they do useful stuff - bonus. Hell, if I owned a company the size of Google, I'd give Guido some money just because I could.
But then, if you ran a business, that's almost precisely what you'd do. It's completely rational. The hoi polloi need to be filtered aggressively, most companies need to select for hunger, etc.
By contrast, you might as well give a big name an honorary position if you can afford it. If they do useful stuff - bonus. Hell, if I owned a company the size of Google, I'd give Guido some money just because I could.
Agreed but it leads me to wonder if they couldn’t do a lot more hiring using this mode. The mode based on reputation, voucher and referral; you know, the way almost every other field does it.
> Would you hire Linus for your bog standard dev role?
The question is incorrect. By hiring Linus you eliminate the need for 5 bog standard dev roles. Bog standard dev roles is not a requirement. It's what you end up with if you hire mediocre people.
The question is incorrect. By hiring Linus you eliminate the need for 5 bog standard dev roles. Bog standard dev roles is not a requirement. It's what you end up with if you hire mediocre people.
I doubt linus is any good at modern web dev. Might take him a while to learn and will probably never enjoy it.
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.
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.
That’s a fair point, but in my experience professionalism trumps what is generally considered cultural fit. Also, while I agree ranking people is going to be team and role specific, much of what makes people effective is fairly universal.
Personally, I would place technical skill at around 50% of what makes up a talented software developer. Effective communication, ability and willingness to work with others, flexibly, work ethic, attention to detail, prioritization, etc are all important. But, I have found these things really tend to go together.
Personally, I would place technical skill at around 50% of what makes up a talented software developer. Effective communication, ability and willingness to work with others, flexibly, work ethic, attention to detail, prioritization, etc are all important. But, I have found these things really tend to go together.
I think this is an important point: they tend to go together because, imho, they are necessary qualities for someone who will "get the job done" (as opposed to someone who will get stuck with no iption to dig themselves out).
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.
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.
[deleted]
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.
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.
Many of these "hiring is broken in tech" posts are like you said: moaning or a remarkable lack of self-awareness.
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.
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.
The tech industry, and Silicon Valley in particular, has long pretended to be an ultra-rational meritocracy. Some people buy into the rhetoric, and get bitterly disappointed when proven wrong. If the industry didn’t feed the myth, perhaps people would have less of an emotional reaction.
I say this without meaning to be offensive, but surely it's blindingly obvious that this isn't the case?
For all of the reasons I stated above?
I think you'd have to be severely mentally deficient in order to think that commercial software development operates in some sort of strict high score board fashion.
OSS development I think is significantly closer if you allow for the sampling bias that only certain groups have enough time to contribute.
For all of the reasons I stated above?
I think you'd have to be severely mentally deficient in order to think that commercial software development operates in some sort of strict high score board fashion.
OSS development I think is significantly closer if you allow for the sampling bias that only certain groups have enough time to contribute.
I think the power of myth and marketing are far more powerful than you expect, especially those who pivot into tech via boot camps and such as an attempt to find a better field to work in. People flocking into tech seem to buy into the concept that the meritocracy will reward them. And unrelated to hiring, tech CEOs are often still regarded as ultra-rational geniuses despite some blowback.
Majority of OSS development is paid for. It is not done by unpaid volunteers feeding themselves by something else.
Some of it is like that, but not much.
As much as I like open source, there is a lot of myth making around it too.
________
Second whether obvious or not, people argued that we meritocracy on these forums here for years. And some still do. At meritocracy peek, Github had even that meritocracy carpet or whatever it was.
Some of it is like that, but not much.
As much as I like open source, there is a lot of myth making around it too.
________
Second whether obvious or not, people argued that we meritocracy on these forums here for years. And some still do. At meritocracy peek, Github had even that meritocracy carpet or whatever it was.
I doubt that. The super-star projects with millions of users sure, but the majority of OSS is probably in the long tail of tiny one-man shows, Github projects with five stars, etc.
The small one person projects with 5 stars have nothing to do with "operating in some sort of strict high score board fashion" or meritocratic evaluation of anything.
Anyway, FOSS makes yearly polls about these topics. It is biased toward more involved projects, but again I don't think someone's one weekend demo is what is talked about here.
Anyway, FOSS makes yearly polls about these topics. It is biased toward more involved projects, but again I don't think someone's one weekend demo is what is talked about here.
>> 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.
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.
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.
no other pays that well != the other markets don't pay well
Perhaps you're speaking from the perspective of dev jobs in Europe, or just outside the US, but even in the midwest where the only "tech" companies are really just the largest commerce/healthcare/financial institutions, dev jobs still pay $75,000+ for entry-level positions. Ignoring the fact that cost of living and taxes are way lower in the midwest than they are on the coasts, it's still a fact that with just a bachelors degree computer science opens up a plethora of opportunities.
If the price to pay is grinding Leetcode problems for a few weeks that's a pretty small price to pay. Honestly.
Perhaps you're speaking from the perspective of dev jobs in Europe, or just outside the US, but even in the midwest where the only "tech" companies are really just the largest commerce/healthcare/financial institutions, dev jobs still pay $75,000+ for entry-level positions. Ignoring the fact that cost of living and taxes are way lower in the midwest than they are on the coasts, it's still a fact that with just a bachelors degree computer science opens up a plethora of opportunities.
If the price to pay is grinding Leetcode problems for a few weeks that's a pretty small price to pay. Honestly.
Not GP, but in Europe definitely nobody starts at 75k, not even in the big metro areas with high COL.
And the commerce/healthcare/financial enterprises that you mentioned are really picky and don't even care about leetcode, they filter based on resume prestige like law firms. Without connections, having attended a prestigious University or experience at other fancy companies you ain't getting your foot in the door regardless of your leetcode level.
If you've only been coding at mom & pop corner shops, you'll be doing that for a long time as most big enetrprises you mentioned won't even look at your resume.
And the commerce/healthcare/financial enterprises that you mentioned are really picky and don't even care about leetcode, they filter based on resume prestige like law firms. Without connections, having attended a prestigious University or experience at other fancy companies you ain't getting your foot in the door regardless of your leetcode level.
If you've only been coding at mom & pop corner shops, you'll be doing that for a long time as most big enetrprises you mentioned won't even look at your resume.
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.
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.
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.
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.
> 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
There’s no proof that they are but there’s also no proof that they aren’t
CVE list for android would be a good place to start ;)
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.
[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.
[deleted]
> 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.
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.
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.
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.
> The point I am making is that a qualified software engineer will eventually figure out something to do with their life.
Fair enough. A true scotsman will never put sugar on his porridge.
> 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.
Indeed, a human being must either do one thing, or, failing that, do another thing.
There's at least two ways of reading what you are saying. In the one reading, you are giving questionable encouragement. In the other reading, what you are saying is a tautology.
I assumed the former, but apparently you meant the latter. You were right all along.
Fair enough. A true scotsman will never put sugar on his porridge.
> 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.
Indeed, a human being must either do one thing, or, failing that, do another thing.
There's at least two ways of reading what you are saying. In the one reading, you are giving questionable encouragement. In the other reading, what you are saying is a tautology.
I assumed the former, but apparently you meant the latter. You were right all along.
The better analogy would be - if you have no oats, stop trying to make porridge. Or go and get some oats.
It is indeed tautological.
Which is my primary complaint about the prevalent attitude displayed in these hiring posts.
Porridge isn't going to change its' recipe for you.
It is indeed tautological.
Which is my primary complaint about the prevalent attitude displayed in these hiring posts.
Porridge isn't going to change its' recipe for you.
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.
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.
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.
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.
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.
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.
[deleted]
[deleted]
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.)
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.)
So if you are not good at coding/recent tech, how do you know if a given solution is high quality or not?
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.
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.
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.
> 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.
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.
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.
> 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.
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.
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.
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.
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.
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.
[deleted]
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.
> 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.
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.
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.
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.
There's an organisation that operates like this.
https://en.wikipedia.org/wiki/Recruit_training
https://en.wikipedia.org/wiki/Recruit_training
+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.
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.
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".
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.
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.
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.
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.
Your experience is highly atypical
Without a flawless performance it’s unlikely for most people to get offers.
Without a flawless performance it’s unlikely for most people to get offers.
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.
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.
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.
This does not ring true based on my experience. Where have you worked where you found this to be the case?
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".
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".
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.
How can someone get this training outside of their job?
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.)
(I'd be happy to train your team if you don't want to go through their archive.)
That presumes there is teachable wisdom and technique in that domain.
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?
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?
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?
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.
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.
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.
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.
>> 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.
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.
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.
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.
> 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.
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.
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.
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.
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.
I think this is what TFA is getting at.
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).
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).
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.
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.
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.
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.
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.
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).
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).
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.
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.
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.
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.
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.
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).
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).
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).
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).
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.
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.
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.
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.
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.
Whats the general consensus on take home projects? How helpful are they?
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).
- 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.
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.
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.
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:
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.
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)?
- 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.
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.
What about having a discussion on how the candidate would solve a given take home?
You could check if she would think of the required parts. For instance, would she think of unit tests? If she wouldn’t mention tests, you could ask „How would you ensure that your program works as expected?“
Thus, solving the take home theoretically.
You could check if she would think of the required parts. For instance, would she think of unit tests? If she wouldn’t mention tests, you could ask „How would you ensure that your program works as expected?“
Thus, solving the take home theoretically.
This is a great use of the take home. It's a good interview-starter to get conversation moving.
> Would you be able to give an example of how limited in scope you're talking about?
At a previous company we gave a problem that boiled down to the following:
The instructions only specified one requirement. Something like:
For your code to be formatted and for you to configure a linter are two separate goals. For JS (were standards vary greatly from org to org) I don't mind as long as there is a consistent formatting. Any IDE or editor has a format function that I would be happy to see used.
> If what you ask is of sufficient complexity
I hope that it is evident that this task was designed to not be complex for anyone but the most junior of developer.
> 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
This sort of thing is exactly what I am interested in with this homework. You were given requirements and you reached for a set of tools that you thought were helpful to you as an engineer despite them not being required.
> 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.
I don't hold a lack of documentation or extra items against a candidate. That is made clear early on. There are tools that are very simple to setup or things you can do that would make it obvious to me that you know what you're doing.
You don't need a linter to format your code. You don't need a unit test framework to write unit tests:
Internal company standards make linters, testing, documentation, etc a "teachable" skill. I don't care if you do that on your own time because when you come to work for the company you will be doing what the company thinks is a good idea for it's source code.
(edit, forgot the "multiple" rule)
At a previous company we gave a problem that boiled down to the following:
1. Read a config file that contains a list of "Rules"
2. Each rule contains a name, an ID, a comparison, and a value.
3. Read a json array of numbers from a file.
4. Apply the rules you read to the array from the file
{
id: 1,
type: greater-than,
value: 10,
name: Number was passed threshold,
}
The instructions only specified one requirement. Something like:
Provide a method for our engineers to run your program
via command line:
`./<your program name> <rules-file> <data-file>
For your code to be formatted and for you to configure a linter are two separate goals. For JS (were standards vary greatly from org to org) I don't mind as long as there is a consistent formatting. Any IDE or editor has a format function that I would be happy to see used.
> If what you ask is of sufficient complexity
I hope that it is evident that this task was designed to not be complex for anyone but the most junior of developer.
> 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
This sort of thing is exactly what I am interested in with this homework. You were given requirements and you reached for a set of tools that you thought were helpful to you as an engineer despite them not being required.
> 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.
I don't hold a lack of documentation or extra items against a candidate. That is made clear early on. There are tools that are very simple to setup or things you can do that would make it obvious to me that you know what you're doing.
You don't need a linter to format your code. You don't need a unit test framework to write unit tests:
const apply = require('./submission').apply;
const tests = [
{rules: [], data: [], output: []}
];
tests.forEach(function (test) {
const output = apply(test.rules, test.data);
if (output != test.output) {
console.log("Failure");
}
});
1. Code is obviously not working
2. Code doesn't handle my sample data
3. Code doesn't handle an obvious edge case (no data, for example)
4. Code doesn't follow the one requirement (./<program> <config> <data>)
Internal company standards make linters, testing, documentation, etc a "teachable" skill. I don't care if you do that on your own time because when you come to work for the company you will be doing what the company thinks is a good idea for it's source code.
(edit, forgot the "multiple" rule)
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.
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.
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.
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.
I think the scenario you describe sucks for all kinds of reasons, but it doesn't have to be like that. If the coding challenge is for an early stage screen, you should be looking at about 30mins worth of work. If it's more in-depth than that, it's not like the hiring company will have time to properly review them all at a screening stage anyway.
I'd support more complicated take home skill assessment tests later on in the recruitment pipeline, as long as they add real value for both the candidate and the company, and they're only given to well qualified and screened candidates. I'd also be concerned at a twelve hour test - that sounds like something very poorly scoped.
I'd support more complicated take home skill assessment tests later on in the recruitment pipeline, as long as they add real value for both the candidate and the company, and they're only given to well qualified and screened candidates. I'd also be concerned at a twelve hour test - that sounds like something very poorly scoped.
> 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!)
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!)
I think they're talking about the initial 'phone screen' portion of the interview.
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.
They'd be more useful in a buyer's market.
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.
What you'll end up with is people who are desperate for your job, which may or may not be a great sign.
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
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
I'd bill the company asking for them a minimum of eight hours at contracting rates. My time isn't free.
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.
Otherwise it's a total waste of everyone's time.
Extra points if you have a tweed vest and a smoking pipe.
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.
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.
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.
The key takeaway is that rejection hurts emotionally. Programmers who care about coding, take the rejection personally. Less time commitment, less hurt.
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?
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?
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.
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.
Whenever I see anything about hiring I always think back to this article
https://techcrunch.com/2015/03/08/on-secretly-terrible-engin...
https://techcrunch.com/2015/03/08/on-secretly-terrible-engin...
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?
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?
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.
Your "best developer" probably doesn't want someone better than them on the job.
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!
I LOVE IT!
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.
> Many engineers including myself would be thrilled to have somebody else highly skilled around, and "selfish/vain" isn't the default in our industry.
What else are you supposed to say about yourself or anyone else?
I'm not talking about the best developers in general, I'm talking about "the best developer in the team". The "golden child". Do you sincerely believe they're thrilled about giving up that special status to the new hire?
Yes, people are that petty, they're not necessarily that self-aware though.
What else are you supposed to say about yourself or anyone else?
I'm not talking about the best developers in general, I'm talking about "the best developer in the team". The "golden child". Do you sincerely believe they're thrilled about giving up that special status to the new hire?
Yes, people are that petty, they're not necessarily that self-aware though.
You can construct any number of hypothetical evils that might plague your team; I don't really see why you'd let that shape your perception of engineers when you hardly ever run across people like that though.
Most people are fine, and if you run into a toxicity then go take care of it like an adult and talk to your manager/HR/whatever.
Most people are fine, and if you run into a toxicity then go take care of it like an adult and talk to your manager/HR/whatever.
I'm not talking about "my team", I'm talking about people. Status preservation is one of the most basic behaviors in higher animals. It's not "toxic" or otherwise special in any way.
If you follow the advice of the GP, you are setting up a conflict of interest. I'm not ruling out that the "best developer" in some teams is of such noble disposition that they will always hire someone better than themselves. It's not what you can expect though, so don't set yourself up for failure.
If you follow the advice of the GP, you are setting up a conflict of interest. I'm not ruling out that the "best developer" in some teams is of such noble disposition that they will always hire someone better than themselves. It's not what you can expect though, so don't set yourself up for failure.
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".
*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".
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.
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.
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.
[deleted]
[deleted]
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.
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.
awesome, right on!!!
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.
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.
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?
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.
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.
That's just the way it is.
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.
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.
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.
and you've met such a person?
If they're 50+ and live in rural America, yeah good luck.
Good luck finding a job creating artisanal fruit preserves at a research station in Antarctica
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.