> Anyone can glamorize and exaggerate the work they have done, and make it sound a lot more impressive than it actually was
My personal experience interviewing is that people cannot easily glamorize their past projects when pressed for details. It might be easy to make it look good on a resume, but hard in person during a discussion with follow up questions.
I think asking about past projects is a fantastic interview question, and it’s very easy to get a good sense of what they did, what they were trying to do, how much was their leadership versus others, how successful it was, how much effort it took. All you have to do is ask questions about it, and not take the resume item at face value.
Personally, I find the open ended nature of the past projects question to be a better predictor of future performance than almost everything else on that list.
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?
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.)
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.
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.
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.
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.
+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.
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.
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.
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?
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.
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.
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.
> 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.
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.
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.
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).
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.
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.
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).
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.
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.
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).
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.
[+] [-] dahart|6 years ago|reply
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.
[+] [-] lubesGordi|6 years ago|reply
[+] [-] username90|6 years ago|reply
[+] [-] golemiprague|6 years ago|reply
[deleted]
[+] [-] esotericn|6 years ago|reply
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.
[+] [-] Frost1x|6 years ago|reply
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.
[+] [-] Retric|6 years ago|reply
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.
[+] [-] o10449366|6 years ago|reply
Many of these "hiring is broken in tech" posts are like you said: moaning or a remarkable lack of self-awareness.
[+] [-] maxaf|6 years ago|reply
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.
[+] [-] gridlockd|6 years ago|reply
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.
[+] [-] ravenstine|6 years ago|reply
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.
[+] [-] paulsutter|6 years ago|reply
[+] [-] AdrianB1|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] ebiester|6 years ago|reply
I don't like the term "culture fit" because it is a proxy for people who are already on the team, and often gets confused for "white, male, and likes to drink with coworkers." That said, I highly value "work style fit" and "team need." Are you running into code quality problems? Find someone who thinks about code quality. Do you need someone who can get a prototype to sales quickly to close a deal? That's a skill, and it's not a generalized skill.
All of the cases above can be valuable, but only contextually. Figure out what your team needs first, then craft your interview process around that.
(As for me? I have been in management for a while, but I am at my best in developing high functioning teams, collaborating between teams to solve larger problems, and crafting high quality solutions. I am not at my best in deep debugging sessions and quick prototyping. If it isn't my own startup, I might not be the ideal choice for employee 1-5. I may be the person you bring in when your team is expanding rapidly and you're running into scaling issues.)
[+] [-] streetcat1|6 years ago|reply
[+] [-] cbanek|6 years ago|reply
> 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.
[+] [-] oneepic|6 years ago|reply
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.
[+] [-] ChuckNorris89|6 years ago|reply
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.
[+] [-] otras|6 years ago|reply
> 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.
[+] [-] jcims|6 years ago|reply
[+] [-] adamredwoods|6 years ago|reply
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.
[+] [-] watwut|6 years ago|reply
[+] [-] akhilcacharya|6 years ago|reply
[+] [-] ddebernardy|6 years ago|reply
[+] [-] neogodless|6 years ago|reply
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.
[+] [-] codingdave|6 years ago|reply
[+] [-] tyscorp|6 years ago|reply
[+] [-] humanrebar|6 years ago|reply
[+] [-] drchewbacca|6 years ago|reply
How do you know if you hired well? Is this an excellent result or a terrible one? How do you know how well each of those 5 did and how well the team would have done with other people in the roles?
[+] [-] okaram|6 years ago|reply
[+] [-] alexandercrohde|6 years ago|reply
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.
[+] [-] necovek|6 years ago|reply
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.
[+] [-] coding123|6 years ago|reply
Hiring might be broken for keeping out the best of the best, but as long as you work at a company that isn't afraid of firing/laying off, hiring isn't fully broken.
[+] [-] eropple|6 years ago|reply
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.
[+] [-] erikpukinskis|6 years ago|reply
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.
[+] [-] bentona|6 years ago|reply
I think this is what TFA is getting at.
[+] [-] projektir|6 years ago|reply
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).
[+] [-] track_me_now|6 years ago|reply
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.
[+] [-] tylerFowler|6 years ago|reply
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.
[+] [-] ltbarcly3|6 years ago|reply
[+] [-] clairity|6 years ago|reply
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).
[+] [-] dredmorbius|6 years ago|reply
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.
[+] [-] smsm42|6 years ago|reply
[+] [-] yellowapple|6 years ago|reply
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).
[+] [-] CalChris|6 years ago|reply
[+] [-] beeblebr0x|6 years ago|reply
[+] [-] 9nGQluzmnq3M|6 years ago|reply
[+] [-] awesome_dude|6 years ago|reply
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.