My platonic ideal for how engineering hiring should work(blog.alinelerner.com)
blog.alinelerner.com
My platonic ideal for how engineering hiring should work
http://blog.alinelerner.com/ive-been-an-engineer-and-a-recruiter-hiring-is-broken-heres-why-and-heres-what-it-should-be-like-instead/
303 comments
Construction and trades takes that approach. It’s a mixed bag. I would say implicit job insecurity removes a lot of potentially good employees from the applicant pool. People who value stability and support families tend to be reliable, and some of them won’t work for someone who has a reputation for firing everyone as soon as things get slow or if they have an off day.
I think my industry (civil engineers) is a bit easier to hire for because credentialing weeds out people who are completely out of their depth, and lying about qualifications can get you in real trouble. Managers can assume you’re basically competent and can focus on hiring people with decent personality and a good reputation. Some of my software friends use brain-teasers to screen candidates, and it comes off as a bit silly to me.
I think my industry (civil engineers) is a bit easier to hire for because credentialing weeds out people who are completely out of their depth, and lying about qualifications can get you in real trouble. Managers can assume you’re basically competent and can focus on hiring people with decent personality and a good reputation. Some of my software friends use brain-teasers to screen candidates, and it comes off as a bit silly to me.
I think my industry (civil engineers) is a bit easier to hire for because credentialing weeds out people who are completely out of their depth, and lying about qualifications can get you in real trouble. Managers can assume you’re basically competent and can focus on hiring people with decent personality and a good reputation. Some of my software friends use brain-teasers to screen candidates, and it comes off as a bit silly to me.
Pretty much the case for every non-Software Engineering discipline.
But then again, people in the tech field will vehemently defend the system - because it's one of the very, very few fields where you don't need a college degree, can go on and "grind leetcode" for months, and land a six-figure job.
And it is because of that, that tech companies are making their recruitment process bordering the absurd. They're simply deadly afraid to vet frauds, that have "gamed" the system.
So in short - tech companies would rather let 10 decent candidates slip by, if it means they can block 1 fraud.
I've been to many engineering interviews, outside tech, and it is not even remotely the same process.
Pretty much the case for every non-Software Engineering discipline.
But then again, people in the tech field will vehemently defend the system - because it's one of the very, very few fields where you don't need a college degree, can go on and "grind leetcode" for months, and land a six-figure job.
And it is because of that, that tech companies are making their recruitment process bordering the absurd. They're simply deadly afraid to vet frauds, that have "gamed" the system.
So in short - tech companies would rather let 10 decent candidates slip by, if it means they can block 1 fraud.
I've been to many engineering interviews, outside tech, and it is not even remotely the same process.
That fear may be true for candidates without experience and/or university degree. But why is it still present for candidates with lots of experience and education? In other words, if other technical/engineering disciplines can manage without this absurd hiring process, then why can't IT field (leaving aside the candidates without experience/higher education)?
Universities are terrible at teaching programming/software engineering. Many also suck at teaching computer science. There's no incentives in academia to be good at teaching, and many lecturers only care about their research.
There are arguments here and on the blog post that the industry doesn't have credentials. We do have credentials, it's the CS degree, but universities suck at issuing them so we don't rely on them much. Sometimes not at all.
The people saying, hey, why can't we be like civil engineering are thus perhaps not sounding as re-assuring as they hope: why would universities be more trustworthy at teaching civil engineering than other kinds of engineering? The problems are incentive related. Ultimately the software industry is highly egalitarian and a bad university experience can't hurt your career permanently, like it could in most other fields.
There are arguments here and on the blog post that the industry doesn't have credentials. We do have credentials, it's the CS degree, but universities suck at issuing them so we don't rely on them much. Sometimes not at all.
The people saying, hey, why can't we be like civil engineering are thus perhaps not sounding as re-assuring as they hope: why would universities be more trustworthy at teaching civil engineering than other kinds of engineering? The problems are incentive related. Ultimately the software industry is highly egalitarian and a bad university experience can't hurt your career permanently, like it could in most other fields.
When I say “engineer” in disciplines other than software, I mean somebody with a professional license. You can only get that by passing exams and having a combination of experience, education and recommendations to pass a state board. It’s much harder and riskier to fake that than to make up experience on a resume or make a blog to appear like a subject matter expert. Unless you know the candidate personally, it can take a lot of effort to uncover a carefully crafted lie. Plus, recognizing quality work in software isn’t even a solved problem, to my understanding.
Other engineering disciplines hire engineers who don’t have a PE all the time. There are more engineering disciplines where taking the PE exam is the minority than the other way around.
Of course they hire non-PEs. You can’t get a license without years (at least 4) of experience first. Most consultancies I know of would not hire anyone who couldn’t pass the FE, though.
My point is that there are plenty of electrical engineers, computer engineers etc... who never take the FE or PE exam.
Funny you should mention that. At my college (Cal Poly) I had fraternity brothers who were Civil Engineering majors. They would look up to me because I had a natural ease with computers. But in the end, I watched them sweat their way through classes that would have wasted me.
This the engineering corollary of "The grass is always greener". For engineers it's "The other engineering disciplines are always harder"!
Probably because most people choose to study what comes easy to them.
I think the key is finding an intuitive way to grasp the subject matter, and then it doesn't feel like such a grind.
If material like this had been available 20 years ago it would have made a huge difference.
https://youtu.be/spUNpyF58BY
If material like this had been available 20 years ago it would have made a huge difference.
https://youtu.be/spUNpyF58BY
Which is another way of saying that the "advanced" subjects (vector calculus, multivariable calculus, fourier transforms) really aren't that bad if you're prepared to put the work in.
Many engineering fields are ones were being studious and knowledgeable can give you a solid career. Software development has a lot more upside potential for the flexibly creative and the lucky.
I feel this is less and less true for Frontend Development which is constantly evolving and you need to put in some serious effort to stay up to date.
If you can do both, I highly recommend it. Programming abilities can multiply your productivity in another field several times.
> Given this, why not hire lightly and fire lightly?
Because any company that adopts such an approach will never be able to recruit anybody who wants to work in a stable environment with a consistent set of smart people who aren't in constant fear that they will be fired the next day.
Because any company that adopts such an approach will never be able to recruit anybody who wants to work in a stable environment with a consistent set of smart people who aren't in constant fear that they will be fired the next day.
When you know you have a job for the next n years at least, you also tend to put more effort into efficient processes. When you have to wonder every other month if you will still be there a lot will be just quick and dirty ad hoc solutions.
It is still not easy to find good people, but the truth is: HR are not the best people to decide who is. If you have good people already and they don't try to build an empire, they will select good people. The danger there is only that they will select people that are too much like themselves or they will select the worse candidate because they fear about their own standing etc.
It is still not easy to find good people, but the truth is: HR are not the best people to decide who is. If you have good people already and they don't try to build an empire, they will select good people. The danger there is only that they will select people that are too much like themselves or they will select the worse candidate because they fear about their own standing etc.
More accurately: such an environment requires paying a premium to compensate for the decreased job security. (As with any market, employees expect to be compensated for their higher risk with higher returns.)
Netflix, for example, and Amazon (to some extent) have gotten away with this model but the vast majority of companies are simply unwilling to pay top of market.
Netflix, for example, and Amazon (to some extent) have gotten away with this model but the vast majority of companies are simply unwilling to pay top of market.
Additionally, in many markets there's no such thing as 'firing lightly'. Here in Scandinavia firing people requires a significant amount of work on the part of the manager and HR.
That's what probationary periods are for.
In Germany new employees usually have a probation period of 3 months, during which companies can pretty much fire them at will if they don't perform as expected.
I think that's almost always enough time to assess whether someone is a good fit for long term employment.
You should fire lightly early, and fire hard if late.
Where I live you have a month when starting were you can be fired with 2 weeks let-go period, after which it takes 3 months or more.
I think you should have an intensive monitoring/evaluation in the first month, and fire lightly if you think there is a mismatch. After you have determined an employee fits you, if they stop fitting you try to figure out why, help them to fit again (are they the kind who gets bored, needs new challenges?, do they have problems at home? If you found someone who fits I think it is more efficient to make them fit again then try to find someone else who fits). I believe this is the way to go even in areas where you do not have the rules about the dismissal period that you have here.
Where I live you have a month when starting were you can be fired with 2 weeks let-go period, after which it takes 3 months or more.
I think you should have an intensive monitoring/evaluation in the first month, and fire lightly if you think there is a mismatch. After you have determined an employee fits you, if they stop fitting you try to figure out why, help them to fit again (are they the kind who gets bored, needs new challenges?, do they have problems at home? If you found someone who fits I think it is more efficient to make them fit again then try to find someone else who fits). I believe this is the way to go even in areas where you do not have the rules about the dismissal period that you have here.
[deleted]
Also, no one deals with technical debt if they don't stay long enough to suffer consequences of compromises, so the quality will decline over time.
Yeah, exactly... depends a lot on who is doing the firing and why too.
I suppose if ALL companies did that then there might be some sort of fluid equilibrium state where most companies had some mix of mostly competent engineers who chose to work there for positive individual choice/reasons. But in a more winner-take-all world where the "best" need to hire the "best", because that means second tier companies get the rejects and therefore will fail to compete and the chosen few get success and riches? Set the bar incredibly high and forget fairness. (also an extreme for purpose of conversation, just on the other end of the spectrum)
I suppose if ALL companies did that then there might be some sort of fluid equilibrium state where most companies had some mix of mostly competent engineers who chose to work there for positive individual choice/reasons. But in a more winner-take-all world where the "best" need to hire the "best", because that means second tier companies get the rejects and therefore will fail to compete and the chosen few get success and riches? Set the bar incredibly high and forget fairness. (also an extreme for purpose of conversation, just on the other end of the spectrum)
> There is no meaningful data that any hiring process--good or bad--improves the outcome of a hire. If there were, everyone would be using it.
I can say with confidence that certain resume features are incredibly strong predictors of interview performance (at least in the related measures, in the field and/or team I'm working in). I'm not HR, but your statement seems to also deny the possibility of this empirical observation.
> Given this, why not hire lightly and fire lightly?
Because it would be a complete dick move to have someone relocate (possibly involving change of country) and then fire them 2 weeks later? That's not even looking at the formal, bureaucratic or training overhead, or any of the other factors in this industry that make hiring and firing a bit more complicated than handing someone (and later taking away) a hardhat and a shovel.
I can say with confidence that certain resume features are incredibly strong predictors of interview performance (at least in the related measures, in the field and/or team I'm working in). I'm not HR, but your statement seems to also deny the possibility of this empirical observation.
> Given this, why not hire lightly and fire lightly?
Because it would be a complete dick move to have someone relocate (possibly involving change of country) and then fire them 2 weeks later? That's not even looking at the formal, bureaucratic or training overhead, or any of the other factors in this industry that make hiring and firing a bit more complicated than handing someone (and later taking away) a hardhat and a shovel.
[deleted]
Can you share what those resume features tend to look like?
Disclaimer: This is for a quite particular set of positions, and it's not in the US (so I have no reference on US GPAs). The EU supply/demand situation is also different from the US, so your FAANG mileage may vary.
Here are a few (at a level of detail that I'm comfortable sharing):
- Outstanding (in either direction) performance in certain subjects in school is a very strong predictor.
- Cover letters are mostly noise, but incoherent, overbearing or careless ones don't go very far. Lack of curiosity and interest is also a negative predictor (but these are of course easily feigned).
- Relevant extracurricular engagement and/or industrial experience begets more well-rounded engineers.
Let me be clear though that we consider applications on more than these factors. These are just predictors, and sometimes they are wrong. I have interviewed actuaries that couldn't calculate dice roll probabilities, C++ programmers that were confused by the class keyword and C# programmers that hadn't heard of virtual.
Here are a few (at a level of detail that I'm comfortable sharing):
- Outstanding (in either direction) performance in certain subjects in school is a very strong predictor.
- Cover letters are mostly noise, but incoherent, overbearing or careless ones don't go very far. Lack of curiosity and interest is also a negative predictor (but these are of course easily feigned).
- Relevant extracurricular engagement and/or industrial experience begets more well-rounded engineers.
Let me be clear though that we consider applications on more than these factors. These are just predictors, and sometimes they are wrong. I have interviewed actuaries that couldn't calculate dice roll probabilities, C++ programmers that were confused by the class keyword and C# programmers that hadn't heard of virtual.
Do you hire experienced people too? I someone has 35 years, does it makes sense to judge them on school results and extracurricular engagement?
These are people who were in workforce 10+ years.
These are people who were in workforce 10+ years.
You are correct to observe that what I listed is primarily relevant to people who have less experience. While prevalent, that's not exclusively the demographic of our applications, and of course the weight of these factors is reduced for someone who has been in the workforce for longer. But they remain good predictors nonetheless.
I'll add a few more I've noticed over time.
Certifications are a strong negative predictor. Someone who turns up with a lot of corporate certifications is unlikely to do well when asked difficult questions.
People who have only ever worked in low grade or low tier banks tend to do poorly. There are a few exceptions. GS has good technologists. Most big investment banks have a few programmers (older ones usually) who have solid experience - but who are unlikely to put any creative effort in and may have a "here's why it can't be done" attitude. May not matter for some roles.
People who list a very large number of short roles tend to do poorly.
People who give a list of projects in their resume experience for which they only assert they were part of the group that delivered it, without concrete claims of tech leadership, often do poorly - generally it indicates a "hiding amongst the crowd" problem in which someone is a poor performer and attempts to hide lack of any actual achievement by reference to group projects.
People who list obscure programming languages as a skill do relatively well, people who list obscure products as a skill do relatively poorly.
Certifications are a strong negative predictor. Someone who turns up with a lot of corporate certifications is unlikely to do well when asked difficult questions.
People who have only ever worked in low grade or low tier banks tend to do poorly. There are a few exceptions. GS has good technologists. Most big investment banks have a few programmers (older ones usually) who have solid experience - but who are unlikely to put any creative effort in and may have a "here's why it can't be done" attitude. May not matter for some roles.
People who list a very large number of short roles tend to do poorly.
People who give a list of projects in their resume experience for which they only assert they were part of the group that delivered it, without concrete claims of tech leadership, often do poorly - generally it indicates a "hiding amongst the crowd" problem in which someone is a poor performer and attempts to hide lack of any actual achievement by reference to group projects.
People who list obscure programming languages as a skill do relatively well, people who list obscure products as a skill do relatively poorly.
"C# programmers that hadn't heard of virtual"
No offense, but that is a very silly thing to consider "foundational" in 2020. The heavy, all encompassing use of inheritance patterns these days is much less prevalent than 10 years ago, even in the C# community.
No offense, but that is a very silly thing to consider "foundational" in 2020. The heavy, all encompassing use of inheritance patterns these days is much less prevalent than 10 years ago, even in the C# community.
Extremely silly, I got a C# job recently after I went about 7 years without touching C#. I forgot virtual existed until my first day when I had to look it up. I would have failed the "what's virtual?" question, yet I am very good at my job (just got a big raise).
> I can say with confidence that certain resume features are incredibly strong predictors of interview performance
But what about actual job performance?
But what about actual job performance?
See above.
Does interview performance have anything to do with job performance though?
In light of this particular team having been very successful at recruiting (i.e. extending offers based on interviews) and retaining people that succeed at the challenges they face for the better part of a decade: Yes.
But again, I'm not claiming this to be universal. Just that it's possible.
But again, I'm not claiming this to be universal. Just that it's possible.
> it would be a complete dick move to have someone relocate (possibly involving change of country) and then fire them 2 weeks later
This. I hold a slightly lower bar (meaning more willing to take a chance) on someone who is unemployed than if they're working now. Worst case if I take someone unemployed, hire them "light", and they don't work out is they're back where they already were, whereas if someone quits their job to come work here and gets fired, they're worse off than they were before.
This. I hold a slightly lower bar (meaning more willing to take a chance) on someone who is unemployed than if they're working now. Worst case if I take someone unemployed, hire them "light", and they don't work out is they're back where they already were, whereas if someone quits their job to come work here and gets fired, they're worse off than they were before.
> There is no meaningful data that any hiring process--good or bad--improves the outcome of a hire. If there were, everyone would be using it.
No, it's just the companies using it keep that data to themselves. Their hiring process is then a competitive advantage.
No, it's just the companies using it keep that data to themselves. Their hiring process is then a competitive advantage.
Very insightful. Indeed, I would.
Ah yes, a claim that can never be disproven, because any evidence produced would just show the company is not an example covered by the claim.
But I do know some companies who have a competitive advantage in the tech market, and their hiring is not great.
But I do know some companies who have a competitive advantage in the tech market, and their hiring is not great.
It has the same amount of evidence as all these "hiring is broken [for the most profitable and transformative industry in all of human history]" posts.
If hiring in tech is broken, then all of hiring is broken, whether it's fast food cashiers or aerospace engineers. Can you seriously claim that any of those have better hiring practices? From personal experience, I can say they are far worse.
If hiring in tech is broken, then all of hiring is broken, whether it's fast food cashiers or aerospace engineers. Can you seriously claim that any of those have better hiring practices? From personal experience, I can say they are far worse.
That's not the ideal response if you actually wanted to defend your claim about the internal data and special competitive advantage rather than just abandoning the claim.
Seriously, I would say that the competitive advantage of a company comes primarily from its product and the vision and competence of the company leadership. You can't just hire your way to success without that foundation. Bad leadership can destroy the greatest employees.
The company founders almost always come together in a very informal manner, and often the early employees do too. And that's the basis of the company. It has nothing whatsoever to do with some special snowflake data-driven formal hiring process.
Indeed, I would argue that once a company becomes very large and successful, they become bloated and bad at pretty much everything, including hiring. At that point they have to get better by acquiring other companies, not by hiring through their standard bureaucratic processes. The competitive advantage of giant corporations is the ability to swallow other companies whole.
Seriously, I would say that the competitive advantage of a company comes primarily from its product and the vision and competence of the company leadership. You can't just hire your way to success without that foundation. Bad leadership can destroy the greatest employees.
The company founders almost always come together in a very informal manner, and often the early employees do too. And that's the basis of the company. It has nothing whatsoever to do with some special snowflake data-driven formal hiring process.
Indeed, I would argue that once a company becomes very large and successful, they become bloated and bad at pretty much everything, including hiring. At that point they have to get better by acquiring other companies, not by hiring through their standard bureaucratic processes. The competitive advantage of giant corporations is the ability to swallow other companies whole.
Those companies my must have ex employees by now. And no one has spilled the beans?
At least for startups, engineerng hiring can definitely be a competitive advantage. (4x startup founder here).
Google basically admitted that GPA and where you went to school don't matter and do not correlate with job performance. And yet here we are still optimizing on the Ivy League. It'd be a safe wager that algorithm whiteboard interviews don't either except that they screen out folks who don't pass the interview. So because everyone has that baseline, that baseline is by definition meaningless. The other side of the coin is that performance management is also just as bad.
Work results are only sensible measure for the work performance. Easy hire and fire is one solution. Also a short trial period at the start of the work agreement should show if results happen or not (fg. 4-6 months).
Yes, because those two things are related.
I don't know if it was ever made public, I think I heard this story via backchannels. But Google did a research project at some point to discover why GPA/interview performance in general did not seem to correlate with post-hiring job performance. The project was never allowed to reach full completion because the direction their data and investigation was going looked like this:
"Our hiring process does not correlate with post-hiring job performance because we have a large and measurable bias in interviews in favour of Ivy League candidates and women."
In other words, GPA didn't correlate with job performance for Google because it was a confounding variable: they were selecting the sample for top tier universities (which select on GPA) at hiring time, but not when it came to promo reviews (which had a different process and anyway, less rhetorical ideology involved than hiring, at least at that time).
I don't know if it was ever made public, I think I heard this story via backchannels. But Google did a research project at some point to discover why GPA/interview performance in general did not seem to correlate with post-hiring job performance. The project was never allowed to reach full completion because the direction their data and investigation was going looked like this:
"Our hiring process does not correlate with post-hiring job performance because we have a large and measurable bias in interviews in favour of Ivy League candidates and women."
In other words, GPA didn't correlate with job performance for Google because it was a confounding variable: they were selecting the sample for top tier universities (which select on GPA) at hiring time, but not when it came to promo reviews (which had a different process and anyway, less rhetorical ideology involved than hiring, at least at that time).
It’s worth reading the source here:
https://www.nytimes.com/2013/06/20/business/in-head-hunting-...
https://www.nytimes.com/2013/06/20/business/in-head-hunting-...
> There is no meaningful data that any hiring process--good or bad--improves the outcome of a hire.
I don't have stats but anecdotally, hiring by personal reference seems by far the most effective way to hire.
> Given this, why not hire lightly and fire lightly?
Because it's a huge financial and organisational burden on the hirer and an even huger (sometimes existential if you live in the U.S. due to health insurance but that's a whole nother rant) burden on the hiree.
I don't have stats but anecdotally, hiring by personal reference seems by far the most effective way to hire.
> Given this, why not hire lightly and fire lightly?
Because it's a huge financial and organisational burden on the hirer and an even huger (sometimes existential if you live in the U.S. due to health insurance but that's a whole nother rant) burden on the hiree.
To add to this, as a senior employee, bringing someone junior up to speed to the point where they can make actual contributions is a big consumer of time typically. Less so for employees who come in at medium rank but even then there is a hand holding period as the new person gets used to the company culture.
In a sufficiently large company you could have a specialized onboarding team, but you’d need to be careful that the specialized team doesn’t get isolated from the technical culture and needs of the rest of the company
In a sufficiently large company you could have a specialized onboarding team, but you’d need to be careful that the specialized team doesn’t get isolated from the technical culture and needs of the rest of the company
>Because it's a huge financial
It shouldn't be. From my experience, the financial cost that comes from increasing the number of people you fire after a few weeks is less than what companies spend furiously guarding against making a bad hire.
>and organisational burden on the hirer
There's no reason this needs to be the case.
It shouldn't be. From my experience, the financial cost that comes from increasing the number of people you fire after a few weeks is less than what companies spend furiously guarding against making a bad hire.
>and organisational burden on the hirer
There's no reason this needs to be the case.
If there was no meaningful data then a random hiring process would be optimal. This is obviously not the case.
It's not totally obvious to me that random hiring would be worse. Most people can do most jobs, given the right experience and opportunity.
>It's not totally obvious to me that random hiring would be worse
Does this have some implied conditions I'm missing? Because to me it seems absolutely obvious that filtering for people who have experience/a degree will vastly improve your outcome over true random hiring.
Does this have some implied conditions I'm missing? Because to me it seems absolutely obvious that filtering for people who have experience/a degree will vastly improve your outcome over true random hiring.
A lot of things seem obvious but aren't actually true. Plenty of people with degree and experience coasted on nothing, or have personalities so abrasive as to make working with them all but impossible. Disappointingly I have poor experience with degrees actually instilling any sense of diligence, or even research capabilities, thus making them questionable even when recruiting for fields such as R&D, where it should be truly an obvious choice. At least a retrained nurse has some basic curiosity and a critical eye, though it's a bit of a shame, what with the nursing staff shortage.
And, also personally, I've had great experience with people who migrated from absolutely unrelated fields (e.g. several people who retrained - within same company - from support into software development). Similarly I had great experience with fresh interns turning out to be brilliant theory people.
And, also personally, I've had great experience with people who migrated from absolutely unrelated fields (e.g. several people who retrained - within same company - from support into software development). Similarly I had great experience with fresh interns turning out to be brilliant theory people.
Right. It logically follows that random applying would be a good strategy: selecting randomly from top-paying jobs, you would reply to job offers for e.g. software engineer, brain surgeon, architect or hedge fund manager, to increase the chances of being randomly hired.
That is effectively how I got my last 2 jobs in software engineering. Picking a few keywords and spamming out your resume seems the only way to match the equivalent efforts from recruiters.
>That is effectively how I got my last 2 jobs in software engineering
Are you saying that you had no qualifications at all before? Because that's what they're saying, just applying for any high-paying job, even if you don't have the requirements.
Are you saying that you had no qualifications at all before? Because that's what they're saying, just applying for any high-paying job, even if you don't have the requirements.
I mean my anecdata to serve as a realistic example of the hyperbolic concept of just wildly applying anywhere at random.
In both cases, I was switching industries (from ASIC design to IoT cloud software to data analytics). So, I arguably had some qualifications and arguably none at all.
In both cases, I was switching industries (from ASIC design to IoT cloud software to data analytics). So, I arguably had some qualifications and arguably none at all.
Can you tell how fast did you acclimate and how did your employer look at this?
I propose the Monte Carlo hiring process: heads means the applicant is hired without question, otherwise they get to go through the regular interview routine.
I like it. Exploration vs exploitation is used in a lot of optimization algorithms (and in reinforcement learning) meaning that there's a low probability that the agent just decides to make a random choice instead of making a greedy choice.
That would ensure also diversity of staff. Very good idea.
Why do you think that? Isn't it rather sexist/racist to argue this?
The candidate stream is itself not "diverse" (assuming you are using the normal meaning of the word of lots of women+racial minorities). Simply randomly making offers wouldn't alter the outcomes because those people aren't being de-selected by skills testing to begin with - unless you believe the 'diverse' candidates are less skilled programmers.
The candidate stream is itself not "diverse" (assuming you are using the normal meaning of the word of lots of women+racial minorities). Simply randomly making offers wouldn't alter the outcomes because those people aren't being de-selected by skills testing to begin with - unless you believe the 'diverse' candidates are less skilled programmers.
> This is obviously not the case.
Isn't it? While machine intervention might be able to weed out the most obvious low-quality candidates, I don't think there's any strong evidence that most hiring processes actually select the strongest hires - just that they, out of the set of candidates that progress to the point of human intervention (i.e. interview), select a decent one.
The problem is that interviews don't scale well, and some kind of automatic culling of the field of candidates is necessary. Engineers, managers, etc all want to feel that whatever machine solution (keyword searching in resumes, applying AI to recorded video statements, HackerRanks) they select is better than random - but there's no incentive for them to check that that's true.
Obviously randomness + interviews is better than pure randomness, but ultimately hiring processes are still pretty random. If you need to weed out most of your candidates, you can't do much better than throwing most of their applications away - and companies end up doing just that, only they cargo cult an "automated process" that claims to do better.
Isn't it? While machine intervention might be able to weed out the most obvious low-quality candidates, I don't think there's any strong evidence that most hiring processes actually select the strongest hires - just that they, out of the set of candidates that progress to the point of human intervention (i.e. interview), select a decent one.
The problem is that interviews don't scale well, and some kind of automatic culling of the field of candidates is necessary. Engineers, managers, etc all want to feel that whatever machine solution (keyword searching in resumes, applying AI to recorded video statements, HackerRanks) they select is better than random - but there's no incentive for them to check that that's true.
Obviously randomness + interviews is better than pure randomness, but ultimately hiring processes are still pretty random. If you need to weed out most of your candidates, you can't do much better than throwing most of their applications away - and companies end up doing just that, only they cargo cult an "automated process" that claims to do better.
I would say that a random selection process would be worse than most hiring funnels that I've seen. This is doubly true considering the abject terrible quality of the lowest decile of candidate in software engineering. (The "spray and pray" resume machine-gunners would be way over-selected by any hiring process that relies on randomness when the rest of the industry is trying to select by interviewing.)
Has random hiring often been tried? I've never heard of anyone doing it. Not sure random hiring would be optimal, but it would be interesting if there were some data, doubtful it exists, though.
A couple places have tried open hiring (first come, first served) for some low-skilled positions, but with good initial results
https://www.fastcompany.com/90462746/the-body-shop-will-star...
https://www.fastcompany.com/90462746/the-body-shop-will-star...
> There is no meaningful data that any hiring process--good or bad--improves the outcome of a hire. If there were, everyone would be using it.
But every company in FAANGMO does use the same (or at least pretty similar) hiring process.
But every company in FAANGMO does use the same (or at least pretty similar) hiring process.
Yep. And there are zero large, successful tech companies hiring SWE's with anything other than Leetcode-style interviews.
Hiring is doing just fine.
Hiring is doing just fine.
This isn't true, depending on your definition of large. For example, Stripe is known to have an engineering interviewing process that diverges from the typical leetcode-style questions.
I think hiring is "doing just fine" and there's room for order-of-mag improvements on precision/recall.
I think hiring is "doing just fine" and there's room for order-of-mag improvements on precision/recall.
Just because it's widely used doesn't mean it's good.
Source: they let me interview people at one of those fancy FAANGMO places (and I don't actually know what I'm doing). Interview success comes down to how lucky you get in the loop imo.
Source: they let me interview people at one of those fancy FAANGMO places (and I don't actually know what I'm doing). Interview success comes down to how lucky you get in the loop imo.
^ I completely agree. This article [1] fully convinced me. And it prompted me to write my own post [2].
[1] Some Thoughts on Interviewing and Why We Do It https://jwongworks.com/blog/2018/07/24/some-thoughts-on-inte...
[2] Screening developers should be easy https://acjay.com/2019/05/16/hiring-developers-is-easy/
[1] Some Thoughts on Interviewing and Why We Do It https://jwongworks.com/blog/2018/07/24/some-thoughts-on-inte...
[2] Screening developers should be easy https://acjay.com/2019/05/16/hiring-developers-is-easy/
> There is no meaningful data that any hiring process--good or bad--improves the outcome of a hire
This is a manifestly absurd claim. It is possible to improve the outcome of a hire, and almost everyone is using those kinds of processes. The firm I work for does an excellent job filtering people for skill and compatibility. The trick is that if you want to capture the top e.g. 10% of applicants, you're going to have to pay them several times more than the median applicant. Most companies are too cheap to attract distinguished talent.
This is a manifestly absurd claim. It is possible to improve the outcome of a hire, and almost everyone is using those kinds of processes. The firm I work for does an excellent job filtering people for skill and compatibility. The trick is that if you want to capture the top e.g. 10% of applicants, you're going to have to pay them several times more than the median applicant. Most companies are too cheap to attract distinguished talent.
>The real truth is: hiring is a crapshoot. For any position and any field. Software engineering is no different
I tried building spaceship and failed. Fiend of mine tried building a spaceship and failed too. However, I know of people who built a spaceship. So is building a spaceship a crapshot?
Reality is: 95% of HRs are incompetent. That's where randomness comes from. Take a random man from street and assign him for HR role after a brief training -- you'll achieve a similar performance to those 95% HRs.
Everybody's talking about hiring the engineer, but so fewer people talk about finding a good HR that would help you to solve a "simple" problem: how to find a good engineer with small experience and small salary that would not leave your company for the next few years and would become after several months just as good as 70-100$/hour engineer hired from top software company, while later most likely still gonna need some time to adapt to your product to become efficient.
I tried building spaceship and failed. Fiend of mine tried building a spaceship and failed too. However, I know of people who built a spaceship. So is building a spaceship a crapshot?
Reality is: 95% of HRs are incompetent. That's where randomness comes from. Take a random man from street and assign him for HR role after a brief training -- you'll achieve a similar performance to those 95% HRs.
Everybody's talking about hiring the engineer, but so fewer people talk about finding a good HR that would help you to solve a "simple" problem: how to find a good engineer with small experience and small salary that would not leave your company for the next few years and would become after several months just as good as 70-100$/hour engineer hired from top software company, while later most likely still gonna need some time to adapt to your product to become efficient.
[deleted]
Because hiring has costs, this requires substantial risk tolerance, and is more suitable to a bigger corporation that can bear them. It will also give you a reputation — though some companies seem to manage quite well even with an iffy reputation in this area (e.g. Netflix). You need a certain amount of prestige to pull that off, I think.
Being hired from my experience hasn't been a crabshoot. Everywhere I've been hired it's been a success.
Hire people with multiple pages on a resume with a variety of experences is a good strategy increasing your odds.
Hire people with multiple pages on a resume with a variety of experences is a good strategy increasing your odds.
id also say it works out okay. its just long and tedious and it feels more painful than it should - but really its not all that bad in general.
I see very toxic people being rejected that think its because of their gender/color/whatever <= lots of complains but the process work
I get rejected sometimes because of misalignement from me, or from them <= feels bad man.. but the process works
I've never been hired to a place where I found that this was all a terrible idea, in 25 years. Theres been places better than others, theres been adjustments after hiring.
I've seen places hire people using simplified processes and the candidates were unsuccessful and unhappy after being hired <= process fail
I see very toxic people being rejected that think its because of their gender/color/whatever <= lots of complains but the process work
I get rejected sometimes because of misalignement from me, or from them <= feels bad man.. but the process works
I've never been hired to a place where I found that this was all a terrible idea, in 25 years. Theres been places better than others, theres been adjustments after hiring.
I've seen places hire people using simplified processes and the candidates were unsuccessful and unhappy after being hired <= process fail
I think a lot of us suspect that just choosing applicants randomly would probably have a very similar outcome to what we do now, but nobody wants to be the first to try it.
The above statement is really just validation that the current process sucks so much for everyone that it's conceivable to replace it with random choice. However, it's not actually true (for reasons explained in the blog) - as a hiring manager, I am confident you couldn't ship "Hello world" by hiring randomly.
> There is no meaningful data that any hiring process--good or bad--improves the outcome of a hire. If there were, everyone would be using it.
Word of mouth recommendations, and yes everyone uses it.
Word of mouth recommendations, and yes everyone uses it.
> There is no meaningful data that any hiring process--good or bad--improves the outcome of a hire.
Daniel Kahneman analyzed a bunch of data that lead him to concluded that the typical interview process did nothing to help select the best candidate. There's a chapter about it in Thinking Fast And Slow [1] and the advice he gives is summarized in this article [2]. I remember thinking after reading this book that it was just a matter of time until everyone everywhere would be denouncing interviews but here we are - old habits die hard.
[1] https://www.amazon.com/Thinking-Fast-Slow-Daniel-Kahneman/dp...
[2] https://www.businessinsider.com/daniel-kahneman-on-hiring-de...
Daniel Kahneman analyzed a bunch of data that lead him to concluded that the typical interview process did nothing to help select the best candidate. There's a chapter about it in Thinking Fast And Slow [1] and the advice he gives is summarized in this article [2]. I remember thinking after reading this book that it was just a matter of time until everyone everywhere would be denouncing interviews but here we are - old habits die hard.
[1] https://www.amazon.com/Thinking-Fast-Slow-Daniel-Kahneman/dp...
[2] https://www.businessinsider.com/daniel-kahneman-on-hiring-de...
What are you talking about? The article is nearly the exact opposite of what you claim. It says:
> A vast amount of research offers a promise: you are much more likely to find the best candidate if you use this procedure than if you do what people normally do in such situations, which is to go into the interview unprepared and to make choices by an overall intuitive judgment such as "I looked into his eyes and liked what I saw."
> A vast amount of research offers a promise: you are much more likely to find the best candidate if you use this procedure than if you do what people normally do in such situations, which is to go into the interview unprepared and to make choices by an overall intuitive judgment such as "I looked into his eyes and liked what I saw."
the typical interview is a series of unstructured intuitive judgement calls - Kahneman suggests something more like a survey with a strong emphasis on its calibration and isolating/controlling biases. Thinking Fast And Slow goes more in depth on how terrible typical interviews are - the article merely summarizes the advice he provided for what to do instead.
I have a very simple hiring process. I describe the product, the work, the gaps. I ask them what their interests are. We find where the interests align with our gaps. If there is no alignment, we simply don't move forward. I tell them the compensation. They accept or reject.
Takes about 45 minutes. Pretty simple, the goal is to make sure that they want to do the work that we need done, and that they feel prepared to do so.
So far so good.
Takes about 45 minutes. Pretty simple, the goal is to make sure that they want to do the work that we need done, and that they feel prepared to do so.
So far so good.
You can’t have possibly described your whole process.
How do you get these candidates in the room? Does everyone who applies get an interview?
And how do you decide between candidates? If it’s as you described, it sounds like it’s “first come first serve”.
How do you get these candidates in the room? Does everyone who applies get an interview?
And how do you decide between candidates? If it’s as you described, it sounds like it’s “first come first serve”.
I just reach out. We're small. At scale I would still prefer to primarily base recruiting on referrals.
Yeah, first come first serve.
Yeah, first come first serve.
And how do you evaluate their ability to fill those gaps?
We just talk about the work. I don't test them, that's a waste of everyone's time.
Probation period?
n=?
There's an old saying: "Don't ever take a fence down until you know the reason it was put up."
The phrase "hiring is broken" comes up dozens of times in HN searches. If something appears broken to you, but persists for a long time, it's time to start considering that the apparently broken thing actually serves a purpose you can't see to someone you don't know.
The phrase "hiring is broken" comes up dozens of times in HN searches. If something appears broken to you, but persists for a long time, it's time to start considering that the apparently broken thing actually serves a purpose you can't see to someone you don't know.
Hiring is not broken, there's simply wayyyyy too many candidates for any opened position, so companies get to be extremely picky and reject 100 people to fill one position.
And to be clear I'm not talking about having too many unqualified candidates who can't do a hello world (there's some but don't pass a screening test), I am talking about an oversupply of candidates of all levels who are able to pass the marathon of interview questions and exercises.
And to be clear I'm not talking about having too many unqualified candidates who can't do a hello world (there's some but don't pass a screening test), I am talking about an oversupply of candidates of all levels who are able to pass the marathon of interview questions and exercises.
That might be true in some areas but... in almost every company I've been, it's been ridiculously hard to find enough qualified applicants for a given role. There wouldn't even have been 100 people to reject. I think programming is still mostly an employee's market.
The 100 applicants are down to 10 people for an onsite, 2 or 3 get an offer, 1 is accepting it.
Sometimes when I look back at the last few people I interviewed onsite, I'm pretty sure they could all have done the job just fine. It's crazy that they're all getting rejected, there is nothing wrong with them, the company is overly picky for no reason.
Digging down there's probably 1 who got an offer and rejected it. Companies always forget to mention that half of their offers are rejected, hiring would be easier if they improved on that.
Sometimes when I look back at the last few people I interviewed onsite, I'm pretty sure they could all have done the job just fine. It's crazy that they're all getting rejected, there is nothing wrong with them, the company is overly picky for no reason.
Digging down there's probably 1 who got an offer and rejected it. Companies always forget to mention that half of their offers are rejected, hiring would be easier if they improved on that.
Same. Pretty much every candidate we interview is more than capable of doing the job technically. Overwhelmingly, why my team picks one person for the job and reject the others is for non-technical/behavioral reasons.
Then again my company is a boring investment bank, not a hot tech company. Top quality candidates are not in a rush to trample each other to join us. 90% of the candidates we get would not be able to brute force naively solve an leetcode medium or even a harder leetcode easy, let alone come up with an optimal solution. We would never be able to hire anyone if we rejected everyone that wasn't able to code an optimal solution in 40 minutes.
Yet if hired, I have no doubt nearly all of them would be able to do the actual job more than well enough - and that has been the case with everyone that I've interviewed and gave the thumbs up to.
Then again my company is a boring investment bank, not a hot tech company. Top quality candidates are not in a rush to trample each other to join us. 90% of the candidates we get would not be able to brute force naively solve an leetcode medium or even a harder leetcode easy, let alone come up with an optimal solution. We would never be able to hire anyone if we rejected everyone that wasn't able to code an optimal solution in 40 minutes.
Yet if hired, I have no doubt nearly all of them would be able to do the actual job more than well enough - and that has been the case with everyone that I've interviewed and gave the thumbs up to.
> Companies always forget to mention that half of their offers are rejected, hiring would be easier if they improved on that.
Easier for that company, but harder for the companies they beat out.
Easier for that company, but harder for the companies they beat out.
Define "qualified".
It's also true that it can be ridiculously hard to get a company to respond to an application, and to get an interview.
Assuming the job requirements aren't unnecessarily restrictive, there is something in the screening process that is actively harming both applicants and hiring managers.
It's also true that it can be ridiculously hard to get a company to respond to an application, and to get an interview.
Assuming the job requirements aren't unnecessarily restrictive, there is something in the screening process that is actively harming both applicants and hiring managers.
I'm not saying that the process is perfect, and I do think that it can be difficult to get a particular job you want, but - at least where I live - it's ridiculously easy to get a job as a dev, even if it's one you're not excited about. This is a vast improvement over many other professions where people are stuck within their roles for a long time because they would struggle to find employment elsewhere.
Well, in the sense that everyone rejected goes back in the pool and everyone accepted doesn't. So the pool is dominated by rejectees.
[deleted]
On the other hand, hiring gets discussed endlessly on HN and there doesn't seem to be a compelling reason presented for the status quo.
At some point you have to accept that the fence maybe doesn't serve a purpose, or its purpose may be forgotten and not applicable, and its worth the risk to take it down and see what happens.
At some point you have to accept that the fence maybe doesn't serve a purpose, or its purpose may be forgotten and not applicable, and its worth the risk to take it down and see what happens.
The compelling reason is the massive success of FAANG companies. How are they making unimaginable amounts of money if their engineers are from "broken hiring"? How is FAANG on a resume such a strong signal if it just means they got through a broken system?
Aline has said some good stuff but she loses me at: "There’s no substitute for chemistry, in dating or in hiring."
Hiring is not fucking dating. You are not having sex with your coworkers, you are not discriminating on gender, race, body type as everyone regularly does in dating. Dating is not a healthy system that you should aspire to in employment. It's very much broken in comparison with swipe apps and the like, just broken in different ways.
Aline has said some good stuff but she loses me at: "There’s no substitute for chemistry, in dating or in hiring."
Hiring is not fucking dating. You are not having sex with your coworkers, you are not discriminating on gender, race, body type as everyone regularly does in dating. Dating is not a healthy system that you should aspire to in employment. It's very much broken in comparison with swipe apps and the like, just broken in different ways.
> The compelling reason is the massive success of FAANG companies. How are they making unimaginable amounts of money if their engineers are from "broken hiring"?
Two possible expanations:
- What works for a big company of FAANG type is not necessarily a good idea for other companies.
- Because the FAANG companies have found a formula for printing money, they can afford such a hugely broken hiring process.
Two possible expanations:
- What works for a big company of FAANG type is not necessarily a good idea for other companies.
- Because the FAANG companies have found a formula for printing money, they can afford such a hugely broken hiring process.
Theyre monopolies
Just remember that taking down the fence is easy but not enough. You also need to find something else to do the job. Which often turns out to be very hard.
There is a long history of dysfunctional processes being replaced with other processes that often turn out to be as dysfunctional as the previous one. Just in a different way. See Scrum and Agile as examples.
There is a long history of dysfunctional processes being replaced with other processes that often turn out to be as dysfunctional as the previous one. Just in a different way. See Scrum and Agile as examples.
>On the other hand, hiring gets discussed endlessly on HN and there doesn't seem to be a compelling reason presented for the status quo
Disagree. After reading and participating in the endless HN hiring discussions, I'd say I've come to an understanding of why, at least in SF, interviews are done the way they are.
It seems to be a lowest-common-denominator approach that serves candidates and companies in different ways.
For the candidate, they can do one set of study (leetcode/system design) and that effort is applicable at a wide range of companies.
For the company, they are finding the intersection of people who are at least intelligent enough to grok CS fundamentals (I know it's just pattern matching after you've studied it), and willing to jump through enough hoops.
Hiring works a very different way outside FAANG leetcode style interviews. It's mostly a chat between a couple devs about what you've worked on in the past and how applicable that experience is and trying to get a sense of where you're at in your career and if you seem like you'd be good to work with. It's a lot less standardized, so it can be very hit and miss sometimes as sometimes you get quizzed on knowledge of their particular stack. Often the study you do for one company isn't necessarily translatable to another.
Disagree. After reading and participating in the endless HN hiring discussions, I'd say I've come to an understanding of why, at least in SF, interviews are done the way they are.
It seems to be a lowest-common-denominator approach that serves candidates and companies in different ways.
For the candidate, they can do one set of study (leetcode/system design) and that effort is applicable at a wide range of companies.
For the company, they are finding the intersection of people who are at least intelligent enough to grok CS fundamentals (I know it's just pattern matching after you've studied it), and willing to jump through enough hoops.
Hiring works a very different way outside FAANG leetcode style interviews. It's mostly a chat between a couple devs about what you've worked on in the past and how applicable that experience is and trying to get a sense of where you're at in your career and if you seem like you'd be good to work with. It's a lot less standardized, so it can be very hit and miss sometimes as sometimes you get quizzed on knowledge of their particular stack. Often the study you do for one company isn't necessarily translatable to another.
> If something appears broken to you, but persists for a long time, it's time to start considering that the apparently broken thing actually serves a purpose you can't see to someone you don't know.
What does this even imply? That someone benefits from this broken system? The recruiting firms? It is indeed broken as engineers are not happy with going through the middleman gauntlet, companies are short on developers and would ideally want to hire asap. The only problem I see for companies here is find the right candidates (filter the bad candidates) but all these obstacles don't seem to be doing that at all. So back to the drawing board...
What does this even imply? That someone benefits from this broken system? The recruiting firms? It is indeed broken as engineers are not happy with going through the middleman gauntlet, companies are short on developers and would ideally want to hire asap. The only problem I see for companies here is find the right candidates (filter the bad candidates) but all these obstacles don't seem to be doing that at all. So back to the drawing board...
It implies that the things that people complain about in interviews may serve a non-obvious purpose. For example, giving hard algorithm problems may not be to test whether you are a good programmer, but to test whether you are invested enough in landing the job to study for the interview.
This kind of logic can be used to rationalize anything and does not satisfy first principles thinking. Processes and tests should serve obvious purposes, otherwise there is no metric for measuring their effectiveness.
An example of this is coming up with "how many golf balls can you fit in a bus?" riddles, in the vain attempt at "seeing how the person thinks"/"problem solving"/"creativity".
An example of this is coming up with "how many golf balls can you fit in a bus?" riddles, in the vain attempt at "seeing how the person thinks"/"problem solving"/"creativity".
I'm not trying to defend it (and as a hiring manager I don't do it) - I'm just explaining the implication of Chesterton's Fence as applied to interviews. "Processes and tests should serve obvious purposes" seems very wrong to me, though - they should certainly serve useful purposes, and those purposes should be documented, but there is no real reason they need to be obvious to a layperson. Google specifically dropped those riddles because they did not find them effective, which means they have some metric for testing efficacy. They have not dropped algorithmic challenges, though. I wonder why?
That's just a way to reduce the number of applicants if you don't care about getting the goods hires because bad hires can game the interview just as much as good hires.
I'm skeptical of this claim - I believe bad programmers could study for years and still not be able to fake their way through an algorithmic interview administered by a competent programmer, and lazy programmers are probably not going to put in the effort to game it. I agree it will reduce the number of applicants though.
The fence is there because the risk of doing something new is hard, especially because testing hypotheses in hiring is expensive.
I am a hiring manager. I've also put significant thought into how we can change the hiring process, if only to get better candidates. However, it comes down to this: I only get 2-3 hires a quarter. Trying to get a meaningful result on changes I make is difficult. If one doesn't work out, did it not work out in a way that my original process would fix?
And so, we get conservative because even though it rejects a lot of qualified candidates, it also gets good candidates.
I am a hiring manager. I've also put significant thought into how we can change the hiring process, if only to get better candidates. However, it comes down to this: I only get 2-3 hires a quarter. Trying to get a meaningful result on changes I make is difficult. If one doesn't work out, did it not work out in a way that my original process would fix?
And so, we get conservative because even though it rejects a lot of qualified candidates, it also gets good candidates.
> I am a hiring manager. I've also put significant thought into how we can change the hiring process, if only to get better candidates.
Simple solution: Be very clear what kind of candidate the company actually needs, e.g. do you need
- a genius in algorithm design
- a person who knows the subtle details of a specific language/platform/standard X
- a nice person vs a person that will fight for "doing the right thing" (e.g. is possibly strongly opinionated)
- how important is it really that the person is also nice to hang up after work
- an allrounder vs an expert for X, Y
- a person who creates solid code that will be good to maintain vs. a person that "simply get things done"
- a person who is is already good at X vs a person who has a high potential to become good at X
Simple solution: Be very clear what kind of candidate the company actually needs, e.g. do you need
- a genius in algorithm design
- a person who knows the subtle details of a specific language/platform/standard X
- a nice person vs a person that will fight for "doing the right thing" (e.g. is possibly strongly opinionated)
- how important is it really that the person is also nice to hang up after work
- an allrounder vs an expert for X, Y
- a person who creates solid code that will be good to maintain vs. a person that "simply get things done"
- a person who is is already good at X vs a person who has a high potential to become good at X
There are 20 more that you could have named. What is their temperament? What kind of initiative do they have? Are they collaborative or more independent? How do they collaborate between teams and is that something you need? Do you need someone that can go in front of a customer?
So, do you customize your hiring process for each hire? What if multiple teams need different types of people? How big is your organization?
And if you get a discrimination claim, can you prove you have a fair process? The bigger the company, the more standard the process generally is.
My interviews aren’t heavy algorithm interviews, unless I need it. However, those questions you mention and many others are hard to analyze. How do you test that someone is an expert, especially if you don’t have an expert on staff? How do you know if the person writes maintainable code or just talks a good game?
How do you assess work ethic?
Hiring is hard.
So, do you customize your hiring process for each hire? What if multiple teams need different types of people? How big is your organization?
And if you get a discrimination claim, can you prove you have a fair process? The bigger the company, the more standard the process generally is.
My interviews aren’t heavy algorithm interviews, unless I need it. However, those questions you mention and many others are hard to analyze. How do you test that someone is an expert, especially if you don’t have an expert on staff? How do you know if the person writes maintainable code or just talks a good game?
How do you assess work ethic?
Hiring is hard.
As one very junior in my career, this comment was really eye opening for me. I am feel a lot of the frustration and stress of the 'broken' hiring process, but was quite comforted by the introspection your comment caused.
thank you for that :)
thank you for that :)
> There are 20 more that you could have named.
Of course; these were just examples as the "e.g." tells.
> How do you test that someone is an expert, especially if you don’t have an expert on staff?
I gave some idea on https://news.ycombinator.com/item?id=24841552
Of course; these were just examples as the "e.g." tells.
> How do you test that someone is an expert, especially if you don’t have an expert on staff?
I gave some idea on https://news.ycombinator.com/item?id=24841552
That gets to the difference between a generalist and a specialist. Sometimes, I need to hire a specialist because we need someone who can provide high level expertise to a group of generalists. (E.g. a specialist on visual design and interactions with javascript, react, and best practices regarding such.) If we are looking to hire for that skill, trivia isn't going to work but neither do we want to hire someone who can talk a good game but would be quickly exposed by an expert, and will lead us down the wrong path.
Now, I can give you all sorts of answers here. My point is that unless you're going to put a lot of effort into redesigning the interview process from first principles for your company due to some need (like Google), or you are putting your effort into a startup like interviewing.io, you're likely going to take an existing process and tweak it. And that explains why the fence is there.
Now, I can give you all sorts of answers here. My point is that unless you're going to put a lot of effort into redesigning the interview process from first principles for your company due to some need (like Google), or you are putting your effort into a startup like interviewing.io, you're likely going to take an existing process and tweak it. And that explains why the fence is there.
> a nice person vs a person that will fight for "doing the right thing" (e.g. is possibly strongly opinionated)
Maybe it's just a matter of wording, but the implication that people who will go to bat for an important choice can't also be "nice" strikes me as strange and contradicts my experience. Good comment otherwise though.
Maybe it's just a matter of wording, but the implication that people who will go to bat for an important choice can't also be "nice" strikes me as strange and contradicts my experience. Good comment otherwise though.
Also a hiring manager.
If you conceptualize a hire as "this decision costs me $100k to $200k, and six months", you'll understand why folks are conservative. That's my finger in the wind cost of a bad hire, in terms of their salary, the salary and opportunity cost of their first two weeks buddy, plus all the other related efforts to onboard and train. Plus, again, if it's a bad hire, by the time we spend 2 months getting to the termination, and a 2 month search, and a 2 month onboarding, I wait 1/2 a year before I get the employee I need.
If you conceptualize a hire as "this decision costs me $100k to $200k, and six months", you'll understand why folks are conservative. That's my finger in the wind cost of a bad hire, in terms of their salary, the salary and opportunity cost of their first two weeks buddy, plus all the other related efforts to onboard and train. Plus, again, if it's a bad hire, by the time we spend 2 months getting to the termination, and a 2 month search, and a 2 month onboarding, I wait 1/2 a year before I get the employee I need.
>The fence is there because the risk of doing something new is hard
This is the exact wrong lesson to take from the proverb. Instead of considering why something is still in place, you should consider why it was put in place to start with.
This is the exact wrong lesson to take from the proverb. Instead of considering why something is still in place, you should consider why it was put in place to start with.
Coding tests came about because some developers can talk a good game but are very poor at software development, and it can take months to realize in more complex code bases. Algorithm tests came about because when interviewing CS majors, you can assume they have had an algorithm class. Many of us know why the fence was put up. We don’t tear it down because it is a complex problem. It just takes one successful company to create a better process and the fences will start coming down, just as whiteboarding has become much less prevelent in the last decade as laptops have become common for developers.
If everyone had this mindset, we will still be in the Stone Age, things can and should always be made better.
Minute progressive changes to systems that already supposedly work end up bringing about systems that work better.
Minute progressive changes to systems that already supposedly work end up bringing about systems that work better.
You're adding a value judgment to the comment you're replying to that wasn't there.
> serves a purpose you can't see to someone you don't know.
Does not mean "good, but you're too stupid to see it."
edit: after one figures out why something is a certain way one could come to the conclusion that it must be changed immediately, and the reason it was that way was more destructive than one could have imagined.
> serves a purpose you can't see to someone you don't know.
Does not mean "good, but you're too stupid to see it."
edit: after one figures out why something is a certain way one could come to the conclusion that it must be changed immediately, and the reason it was that way was more destructive than one could have imagined.
It's implied that if the reason is not a good one you should take down the fence.
Or alternatively it's a hard problem, in a domain where nailing down a good solution may be non-obvious, or perhaps even really defining the problem domain is not yet done.
The hard problem being you have incredibly limited bandwidth to gather data on a candidate.
I think this is a big part of it.
When I think about how I'd like my work to have a big, positive impact on the world, one of the first things that comes to mind is fixing hiring/job hunting. I'm moderately intelligent and have felt this way for a couple decades, and I still haven't done anything about it because I still don't know how to make it not suck, and I've yet to see anyone else working on a good solution either.
I've seen a lot of very smart, capable, and talented people have trouble finding a decent job, and eventually settle for underemployment for a good while. A system that could properly utilize their productivity would be vastly superior to our current system. There's a lot of money on the table for anyone who implements that system.
I don't know what that system looks like. I just know with certainty that there's a massive amount of wasted productivity under our current system.
What I can tell you is that when I graduated college, the way you found a job was to use Monster.com--a big job search engine--apply to various openings in a tedious process, and interview. Today, you use Indeed.com--a big job search engine--apply to various openings in approximately the same tedious process, and then interview in approximately the same way.
There's money on the table for anyone who can improve the system, and no one has. This tells me it's hard. (The fact that I don't know how to improve it a bonus.)
When I think about how I'd like my work to have a big, positive impact on the world, one of the first things that comes to mind is fixing hiring/job hunting. I'm moderately intelligent and have felt this way for a couple decades, and I still haven't done anything about it because I still don't know how to make it not suck, and I've yet to see anyone else working on a good solution either.
I've seen a lot of very smart, capable, and talented people have trouble finding a decent job, and eventually settle for underemployment for a good while. A system that could properly utilize their productivity would be vastly superior to our current system. There's a lot of money on the table for anyone who implements that system.
I don't know what that system looks like. I just know with certainty that there's a massive amount of wasted productivity under our current system.
What I can tell you is that when I graduated college, the way you found a job was to use Monster.com--a big job search engine--apply to various openings in a tedious process, and interview. Today, you use Indeed.com--a big job search engine--apply to various openings in approximately the same tedious process, and then interview in approximately the same way.
There's money on the table for anyone who can improve the system, and no one has. This tells me it's hard. (The fact that I don't know how to improve it a bonus.)
> There's money on the table for anyone who can improve the system, and no one has. This tells me it's hard.
In other comments on this article, I wrote my arguments why I don't believe that detecting good candidates is hard (I wrote suggestions there).
I believe the hard problem is rather that most companies/recruiters don't actually know (or won't say) what skills they are really looking for, so they use dubious processes to rationalize why they chose a specific candidate.
In other comments on this article, I wrote my arguments why I don't believe that detecting good candidates is hard (I wrote suggestions there).
I believe the hard problem is rather that most companies/recruiters don't actually know (or won't say) what skills they are really looking for, so they use dubious processes to rationalize why they chose a specific candidate.
Read the article, she discusses that.
> Although these approaches are rational under existing constraints, they’re neither particularly efficient nor particularly fair to the individuals subject to them. This doesn’t mean that we can’t improve the system … But before we talk about what we have the power to change, let’s dive a bit deeper into the constraints we face today.
> Although these approaches are rational under existing constraints, they’re neither particularly efficient nor particularly fair to the individuals subject to them. This doesn’t mean that we can’t improve the system … But before we talk about what we have the power to change, let’s dive a bit deeper into the constraints we face today.
I did read the article. The fact that someone reasons ones way to a dubious conclusion doesn't make the conclusion less dubious.
All premature fence-pullers think they have rational reasons for pulling the fence down. They're the ones the quote is meant for.
All premature fence-pullers think they have rational reasons for pulling the fence down. They're the ones the quote is meant for.
“it's time to start considering that the apparently broken thing actually serves a purpose you can't see to someone you don't know.”
That sounds a little like conspiracy theory. My theory is that hiring is just really hard and it’s difficult to do that at scale.
I know people who are really good at interviewing. I think I myself can interview reasonably for people who have to work with me. But that takes a lot of time and energy. So “specialists” from HR take over. But they don’t understand the real requirements for the job so they have to come up with a lot standardized indirect measures which don’t work well.
That sounds a little like conspiracy theory. My theory is that hiring is just really hard and it’s difficult to do that at scale.
I know people who are really good at interviewing. I think I myself can interview reasonably for people who have to work with me. But that takes a lot of time and energy. So “specialists” from HR take over. But they don’t understand the real requirements for the job so they have to come up with a lot standardized indirect measures which don’t work well.
> My theory is that hiring is just really hard
Not that hard. Talk to people like human beings and examine their previous work and employment history.
Not that hard. Talk to people like human beings and examine their previous work and employment history.
You conveniently cut off the important part:
> hiring is just really hard and it’s difficult to do that at scale
Yes, talking to people about their previous work and employment history is a good way to judge their fit for a position. It also takes about half a working day of 2-3 people each time to do it properly.
> hiring is just really hard and it’s difficult to do that at scale
Yes, talking to people about their previous work and employment history is a good way to judge their fit for a position. It also takes about half a working day of 2-3 people each time to do it properly.
Like Soylent Green, a software company is people. If you have hiring authority and you don't think it's worth your time to spend half a day a couple of times a week to get the right people into your organization, you have the wrong job.
I can confirm that putting in this time is imperative to getting the right people hired.
But if you require that any engineer involved should spend a quarter to half of their week on hiring, and that you yourself consider anyone with less commitment unsuitable, don't you agree that scalability becomes a problem?
How many half-recruiters, half-engineers do you think are available, compared to the overall need for engineers with hiring authority? I don't have data on the former, but it's apparent to me that, if you hire people to do this full-time instead, you're hiring a recruiter. That's what gets you exactly the system everybody seems to complain about.
But if you require that any engineer involved should spend a quarter to half of their week on hiring, and that you yourself consider anyone with less commitment unsuitable, don't you agree that scalability becomes a problem?
How many half-recruiters, half-engineers do you think are available, compared to the overall need for engineers with hiring authority? I don't have data on the former, but it's apparent to me that, if you hire people to do this full-time instead, you're hiring a recruiter. That's what gets you exactly the system everybody seems to complain about.
Only for the record, that is Chesterton's fence:
https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence
https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence
I think that phrase is a thought terminating cliche. How can one argue with the claim that every construct has a valuable hidden purpose despite evidence to the contrary?
> How can one argue with the claim that every construct has a valuable hidden purpose despite evidence to the contrary?
He doesn't claim that it has a valuable hidden purpose, he claims that it had (when it was constructed). :-)
He doesn't claim that it has a valuable hidden purpose, he claims that it had (when it was constructed). :-)
I don't think the claim is "every construct has a valuable hidden purpose". It's "if you can't explain all the important purposes of a construct, you aren't ready to take it down."
I remind myself of Chesterton's Fence every time I encounter some WTF code.
I remind myself of Chesterton's Fence every time I encounter some WTF code.
I think that's what this blog does, no?
Correct, the algo style interview is mostly a test of work ethic and time spent, not one simple of technical skill.
What if the answer is a combination of laziness, fashion, elitism and a desire to haze?
Recruiters are often a necessary evil - they act as a filter to find the "smart people" and for smart people to find the good roles.
1. Finding a good recruiter is as hard or harder than finding a good employee - only do it if you expect to be recruiting for multiple roles over a period.
2. Think a lot about what you're looking for in an engineer, how you'll evaluate candidates, what experience will be shows for the talents you need and then how to articulate that to the recruiter. When they send CVs/resumes make sure you give feedback on what are the bad and good qualities.
3. When recruiting I've nearly always gone via recruiters that have gotten me roles or have worked with in the past (or atleast through them to someone else in their organisation).
1. Finding a good recruiter is as hard or harder than finding a good employee - only do it if you expect to be recruiting for multiple roles over a period.
2. Think a lot about what you're looking for in an engineer, how you'll evaluate candidates, what experience will be shows for the talents you need and then how to articulate that to the recruiter. When they send CVs/resumes make sure you give feedback on what are the bad and good qualities.
3. When recruiting I've nearly always gone via recruiters that have gotten me roles or have worked with in the past (or atleast through them to someone else in their organisation).
How come when I login to my interviewing.io account I don't see Twitter but it's shown in the screenshot? Is that an accurate representation? I do see the other companies from the screenshot but with fewer jobs.
So what about certifications?
To me it looks exactly like the kind of credentials the article describes.
To me it looks exactly like the kind of credentials the article describes.
> In any event, on interviewing.io, once you’ve built up your reputation by doing mock interviews (persistent, meaningful credentialing)
Credentials for doing well in interviews, maybe. I can respect the frankness in the following paragraph though:
> Of course, one of the limitations of our approach is that we’re getting performance data about engineers from the practice interviews they do on our platform. Any seasoned interviewer will tell you that the signal one gets from a technical interview isn’t the whole story.
And really that is another big topic that requires more research imo - interview performance vs job performance.
Credentials for doing well in interviews, maybe. I can respect the frankness in the following paragraph though:
> Of course, one of the limitations of our approach is that we’re getting performance data about engineers from the practice interviews they do on our platform. Any seasoned interviewer will tell you that the signal one gets from a technical interview isn’t the whole story.
And really that is another big topic that requires more research imo - interview performance vs job performance.
I really don’t like the “x is broken”-style of saying something doesn’t work. It’s not broken, it’s suboptimal.
Exactly. If you’re going to make a claim that “hiring in tech is broken”, you’ll need some pretty good data to back that up, especially when you consider that some of the most profitable companies in human history are doing the thing you say is “broken”.
100% Agree. There are 6 ridiculous reasons why click-bait titles are broken.
Someone here pointed it out on another post a long time ago but the only explanation for the hazing ritual that has become modern hiring is that we have a glut of engineering talent.
I'm interested to see what the new trend of remote work will do to the current paradigm. I think the lot of us are about to find we're not much more than highly skilled mechanics.
Edit:
On reading all the comments that came after mine, I realize I'll have a decision to make Q1 2021 when my role at my current startup becomes financially unwise to maintain (slow growth on a popular product in a very niche industry). Im a co-founder but still it will make more financial sense to put the tech product in Maintenance Mode for awhile with some offshore contractors. All the hard work has been done save for riding out the slow Change The Industry adoption curve.
When this day comes I'll be back on the market myself and in considering all this I think Im going to target large F500 companies who's core business isn't tech or internet or whatever. Companies that rely on tech as a part of their larger non-tech business.
I know folks who are devs at AMZN and GOOG and I can't help but come away with the impression that save for the RSUs they wouldn't be there either. The pain around getting the offer may not be the worst part - the worst part may be after you accept and actually have to work there. Fairly simple logic might indicate that if the dating phase is this bad, the marriage can't be much better.
I'm interested to see what the new trend of remote work will do to the current paradigm. I think the lot of us are about to find we're not much more than highly skilled mechanics.
Edit:
On reading all the comments that came after mine, I realize I'll have a decision to make Q1 2021 when my role at my current startup becomes financially unwise to maintain (slow growth on a popular product in a very niche industry). Im a co-founder but still it will make more financial sense to put the tech product in Maintenance Mode for awhile with some offshore contractors. All the hard work has been done save for riding out the slow Change The Industry adoption curve.
When this day comes I'll be back on the market myself and in considering all this I think Im going to target large F500 companies who's core business isn't tech or internet or whatever. Companies that rely on tech as a part of their larger non-tech business.
I know folks who are devs at AMZN and GOOG and I can't help but come away with the impression that save for the RSUs they wouldn't be there either. The pain around getting the offer may not be the worst part - the worst part may be after you accept and actually have to work there. Fairly simple logic might indicate that if the dating phase is this bad, the marriage can't be much better.
More specifically than just a glut of engineering talent, is an incredibly broad range of engineering talent. I'm not talking about genius 10x engineer controversy or anything like that.
I'm talking about the difference between someone transitioning fields fresh out of a 12 week boot camp and someone with a computer science degree, full stack experience, and knowledge of what's going on under the hood. Even when you see many years of experience on somebody's resume, it's really really hard to tell what that means.
It's the combination of a really wide range of skill and a really big difficulty assessing that skill from just the resume. So the interview really has to do heavy lifting in this field.
Compare that to my partners field, where there's a licensing board, the job duties are pretty much the same anywhere, and all you really need is quick check of is this person sane, is their license and training up-to-date, and do their references check out. Even in that field, you can imagine the interviews being way more extensive if there wasn't a license requirement and mandatory regular training. It would be like a lawyer having to pass the bar exam at every interview, instead of being able to say that they've passed the bar exam.
(This is all coming from somebody without a CS degree who transitioned into the field, so I'm really really not proposing we do gatekeeping. I'm just acknowledging that without gatekeeping, we effectively have to pass the bar exam at every interview.)
I'm talking about the difference between someone transitioning fields fresh out of a 12 week boot camp and someone with a computer science degree, full stack experience, and knowledge of what's going on under the hood. Even when you see many years of experience on somebody's resume, it's really really hard to tell what that means.
It's the combination of a really wide range of skill and a really big difficulty assessing that skill from just the resume. So the interview really has to do heavy lifting in this field.
Compare that to my partners field, where there's a licensing board, the job duties are pretty much the same anywhere, and all you really need is quick check of is this person sane, is their license and training up-to-date, and do their references check out. Even in that field, you can imagine the interviews being way more extensive if there wasn't a license requirement and mandatory regular training. It would be like a lawyer having to pass the bar exam at every interview, instead of being able to say that they've passed the bar exam.
(This is all coming from somebody without a CS degree who transitioned into the field, so I'm really really not proposing we do gatekeeping. I'm just acknowledging that without gatekeeping, we effectively have to pass the bar exam at every interview.)
I believe I have posted this before, but one of the big problems with this industry is the mashing of a whole bunch of different roles into the same bucket.
I used to be an electrical engineer. In the traditional engineering world there are mechanics/assemblers (high school with maybe a vocational certificate program), technicians (two-year Associates or vocational degree), engineers (Bachelor's or Master's degree in a specific, relevant discipline), and researchers (Ph.D.+ in a specific, relevant discipline).
In the Valley-oriented tech industry, the first three all get squashed into "software engineer". It's often not clear what a company needs, even to the company. Some companies seemingly don't care; Google, for instance, seems to hire all software engineers to the same bar then sorts them internally into the mechanic/technician/engineer bins based on what teams will take them. I think hiring is going to remain fundamentally broken until companies start making an explicit distinction between these roles when they open reqs and interview candidates.
Now, I'm not saying my former industry's way of doing things is all good. I have effectively left it for good by virtue of not having touched a circuit card or JTAG debugger professionally in 14 years. I do think this industry could learn from the separation of roles, though.
I used to be an electrical engineer. In the traditional engineering world there are mechanics/assemblers (high school with maybe a vocational certificate program), technicians (two-year Associates or vocational degree), engineers (Bachelor's or Master's degree in a specific, relevant discipline), and researchers (Ph.D.+ in a specific, relevant discipline).
In the Valley-oriented tech industry, the first three all get squashed into "software engineer". It's often not clear what a company needs, even to the company. Some companies seemingly don't care; Google, for instance, seems to hire all software engineers to the same bar then sorts them internally into the mechanic/technician/engineer bins based on what teams will take them. I think hiring is going to remain fundamentally broken until companies start making an explicit distinction between these roles when they open reqs and interview candidates.
Now, I'm not saying my former industry's way of doing things is all good. I have effectively left it for good by virtue of not having touched a circuit card or JTAG debugger professionally in 14 years. I do think this industry could learn from the separation of roles, though.
The problem with the bar comparison is that at a white shoe law firm (the rough equivalent of FAANG) associates go through an extremely competitive, up-or-out apprenticeship/hazing program. The interview gatekeeping isn’t gone, it just becomes chronic instead of acute.
I think in addition to the skill differences, there are also huge opinion differences. Nobody really knows the best way to write software, but everyone has their particular way they think it should be done. So even if you had two genius developers, they might disagree so much they essentially can't work together.
> It's the combination of a really wide range of skill and a really big difficulty assessing that skill from just the resume.
If you know what skills you are looking for (hint: lots of companies and recruiters don't), this is not actually that hard.
For every skill, there are questions that should be really easy to answer for everybody with expertise, but are suprising/hard to answer for everybody who pretends to have knowledge. This enables you to check quite quickly whether the claimed skills are actually there or not.
For example, the easier sections in
> https://github.com/satwikkansal/wtfpython
might give you a hint for topics that most seasoned Python programmers should know blindfolded while they are probably rather surprising for anybody with shallow Python knowledge. Let the applicant explain how they came up with their solution for, say, some of the problems, and you will see rather fast whether the claimed skills are actually there or not.
If you know what skills you are looking for (hint: lots of companies and recruiters don't), this is not actually that hard.
For every skill, there are questions that should be really easy to answer for everybody with expertise, but are suprising/hard to answer for everybody who pretends to have knowledge. This enables you to check quite quickly whether the claimed skills are actually there or not.
For example, the easier sections in
> https://github.com/satwikkansal/wtfpython
might give you a hint for topics that most seasoned Python programmers should know blindfolded while they are probably rather surprising for anybody with shallow Python knowledge. Let the applicant explain how they came up with their solution for, say, some of the problems, and you will see rather fast whether the claimed skills are actually there or not.
Quizzing on programming language minutia is a terrible way to hire. It's mostly quizzing how long people have been writing that specific language and their interest in language minutia.
It's been several years since I wrote JavaScript or Python on a regular basis professionally and I'd almost certainly fail your quiz. Yet I'm very confident I could be quickly productive in a Python environment.
Interviews should probe thought processing, not language minutia.
It's been several years since I wrote JavaScript or Python on a regular basis professionally and I'd almost certainly fail your quiz. Yet I'm very confident I could be quickly productive in a Python environment.
Interviews should probe thought processing, not language minutia.
> not proposing we do gatekeeping
The opposite of gate keeping, by analogy, is letting everybody in. That is, hiring each and every single person who applies in. As soon as you set a minimum bar, the first person who can't clear it accuses you of "gatekeeping".
The opposite of gate keeping, by analogy, is letting everybody in. That is, hiring each and every single person who applies in. As soon as you set a minimum bar, the first person who can't clear it accuses you of "gatekeeping".
I meant gatekeeping to the whole industry itself, like everyone needs a license and certification from the American Association of Software Engineers, for which you need a computer science degree from an accredited university, or something like that. Good point though.
Having been on both sides, that seems like the most likely explanation. For a given job posting we see hundreds of applicants, 90% of which have no business applying for that job and maybe another 5% are close but unqualified.
The process has become optimized for weeding out the 490 bad applicants to eventually get down to the 10 worth talking to. It's painful for both sides, but eventually it does get there.
The process has become optimized for weeding out the 490 bad applicants to eventually get down to the 10 worth talking to. It's painful for both sides, but eventually it does get there.
I think it's more so one can retroactively justify picking a particular qualified candidate from a list of 100 qualified candidates.
That opinion will make anyone with experience in hiring think that you don't have it (experience in hiring). Sturgeon's law holds true for job applicants.
on the other hand, 90% of tech hiring managers have no business being in the decision making position.
it's a lose lose situation
it's a lose lose situation
I think this is part of the answer to the question of why hiring sucks. I was speaking to a coworker at one point and discussing mistakes that led to a rejection, and the conversation turned to the fact that these mistakes don't make someone a bad engineer, especially if they weren't actively preparing for interview. He said "Well, you have to reject someone", and the conversation kind of ended there.
I found this answer to both be true and unsettling.
I found this answer to both be true and unsettling.
pandemic has worsened the situation
big tech engineer turnover has ground to a halt (employed engineers playing it safe)
they have open positions but those were based on pre-pandemic turnover estimates
so they don't need to hire as many
the result: perfect coding challenges not enough ... now also need perfect behavioral answers, perfect 40 yard dash, perfect push-ups, perfect knife juggling, and most importantly, perfect clown show while wearing red nose and green wig.
big tech engineer turnover has ground to a halt (employed engineers playing it safe)
they have open positions but those were based on pre-pandemic turnover estimates
so they don't need to hire as many
the result: perfect coding challenges not enough ... now also need perfect behavioral answers, perfect 40 yard dash, perfect push-ups, perfect knife juggling, and most importantly, perfect clown show while wearing red nose and green wig.
[deleted]
Ha, yeah, bureaucracy sucks!
Hiring is just one of many things that the big G has made worse for the tech field. I wish people would stop idolizing them and see the negative influence they have had on our profession.
> Or wonder why we think we can succeed where so many others have failed. But, before you do, think on this. I’ve spent the last five years of my life dedicated to bringing this vision of hiring to fruition because I believe, in my heart of hearts, that this is the only way hiring can be both efficient and fair.
When your best argument is "trust me I know" usually this doesnt mean any good
When your best argument is "trust me I know" usually this doesnt mean any good
This is a really long article. The author should consider putting a TLDR at the top. Manged to read only half of it and still didn't get the point.
The point was "use interviewing.io's (the author's company) services", in the last paragraph.
God I am so sick of hearing "hiring is broken". Not that I necessarily disagree, but this is the first sentence of every single recruiting startup pitch. (And spoiler alert- none of them have fixed it) It comes off tongue in cheek to me now.
Yes, this article is nothing more than an advertisement for interviewing.io
They seem to be running a marketing campaign. I saw a clickbait-style article on habr today.
OP here/founder of interviewing.io. What is habr?
I'm sick of hearing _x_ is broken
[deleted]
Here's a radical idea (read to the end before you object). The inspiration is a blend of how open source projects recruit developers, and how the 20% Google side-projects used to work.
I work for company A, I'm starting to get slightly bored or interested in doing something else. Without quitting my job, I contribute a few days of code to company B, whose project I find interesting. As I contribute more to company B, I eventually quit company A and join company B full-time.
Benefits of this approach: no interviews. Know what you are getting into. Try different things and what works for you.
How can we make this work: legal framework. California, if you are listening, pass a law that prevents companies from exclusive work arrangements, so I can always do a side-gig with company B even if they are competitors. Have company B compensate me, so we don't end up in a situation where company B is abusing job seekers by getting free work done. Maybe a law could say that I'm safe as long as my work for company B while employed by company A doesn't exceed 5% of my salary or so.
Would that work?
I work for company A, I'm starting to get slightly bored or interested in doing something else. Without quitting my job, I contribute a few days of code to company B, whose project I find interesting. As I contribute more to company B, I eventually quit company A and join company B full-time.
Benefits of this approach: no interviews. Know what you are getting into. Try different things and what works for you.
How can we make this work: legal framework. California, if you are listening, pass a law that prevents companies from exclusive work arrangements, so I can always do a side-gig with company B even if they are competitors. Have company B compensate me, so we don't end up in a situation where company B is abusing job seekers by getting free work done. Maybe a law could say that I'm safe as long as my work for company B while employed by company A doesn't exceed 5% of my salary or so.
Would that work?
A few thoughts:
1. This process is probably going to bias your hiring pool towards young and single people that are willing to either work weekends or use vacation time to go work on a part time job
2. Forcing a company to let an employee work for a competitor opens up a whole new can of worms. This seems game-able in the same way that the Washington DC revolving door is e.g. Uber hires a Tesla autopilot engineer at the cap of 5% of his salary, and after a few years of "contributions" which are totally not industrial espionage they bring him on full-time with an eleventy million dollar signing bonus.
1. This process is probably going to bias your hiring pool towards young and single people that are willing to either work weekends or use vacation time to go work on a part time job
2. Forcing a company to let an employee work for a competitor opens up a whole new can of worms. This seems game-able in the same way that the Washington DC revolving door is e.g. Uber hires a Tesla autopilot engineer at the cap of 5% of his salary, and after a few years of "contributions" which are totally not industrial espionage they bring him on full-time with an eleventy million dollar signing bonus.
My partner works for a big accounting firm and when a member of staff wants to leave their people-manager, will if they wish, actively help them find a secondment to another firm (not a competitor).
People sometimes want to leave a job and it's in everyones interest for that process to be smooth and pleasant. The leaver has a good final impression of the firm so they recomend it in the future to potential clients or employees, they get support in finding and trialing a new job, and the company to whihc they are seconded gets a low risk trial of a new memeber of staff.
It just seems so grown up compared to the ineffectual thrashing about of tech recruiting.
People sometimes want to leave a job and it's in everyones interest for that process to be smooth and pleasant. The leaver has a good final impression of the firm so they recomend it in the future to potential clients or employees, they get support in finding and trialing a new job, and the company to whihc they are seconded gets a low risk trial of a new memeber of staff.
It just seems so grown up compared to the ineffectual thrashing about of tech recruiting.
Hmm, legal framework, maybe... but maybe with some small tweaks the legal framework wouldn't need much changed...
If you become a contractor rather than a full time employee, the only thing you're missing is benefits/retirement probably, in addition to longer term commitments from an organization (maybe - these days there are no real guarantees).
If you can get benefits/retirement through some other kind of government program or join an independent group that forms together (I remember there was a YC company that was doing this) to pay for group benefits - then why not just go the contractor route?
If you become a contractor rather than a full time employee, the only thing you're missing is benefits/retirement probably, in addition to longer term commitments from an organization (maybe - these days there are no real guarantees).
If you can get benefits/retirement through some other kind of government program or join an independent group that forms together (I remember there was a YC company that was doing this) to pay for group benefits - then why not just go the contractor route?
This is relatively close to my dream hiring process, except I'd shortcut it. Instead of working 1 day a week because you're bored, just take a week off. Come work at my company for a week. If we like you, we'll hire you.
However, the legal issues sound like a nightmare. Additionally, in the US many people's benefits are tied to their job, so if they needed to, for example, take unpaid leave to do this "test drive" that would also cause complications.
However, the legal issues sound like a nightmare. Additionally, in the US many people's benefits are tied to their job, so if they needed to, for example, take unpaid leave to do this "test drive" that would also cause complications.
Wouldn't most companies who are in the shoes of company A in this example, find some excuse to lay off the employee in question when the person applies for this arrangement?
Or do you mean the employee would do this in secret from company A? If so, like the other commenter said, that excludes anyone who can't put in weekend work time.
Or do you mean the employee would do this in secret from company A? If so, like the other commenter said, that excludes anyone who can't put in weekend work time.
1000x this! Seems like win win for both sides. Kind of reminds me of universities that let you take a course or two to then allow you to continue in the degree program . For some reason I can’t think of any university that actually does that. Is it possible that hiring and university admission suffer the same affliction?
I think there is already a law. What you do in your time, material and equipment is your own business.
...as long as your employer doesn't think it competes with their business. If it does (even if it competes with a part of the business that has nothing to do with your work or that you don't even know about) things can get messy
That's consulting/contracting.
Obviously no one wants to hire a long term full-time salaried employee on those terms.
Obviously no one wants to hire a long term full-time salaried employee on those terms.
Hiring is broken period, not jut for engineers.
I could whine on about this topic for days, I ran an IT Division that supported HR for a very large company, and we built a slick streamlined system that worked great, in spite of what HR wanted. The two things that drive me crazy when applying for a job
1) keyword matching metrics, UGH!! It's not an effective filter. If you really want to filter candidates have a job specific requirements questionnaire. As a hiring manager I'd much rather create my filter questionnaire.
2)Using the resume submission process to complete the employment application form <DUMBEST IDEA EVER>, it can be a two step process, REALLY IT CAN BE A TWO STEP PROCESS!
NOBODY READS THE EMPLOYMENT APPLICATION FORM, it has nothing to do with screening candidates. If you want to interview a candidate THEN have them complete the employment form.
I could whine on about this topic for days, I ran an IT Division that supported HR for a very large company, and we built a slick streamlined system that worked great, in spite of what HR wanted. The two things that drive me crazy when applying for a job
1) keyword matching metrics, UGH!! It's not an effective filter. If you really want to filter candidates have a job specific requirements questionnaire. As a hiring manager I'd much rather create my filter questionnaire.
2)Using the resume submission process to complete the employment application form <DUMBEST IDEA EVER>, it can be a two step process, REALLY IT CAN BE A TWO STEP PROCESS!
NOBODY READS THE EMPLOYMENT APPLICATION FORM, it has nothing to do with screening candidates. If you want to interview a candidate THEN have them complete the employment form.
"Please don't use uppercase for emphasis. If you want to emphasize a word or phrase, put asterisks around it and it will get italicized."
https://news.ycombinator.com/newsguidelines.html.
https://news.ycombinator.com/newsguidelines.html.
Yup. Having a crazy long form to fill out is madness. Here is my resume. That's all you need. I already did all the work for you.
I have stopped applying to places that require any more than a resume submission. Its just not worth my time.
I have stopped applying to places that require any more than a resume submission. Its just not worth my time.
Is hiring broken, or is it a symptom of deeper organizational issues?
When I browse European startup offers and I interview for some of those positions, I get the feeling that their endless list of requirements has more to do with having high developer turnover and lack of funds to build a team, rather than their CTO's desire to hire a programming demigod.
When I browse European startup offers and I interview for some of those positions, I get the feeling that their endless list of requirements has more to do with having high developer turnover and lack of funds to build a team, rather than their CTO's desire to hire a programming demigod.
"If you’ve ever been on either end of the table, you’re probably mad at the state of hiring, too. Whether you have given it a lot of thought or whether you just feel it deep down, something about the whole process feels off."
This feels like a really big assumption. Is it true? Is there data to back this?
I've felt annoyed at individual interviewers, or a process at a given company but I've in general felt like I got more of a fair shake in the tech world than other industries I've worked in.
This feels like a really big assumption. Is it true? Is there data to back this?
I've felt annoyed at individual interviewers, or a process at a given company but I've in general felt like I got more of a fair shake in the tech world than other industries I've worked in.
I also cannot agree with the sentiment you quoted. But I appreciate that it's possible - and in fact extremely likely - that the author's experiences and mine are fully disjoint. Different sides of the world and FAANG vs smaller businesses need not have the same hiring challenges.
Bad companies are bad at hiring, good companies tend to be good at it. In most cases as efficient as they can be if you understand their constraints.
Lots of "good companies" have terrible hiring processes, in part because they're sufficiently famous and prestigious that they can be really bad at hiring - like proudly advertising a 2 month long process - and still hire enough qualified software engineers. I don't think it's correlated.
TLDR
Interviewing.io is different from other recruiting startups because verified candidates get to directly book time slots with engineers at companies. Candidates get verified by taking multiple mock interviews (more data points).
Other competitors, such as Triplebyte, still have a recruiter in between interview and company. Even after you get verified and have good performance on the Triplebyte quiz and interview, there is still a recruiter who acts as a gatekeeper. That recruiter can prevent you from speaking to companies even if your interview performance was 99% percentile.
Interviewing.io is different from other recruiting startups because verified candidates get to directly book time slots with engineers at companies. Candidates get verified by taking multiple mock interviews (more data points).
Other competitors, such as Triplebyte, still have a recruiter in between interview and company. Even after you get verified and have good performance on the Triplebyte quiz and interview, there is still a recruiter who acts as a gatekeeper. That recruiter can prevent you from speaking to companies even if your interview performance was 99% percentile.
If there's anyone that I'd listen to talk about this, it's Aline. She's a shining example of something I think patio11 once wrote: dogged learning about one topic is bound to produce value sooner or later. You just need to spend enough time learning where the pain points are, and build something that solves them.
She's been turning this crank for years, and I believe her when she cites interviewing.io having a 40% successful place rate.
She's been turning this crank for years, and I believe her when she cites interviewing.io having a 40% successful place rate.
> I believe her when she cites interviewing.io having a 40% successful place rate.
Is that from a different piece? The only 40% figure in the article is in reference to reasons for people using the platform, not conversion rate...
Is that from a different piece? The only 40% figure in the article is in reference to reasons for people using the platform, not conversion rate...
I'd almost advocate maybe even providing less signaling, like a technical chat-roulette where you get put into a pool and both sides can just "NOPE" out at any time if the interaction isn't sparking joy. Only when you build a rapport talking about the kind of work and challenges does it allow you to say: okay, let's meet later in an attributable fashion for real.
Also, bonus points if it involves OTR/PFS so you can talk details without attribution and know that since you're in a "pool" if you got through to an identifiable, in-person interview you can pretend like it never happened, but the candidate and the engineer both at some point definitely interacted in a way that they both felt comfortable proceeding to that point.
Also, bonus points if it involves OTR/PFS so you can talk details without attribution and know that since you're in a "pool" if you got through to an identifiable, in-person interview you can pretend like it never happened, but the candidate and the engineer both at some point definitely interacted in a way that they both felt comfortable proceeding to that point.
This does not work for introverts that are fantastic at their jobs
I think it's important to distinguish "introvert" from "lacks social skills". I'm introverted in the sense that social interaction drains my energy and solitude recharges it (with the stereotypical consequences like I don't like parties qua parties). However, I have good social skills in that I can make almost anyone like me, quickly. That is extremely useful in both getting hired and keeping a job.
wow. are you me ? :)
Hope this gets fixed some day.
I've been seeing this sentiment a lot on LinkedIn, particularly with new developers entering the field. Leaving aside the whole argument about whether or not we should really be calling software developers engineers, a lot of these same people are advertising themselves as full-stack. I'm sorry, but you going through a 10-week bootcamp or even getting a 4 year CS degree does not make you full-stack.
It's comparable to how we laugh at recruiters when they ask for 5 years in a given language that has only been around for 2 years. You clearly don't know what you're talking about.
I always tell the folks I mentor through bootcamps they should figure out which area they like best, focus most of their efforts in that area, and then advertise themselves as a front-end developer or back-end developer or whatever, not full-stack. The upside down T approach. Show recruiters and hiring managers you at least know enough to know what you don't know.
And stop complaining on LinkedIn about how unfair it is that you don't have a million job opportunities pouring in or about all the applications you submitted and didn't hear back from - yes it's annoying, but if you advertise yourself as something you're not, you've likely already wasted someone else's time, so understand they probably don't want to waste anymore giving you an explanation for why you were passed over.
It's comparable to how we laugh at recruiters when they ask for 5 years in a given language that has only been around for 2 years. You clearly don't know what you're talking about.
I always tell the folks I mentor through bootcamps they should figure out which area they like best, focus most of their efforts in that area, and then advertise themselves as a front-end developer or back-end developer or whatever, not full-stack. The upside down T approach. Show recruiters and hiring managers you at least know enough to know what you don't know.
And stop complaining on LinkedIn about how unfair it is that you don't have a million job opportunities pouring in or about all the applications you submitted and didn't hear back from - yes it's annoying, but if you advertise yourself as something you're not, you've likely already wasted someone else's time, so understand they probably don't want to waste anymore giving you an explanation for why you were passed over.
>I've been seeing this sentiment a lot on LinkedIn, particularly with new developers entering the field.
It honestly just amounts to "The most well compensating jobs with the most competition to attain them have a difficult application process, and that is unfair (to me) because of X, Y or Z". These posts are positively dripping in grandiose levels of entitlement.
It honestly just amounts to "The most well compensating jobs with the most competition to attain them have a difficult application process, and that is unfair (to me) because of X, Y or Z". These posts are positively dripping in grandiose levels of entitlement.
If you can write a web page that submits a user form and a server that writes that data to a persistent database ... I'm failing to see which part of the "stack" is unfilled. This is what bootcamps teach.
Yes, bootcamps teach you the basics of each part of the stack. I would make the argument that you aren't proficient in any of these areas, so to advertise yourself as such is misleading. I file my own taxes, but I don't refer to myself as an accountant.
I've yet to meet a bootcamp grad that can efficiently architect a relational database, for example. I know plenty of Sr. level front-end developers who wouldn't think to call themselves full-stack even though they know how to submit a user form that persists to the database. Same with back-end developers who know HTML, CSS, and pick your flavor of JS framework.
If you've worked in the industry, you know things change too fast to stay up to speed on everything. It's not impossible, but it's unlikely and unrealistic to have that expectation of someone once they are employed.
I've yet to meet a bootcamp grad that can efficiently architect a relational database, for example. I know plenty of Sr. level front-end developers who wouldn't think to call themselves full-stack even though they know how to submit a user form that persists to the database. Same with back-end developers who know HTML, CSS, and pick your flavor of JS framework.
If you've worked in the industry, you know things change too fast to stay up to speed on everything. It's not impossible, but it's unlikely and unrealistic to have that expectation of someone once they are employed.
Being full-stack does not mean you are a HTML and CSS expert. Anyone hiring a full-stack dev should know that. Full-stack means you can create a functional web application. It doesn't have to be in the latest JS library.
Many non-tech employers careless about your stack, as long as the application performs the tasks they want and the cost is reasonable.
A full stack dev most likely won't be an expert in any particular area but should have a good understanding of the web so they can pick up different JS libraries, web frameworks easily.
Many non-tech employers careless about your stack, as long as the application performs the tasks they want and the cost is reasonable.
A full stack dev most likely won't be an expert in any particular area but should have a good understanding of the web so they can pick up different JS libraries, web frameworks easily.
Just call yourself a web developer then. Does someone outside of the tech world really know what full-stack means without an explanation?
And also, I don't consider full-stack exclusive to the web. Desktop apps, for example.
And also, I don't consider full-stack exclusive to the web. Desktop apps, for example.
"full stack" is a pretentious term web devs made up for themselves.
You're missing the edge, which is very very broad.
Suppose your employer wants your web app to interface with an industrial PLC, or fetch data from a car's CAN bus, or talk to a vending machine (ironically the sort of machine that Java was originally designed for).
Most bootcamps don't teach enough fundamentals for someone to figure out how to write both client- and server-side code for those sorts of situations.
Or on the other end of the spectrum, could you write hypervisor code to manage the sort of mass-scale VM deployments behind most cloud providers? It would be very difficult to be an expert on the "full stack", if you think about it.
So...tl;dr, most of the application layer? Probably the physical layer too, any how many of us really work with the link layer?
Suppose your employer wants your web app to interface with an industrial PLC, or fetch data from a car's CAN bus, or talk to a vending machine (ironically the sort of machine that Java was originally designed for).
Most bootcamps don't teach enough fundamentals for someone to figure out how to write both client- and server-side code for those sorts of situations.
Or on the other end of the spectrum, could you write hypervisor code to manage the sort of mass-scale VM deployments behind most cloud providers? It would be very difficult to be an expert on the "full stack", if you think about it.
So...tl;dr, most of the application layer? Probably the physical layer too, any how many of us really work with the link layer?
Yup. People don't realize how many applicants literally can't even pass FizzBuzz, or some slightly more complicated variant. It is not just a meme. Dunning–Kruger.
I see this a lot on forums, blogs, Reddit, etc. but after having interviewed many candidates, I have yet to see someone that incompetent.
My company is not a hot Silicon Valley tech company either. It's a dull, boring, investment bank. I am generally not impressed at the quality level of most of the candidates we get when we hire. But still 100% of them are able to code more than well enough to pass FizzBuzz.
Now throw anything beyond the easiest of leetcode easy level questions at them and the majority will struggle. But that is still a level above Fizzbuzz and the like. And most come from backgrounds where the last job they were hired for did not leetcode them, but rather relied on language/framework trivia type interviews.
My company is not a hot Silicon Valley tech company either. It's a dull, boring, investment bank. I am generally not impressed at the quality level of most of the candidates we get when we hire. But still 100% of them are able to code more than well enough to pass FizzBuzz.
Now throw anything beyond the easiest of leetcode easy level questions at them and the majority will struggle. But that is still a level above Fizzbuzz and the like. And most come from backgrounds where the last job they were hired for did not leetcode them, but rather relied on language/framework trivia type interviews.
I have, personally, interviewed a senior software engineer candidate, claiming 8+ year of experience coding, who could not write a simple 5-minute exercise, in any language of his choosing. It wasn't FizzBuzz exactly, but if I'd thought to ask FizzBuzz, he'd have busted that as well.
"Write a function that takes a set of numbers [array, list, or equivalent] and returns the average."
Couldn't even get started.
I was the third interviewer. He'd BSed his way past the phone screen and two others and I caught a whiff of "Johnny can't code" and decided to check by asking him one of our new college grad questions.
There have been many more who bombed terribly in a manner that leaves me doubting whether they could solve FizzBuzz given an hour.
I don't doubt your beliefs, but I am surprised that you've not found any candidates who cannot possibly code at all. That probably speaks well to whatever upstream filtering process your firm is using (it would be ironic if it was "coding FizzBuzz using this online coding platform").
"Write a function that takes a set of numbers [array, list, or equivalent] and returns the average."
Couldn't even get started.
I was the third interviewer. He'd BSed his way past the phone screen and two others and I caught a whiff of "Johnny can't code" and decided to check by asking him one of our new college grad questions.
There have been many more who bombed terribly in a manner that leaves me doubting whether they could solve FizzBuzz given an hour.
I don't doubt your beliefs, but I am surprised that you've not found any candidates who cannot possibly code at all. That probably speaks well to whatever upstream filtering process your firm is using (it would be ironic if it was "coding FizzBuzz using this online coding platform").
My priors for “is nervous in interviews and gets flustered” are significantly higher than for “can’t code fizbuzz and somehow kept their previous jobs”.
This meme has been going around for ages (at least since Spolsky wrote about it) but I really doubt it is as common as people think.
I think it’s still rational to pass on someone who got stage fright, since in that case you have no signal on which to make an assessment. But I think the “can’t code” rationalization does candidates a disservice.
Interviewing is really stressful for many candidates! I encourage interviewers to remember this and treat candidates with compassion; maybe they can tell you think they can’t code, and that makes them more flustered. Vs. a joke about how interviews are stressful that might put them more at ease.
This meme has been going around for ages (at least since Spolsky wrote about it) but I really doubt it is as common as people think.
I think it’s still rational to pass on someone who got stage fright, since in that case you have no signal on which to make an assessment. But I think the “can’t code” rationalization does candidates a disservice.
Interviewing is really stressful for many candidates! I encourage interviewers to remember this and treat candidates with compassion; maybe they can tell you think they can’t code, and that makes them more flustered. Vs. a joke about how interviews are stressful that might put them more at ease.
It's quite common but how common depends a lot on where you get your candidate stream from. In my experience it's never to do with stage fright. The candidates don't seem flustered. They just cannot program. Even if it was stage fright, so what? Instant no hire. Your work will be evaluated by people post-hiring too: you have to be able to perform the job you are hired for when asked to do so. Panicking the moment you're asked to do your job is an excellent indicator you should not be in the team.
At my current firm, I hired most of the engineering team. In the early days we relied heavily on website applications and external agencies. A non-trivial number of candidates would struggle with a task like "read a text file into memory and print out the lines". Not FizzBuzz, if anything that's even easier: FizzBuzz trips up some inexperienced candidates because they don't know about the modulo operator, which is relatively rarely used. But almost any kind of program will use files.
At some point we started pulling sourcing and recruiting in-house. We also dropped some bad agencies and got a bit more savvy about which ones were cheating. The candidate stream got better at that point and total failure became less common. Unacceptably poor performance was still a frequent issue though.
Disappointingly, to me, a lot of candidates and even people we hired would try to claim that asking candidates to load a text file from disk was somehow unfair because "real programmers" don't work with files anymore, they just use web frameworks to do everything. Needless to say, that was not the kind of software engineer we were trying to hire.
At my current firm, I hired most of the engineering team. In the early days we relied heavily on website applications and external agencies. A non-trivial number of candidates would struggle with a task like "read a text file into memory and print out the lines". Not FizzBuzz, if anything that's even easier: FizzBuzz trips up some inexperienced candidates because they don't know about the modulo operator, which is relatively rarely used. But almost any kind of program will use files.
At some point we started pulling sourcing and recruiting in-house. We also dropped some bad agencies and got a bit more savvy about which ones were cheating. The candidate stream got better at that point and total failure became less common. Unacceptably poor performance was still a frequent issue though.
Disappointingly, to me, a lot of candidates and even people we hired would try to claim that asking candidates to load a text file from disk was somehow unfair because "real programmers" don't work with files anymore, they just use web frameworks to do everything. Needless to say, that was not the kind of software engineer we were trying to hire.
Usually the candidate pipeline is:
1. External recruiter shotguns out candidates to my team manager. Having been on the other side of this process myself, any vetting the external recruiter does is pretty minimal and purely behavioral.
2. Our manager passes around resumes to the team, and we collectively review them and give a thumbs up or down based on how subjectively we are impressed by it.
3. Manager assigns the more senior members of the team to conduct phone screens. Typically we throw some of the easiest of the easiest leetcode questions, or very simple "implement this in JS" questions. I personally have failed people at this stage mostly for communication or behavioral issues.
4. On-site. Combination of easy leetcode questions and "implement this in JS" questions. I can honestly, proudly, say that my team does not look for hyperoptimal perfect leetcode solutions - we genuinely focus on the communication process more. Part of the reason for this is, as I mentioned before, most of the candidates we get would struggle at all but the easiest leetcode questions and we cannot afford to be picky. We're not a hot tech company. We're a boring investment bank.
Very, very rarely we get a candidate that has worked at a hot tech company - even a FAANG occasionally. Their candidacy gets treated like a celebrity. But so far all such candidates have been turned down by my manager's manager because "they don't have enough business (finance/trading) knowledge". Never mind that most of our current team has extremely little to no such business knowledge too. In any case I doubt we could match the level of compensation they might be wanting.
1. External recruiter shotguns out candidates to my team manager. Having been on the other side of this process myself, any vetting the external recruiter does is pretty minimal and purely behavioral.
2. Our manager passes around resumes to the team, and we collectively review them and give a thumbs up or down based on how subjectively we are impressed by it.
3. Manager assigns the more senior members of the team to conduct phone screens. Typically we throw some of the easiest of the easiest leetcode questions, or very simple "implement this in JS" questions. I personally have failed people at this stage mostly for communication or behavioral issues.
4. On-site. Combination of easy leetcode questions and "implement this in JS" questions. I can honestly, proudly, say that my team does not look for hyperoptimal perfect leetcode solutions - we genuinely focus on the communication process more. Part of the reason for this is, as I mentioned before, most of the candidates we get would struggle at all but the easiest leetcode questions and we cannot afford to be picky. We're not a hot tech company. We're a boring investment bank.
Very, very rarely we get a candidate that has worked at a hot tech company - even a FAANG occasionally. Their candidacy gets treated like a celebrity. But so far all such candidates have been turned down by my manager's manager because "they don't have enough business (finance/trading) knowledge". Never mind that most of our current team has extremely little to no such business knowledge too. In any case I doubt we could match the level of compensation they might be wanting.
Well, it is not FizzBuzz, but the challenge I ask as a "evidently bad" filter ( http://challenge.paystand.mx/challenge ) is just a couple of GET / POST requests .
You would not imagine how many people (fortunately) get filtered by this step.
You would not imagine how many people (fortunately) get filtered by this step.
I can imagine an embedded developer unable to do that, they never do HTTP requests and it's a nightmare to implement in C or C++, a web developer in python/ruby/node should do fine.
It's selecting for languages and candidates with built-in support for HTTP and json and base64. It's far from a 1h problem if the candidate has to find working libraries for each of that.
It's selecting for languages and candidates with built-in support for HTTP and json and base64. It's far from a 1h problem if the candidate has to find working libraries for each of that.
Depends on an embedded developer.
It is very handy to know TCL or Python so you can script your hardware or create provisioning/testing scripts.
And with the whole IOT thing, HTTP requests in C became much more common.
Deffinitely right. This is for positions in a SaaS company where the developer would be mostly doing backend or frontend code.
That looks like an excellent exercise, going to save that :)
Thank you! yeah. I designed it with a thought in mind: A lot of the "exercises" or "challenges" that I see people ask for interviews are mainly stupid leetcode type puzzles that do not really reflect what you will be doing on the job.
I wanted to do a challenge that really reflected the stuff that we are doing at Paystand. When you are building a Web based SaaS application, the majority of time you will be a) Interfacing with crappy APIs. b) Doing simple processing in your logic (hence the string processing and sorting), c) Dealing with GET and POST requests in JSON
That's all I tried to present in the challenge. And if you read it, you will see that it gives A LOT of hints. There's even people who have asked me why do I give so many "clues". But on the other side I have gotten candidates that email me to ask me why they API call is returning an error (it is there in the notes that you must use the proper HTTP header). People are lazy, people don't read, and those are not suitable candidates for us.
I wanted to do a challenge that really reflected the stuff that we are doing at Paystand. When you are building a Web based SaaS application, the majority of time you will be a) Interfacing with crappy APIs. b) Doing simple processing in your logic (hence the string processing and sorting), c) Dealing with GET and POST requests in JSON
That's all I tried to present in the challenge. And if you read it, you will see that it gives A LOT of hints. There's even people who have asked me why do I give so many "clues". But on the other side I have gotten candidates that email me to ask me why they API call is returning an error (it is there in the notes that you must use the proper HTTP header). People are lazy, people don't read, and those are not suitable candidates for us.
Totally agree on all points. I don’t think it gives too many hints at all, in fact it feels very much like a half-baked product spec that you’ll probably have to deal with on the job as well :p
Also the point isn’t to demolish the interviewee with a difficult question, it’s to get a feel for how they are to work with (and of course, if they know the basics at all)
Also the point isn’t to demolish the interviewee with a difficult question, it’s to get a feel for how they are to work with (and of course, if they know the basics at all)
I haven't personally, but my ex-wife is a developer at a FAANG and she told me multiple stories of people she phone screened who couldn't actually write a simple for loop.
I don't think it's specifically FAANG but the staggering renumeration they offer IME seems to mean they [disproportionately] attract the naïve. It maybe doesn't help that the perception is that tech giants have very large numbers of developer jobs involving non-complex work that pays extremely well, and that very basic "coding" skills are valuable.
Anecdata, but from five years helping beginners through a popular online curriculum, this pattern is ridiculously common:
1. Beginner learns some HTML/CSS over the course of a few weeks.
2. Start on the JS curriculum, get stuck immediately.
3. Start to ask in forum if there are jobs [at a FAANG] just involve knowing HTML/CSS.
4. Very polite and detailed replies start to appear on forum of the form "well, it doesn't hurt to try but you might want to bear in mind that at entry level you're competing against people who have years of learning behind them", or "maybe just try to work through the slightly harder bits of the curriculum first (bearing in mind that even that isn't going give you a deep knowledge of the subject on its own)".
5. Few months later the beginner reappears talking about how they've applied to x number of jobs with no responses. And they start asking about how to get jobs working freelance. Moderators take some diazepam and start putting together more polite replies.
Anecdata as I can only see a tiny slice of self-learners via the forum; I feel for your ex though
Anecdata, but from five years helping beginners through a popular online curriculum, this pattern is ridiculously common:
1. Beginner learns some HTML/CSS over the course of a few weeks.
2. Start on the JS curriculum, get stuck immediately.
3. Start to ask in forum if there are jobs [at a FAANG] just involve knowing HTML/CSS.
4. Very polite and detailed replies start to appear on forum of the form "well, it doesn't hurt to try but you might want to bear in mind that at entry level you're competing against people who have years of learning behind them", or "maybe just try to work through the slightly harder bits of the curriculum first (bearing in mind that even that isn't going give you a deep knowledge of the subject on its own)".
5. Few months later the beginner reappears talking about how they've applied to x number of jobs with no responses. And they start asking about how to get jobs working freelance. Moderators take some diazepam and start putting together more polite replies.
Anecdata as I can only see a tiny slice of self-learners via the forum; I feel for your ex though
I wonder how much of this is a FAANG problem only due to how much they pay entry-level jobs, and invite people trying to, effectively, win the lottery.
People don't realize how many forum commenters literally don't know what "Dunning-Kruger" means.
Eh, I think it's fine. If you're going in at entry level, your expertise won't be that deep, but full-stack just means open to joining a team that does front-end, back-end or both. The typical bootcamp grad can develop into a specialist or generalist as they go, given support and resources.
I think saying you are full-stack is misleading and it sets job-seekers up for failure. And I would argue it's not fine, since it's these same types of people whining about what terrible luck they are having (purely anecdotal of course).
A few ideas that I think would give these grads some better luck:
- Update your profile to say "Interested in joining a front-end or back-end team" or "tech generalist with a focus on X"
- Elaborate even further in your About section and let people know which of the two you are stronger in and what experience you have
- Swap out "full-stack" for "web developer"
Don't tell me you're something you're not. Under-promise, over deliver. Seeing full-stack on a resume sets my expectations for whoever I'm about to interview regardless of the number of years of experience.
edit: styling
A few ideas that I think would give these grads some better luck:
- Update your profile to say "Interested in joining a front-end or back-end team" or "tech generalist with a focus on X"
- Elaborate even further in your About section and let people know which of the two you are stronger in and what experience you have
- Swap out "full-stack" for "web developer"
Don't tell me you're something you're not. Under-promise, over deliver. Seeing full-stack on a resume sets my expectations for whoever I'm about to interview regardless of the number of years of experience.
edit: styling
This assumes that they are applying to companies with separate frontend and backend teams. My company only has one small team so we all do a bit of everything: frontend web, react native app, backend, ops stuff. We'd never hire someone who was only front-end or only backend because that would leave half the job they weren't doing. But we have hired junior engineers who have only a little professional experience.
Seeing full-stack on a resume shouldn't set any expectations other than they have and intend to continue working on both front-end and backend code.
Seeing full-stack on a resume shouldn't set any expectations other than they have and intend to continue working on both front-end and backend code.
I'm not sure if you're a hiring manager, but I am. In my experience, what someone writes regarding their "stackness" means nothing to me. It only matters to the extent that it matches recruiter searches. I care about someone's practical experience, their fit for my team's work, and their ability to learn and adapt.
I'm not a hiring manager, but I've interviewed plenty and given my opinions to the hiring managers. I've also discussed candidates with fellows developers and have heard "that's not a full-stack developer" more times than I can count, which leads to "I'm not sure they know what they are talking about."
The point of my response is to say, if something isn't working, change the formula. Here's some anecdotal evidence given my experience that might help. Stop complaining on LinkedIn about it. I personally look at LinkedIn and if I see multiple posts from you complaining about how unfair things are it's going to be an immediate pass.
The point of my response is to say, if something isn't working, change the formula. Here's some anecdotal evidence given my experience that might help. Stop complaining on LinkedIn about it. I personally look at LinkedIn and if I see multiple posts from you complaining about how unfair things are it's going to be an immediate pass.
full stack is a front-end engineer and they're willing to deal with the shitty JS stack.
My personal experience interviewing for "full stack" and "front end" roles.
Full stack interview tracks seem to be identical to backend/generalist tracks. Purely leetcode questions up the wazoo.
Some front end interview tracks are the same. But I'm seeing more and more cases where they will throw "implement feature X in JavaScript" type questions, not leetcode.
Full stack interview tracks seem to be identical to backend/generalist tracks. Purely leetcode questions up the wazoo.
Some front end interview tracks are the same. But I'm seeing more and more cases where they will throw "implement feature X in JavaScript" type questions, not leetcode.
I always understood full-stack as "willing to work on both server and client side". In opposition from people who work only on frontend or only on server.
Everybody talks about how hard it is to tell a good engineer from about one. I've been thinking about what exactly that means in terms of our day-to-day.
If 10% of the work you're doing this quarter is work that you are going to be doing next quarter, you'll need to be interviewed differently than if 90% of the work you're doing this quarter is work that you're going to be doing next quarter.
If the job is narrow and predictable enough, you can just assess somebody's ability to do the tasks you will ultimately need them to do. if the job is broad and unpredictable enough, you have to assess it by proxy. Like how due to the long tail of word usage [0], it's easier to just talk to somebody to see if they are fluent, rather than quizzing them on words.
I wonder if software engineering is in some weird anti-sweet spot, where our breadth of work isn't so broad that we really need many year degrees and licenses and boards, but isn't narrow enough that you can just assess somebody on the actual duties you want them to be performing.
Not to mention that different jobs in the field really do have different degrees of unpredictability/variety, so the breadth experienced in a few years at one shop would be completely different from the narrowness experienced in a few years at another, so a resume doesn't you tell as much as you'd hope.
[0] A full 50% of the words in Tom Sawyer only occur once, for example. It's why teaching languages can only go so far, and you really just get lots of experience using a language to become proficient.
If 10% of the work you're doing this quarter is work that you are going to be doing next quarter, you'll need to be interviewed differently than if 90% of the work you're doing this quarter is work that you're going to be doing next quarter.
If the job is narrow and predictable enough, you can just assess somebody's ability to do the tasks you will ultimately need them to do. if the job is broad and unpredictable enough, you have to assess it by proxy. Like how due to the long tail of word usage [0], it's easier to just talk to somebody to see if they are fluent, rather than quizzing them on words.
I wonder if software engineering is in some weird anti-sweet spot, where our breadth of work isn't so broad that we really need many year degrees and licenses and boards, but isn't narrow enough that you can just assess somebody on the actual duties you want them to be performing.
Not to mention that different jobs in the field really do have different degrees of unpredictability/variety, so the breadth experienced in a few years at one shop would be completely different from the narrowness experienced in a few years at another, so a resume doesn't you tell as much as you'd hope.
[0] A full 50% of the words in Tom Sawyer only occur once, for example. It's why teaching languages can only go so far, and you really just get lots of experience using a language to become proficient.
This article is not talking about how broken Google-style algorithmic interviews are. It's encouraging Google-style algorithmic interviews by bringing them to the candidate as soon as possible. This is achieved by making candidates pay money for mock interviews with interviewers from tech companies.
This fundamental problem this article is describing is that recruiters are filtering out too many candidates by pedigree to ever have them end up in an algorithmic interview with a tech company.
This fundamental problem this article is describing is that recruiters are filtering out too many candidates by pedigree to ever have them end up in an algorithmic interview with a tech company.
How important is your pedigree in getting a (good) tech job? If you've worked as a SWE in some capacity, it seems like most companies (even top ones) consider you good enough to at least interview you.
My pedigree is average at best. I've worked my entire career at non-tech companies (banks, hedge funds) doing decidedly unsexy work. I'm still able to attract enough attention that FAANG and many other top tech company recruiters contact me first.
Interestingly enough, it's the top companies in my current sector (finance) that refuse to even have an internal recruiter casually speak with me. i.e. Citadel, Two Sigma, Jane Street, etc.
There's also stories I see occasionally on LinkedIn, etc. of people from completely non-technical backgrounds getting hired as SWEs at top tech companies. Taxi drivers, ex-felons, aestheticians, etc. getting hired as SWEs at FAANG and unicorns.
My pedigree is average at best. I've worked my entire career at non-tech companies (banks, hedge funds) doing decidedly unsexy work. I'm still able to attract enough attention that FAANG and many other top tech company recruiters contact me first.
Interestingly enough, it's the top companies in my current sector (finance) that refuse to even have an internal recruiter casually speak with me. i.e. Citadel, Two Sigma, Jane Street, etc.
There's also stories I see occasionally on LinkedIn, etc. of people from completely non-technical backgrounds getting hired as SWEs at top tech companies. Taxi drivers, ex-felons, aestheticians, etc. getting hired as SWEs at FAANG and unicorns.
My experience interviewing with hedge funds is that they expect candidates to be working with an external recruiter.
I think at least half of the reason for that is that it makes it easier for them to see your pst salary / bonus.
Yup - seems that's the way it works in finance. External recruiter sends my resume to a firm, internal recruiter then does a casual chat with me, and assuming I don't throw any red flags, I proceed to the coding phone screen.
Multiple external recruiters have attempted to submit me to Citadel and Two Sigma over the course of the past five years. I always tell the recruiter I've never heard back from them in the past, but they're always confident that they can vouch for me and get me an interview. Of course, I never hear back and the recruiter is puzzled.
Multiple external recruiters have attempted to submit me to Citadel and Two Sigma over the course of the past five years. I always tell the recruiter I've never heard back from them in the past, but they're always confident that they can vouch for me and get me an interview. Of course, I never hear back and the recruiter is puzzled.
> How important is your pedigree in getting a (good) tech job?
Working at a well-known company can definitely help open doors. It proves that you’ve already completed their challenging interview process and it’s also assumed that you picked up some good engineering practices while working there.
However, pedigree alone won’t get you jobs at most places. You still have to go through the interview so they can see how you perform on a level playing field.
As much as online comments hate the coding challenge interview problems, they’re actually a great thing for people without impressive career pedigrees. It’s the only way you’re going to get to compete on a somewhat level playing field next to the kid who went to an Ivy League and landed all the right internships due to their parents’ connections.
Generally speaking, it’s the people who have jobs at well known companies who want to get rid of coding challenges and go back to hiring based on pedigree, mostly because it benefits them greatly and reduces their competition. In reality, anyone talented enough to work at top companies doesn’t have to study much for coding interviews. This idea that coding interviews are somehow filtering out brilliant engineers and selecting for less qualified people is largely a myth. The reality is that engineers just don’t like being challenged on the spot and would rather employers just trust their resume. That is, if they already have a good resume. The juniors love coding challenges because it’s a way to prove your skills without relying on pedigree or university or family connections.
Working at a well-known company can definitely help open doors. It proves that you’ve already completed their challenging interview process and it’s also assumed that you picked up some good engineering practices while working there.
However, pedigree alone won’t get you jobs at most places. You still have to go through the interview so they can see how you perform on a level playing field.
As much as online comments hate the coding challenge interview problems, they’re actually a great thing for people without impressive career pedigrees. It’s the only way you’re going to get to compete on a somewhat level playing field next to the kid who went to an Ivy League and landed all the right internships due to their parents’ connections.
Generally speaking, it’s the people who have jobs at well known companies who want to get rid of coding challenges and go back to hiring based on pedigree, mostly because it benefits them greatly and reduces their competition. In reality, anyone talented enough to work at top companies doesn’t have to study much for coding interviews. This idea that coding interviews are somehow filtering out brilliant engineers and selecting for less qualified people is largely a myth. The reality is that engineers just don’t like being challenged on the spot and would rather employers just trust their resume. That is, if they already have a good resume. The juniors love coding challenges because it’s a way to prove your skills without relying on pedigree or university or family connections.
> They wisely rejected pedigree as a viable means of credentialing and adopted the admirable mission of democratizing access to opportunity in software engineering.
You know that college admissions are just as "democratic" as somebody's online testing process, right? As in, anybody can take the test and if they pass, they get admitted? Like... they're exactly the same concept?
You know that college admissions are just as "democratic" as somebody's online testing process, right? As in, anybody can take the test and if they pass, they get admitted? Like... they're exactly the same concept?
> Breaking character for a moment, a friend of mine recently got this recruiting email from Google, who has elevated gaslighting to an art form
God I love Aline's stuff.
God I love Aline's stuff.
The thing that companies fail to do is reconcile hiring decisions with performance reviews afterwards. They have a single hiring practice and they NEVER EVER change it, regardless of the quality of the eventual hires.
The missing feedback loop from performance review back to the hiring process means that the hiring process can't get fixed. Until companies start adding that process back in, hiring will never get better.
The missing feedback loop from performance review back to the hiring process means that the hiring process can't get fixed. Until companies start adding that process back in, hiring will never get better.
I think it's complicated by the fact that the better the company, they better they are at mentoring even "bad" hires. I.e., performance review isn't normalized across all companies. Google might think their hiring process is great because a lot of their hires do well in their performance review - but maybe that has more to do with the engineering culture and mentorship in the company, and less to do with their ability to pick future winners.
Perhaps though if one looks at the performance review weighted to a review date as soon after the hiring, and sort of tail off how much weight is given over the coming years it'd make sense.
I've just seen a lot of bad hires get better with time. And some good hires lose steam or become jaded and perform worse over time.
Thus, as messed up as it is, one of the keenest signals is tenacity in the end. And ironically tenacity in preparation for interviews (that Leetcode grind) is somewhat correlated with performance reviews in the long run and perhaps correlated with utility to the company.
That said, "decent" engineers in the long run that don't think outside the box but check their performance review boxes slowly bleed a company's ability to disrupt. I.e., performance reviews need to be expanded a bit to think about the health of the overall company and not just the employee performing their function.
As a large tech organization, I'd prefer a complex distribution of performances over an even distribution any day - because value to tech companies is still influenced by more black swan event type of innovation. But then I have a high "beta" (variation) in terms of what I'm looking for. Companies with more of a utility emphasis perhaps are better served by a hiring process that is "reliable" with a lot of false negatives.
Perhaps though if one looks at the performance review weighted to a review date as soon after the hiring, and sort of tail off how much weight is given over the coming years it'd make sense.
I've just seen a lot of bad hires get better with time. And some good hires lose steam or become jaded and perform worse over time.
Thus, as messed up as it is, one of the keenest signals is tenacity in the end. And ironically tenacity in preparation for interviews (that Leetcode grind) is somewhat correlated with performance reviews in the long run and perhaps correlated with utility to the company.
That said, "decent" engineers in the long run that don't think outside the box but check their performance review boxes slowly bleed a company's ability to disrupt. I.e., performance reviews need to be expanded a bit to think about the health of the overall company and not just the employee performing their function.
As a large tech organization, I'd prefer a complex distribution of performances over an even distribution any day - because value to tech companies is still influenced by more black swan event type of innovation. But then I have a high "beta" (variation) in terms of what I'm looking for. Companies with more of a utility emphasis perhaps are better served by a hiring process that is "reliable" with a lot of false negatives.
A company's hiring practice should reflect the type of engineer they want to hire. If they want to hire engineers that can start contributing immediately, and they hire engineers that need mentoring, then the hiring process is broken.
If they widen their expectations, and hire people that they believe they can mentor into net contributors, then their hiring practices should reflect this.
There are many ways a company can make hiring more scientific, including A/B testing (ie. hiring people they normally wouldn't, have more data around how productive new hires are, etc) but I've never seen it over than "copy Google and we should be good."
If they widen their expectations, and hire people that they believe they can mentor into net contributors, then their hiring practices should reflect this.
There are many ways a company can make hiring more scientific, including A/B testing (ie. hiring people they normally wouldn't, have more data around how productive new hires are, etc) but I've never seen it over than "copy Google and we should be good."
If someone becomes a net-contributor after some mentorship, were they really a bad hire?
I guess if they can take someone they would not have hired, and then mentored them to become a net-contributor, then the hiring process is broken. You can't really test this without hiring people you wouldn't normally hire based on your hiring process.
I agree that in general, feedback loops are important. But you had better be absolutely sure that you're measuring the right thing, because once you put it in place, your hiring process will begin to optimize around it. So unless you can write down precisely what it means to be a good whatever, you probably shouldn't expect feedback to solve your hiring problems.
Yeah, I think this is a more concise version of the point I was trying to make. And that perhaps "performance reviews" should be one of a couple of signals as feedback to the hiring process. There's just so many variables in play (covid-19, etc.) one has to be super careful about recognizing the right signals / causation, etc. Ideally one needs experiments about which signals or feedback to use in determining if it's a good hire in addition to experiments about different hiring process changes.
An issue with this is that it's inherently one-sided: you get to see the performance of the people you hire, but you have no idea what happens with the people you reject.
Because of that, you inevitably get "weird" results like seeing that your best employees often did relatively poorly on interviews (Google did a study that produced exactly that result—their best employees often were those that failed 1 or 2 of their interviews).
But this is just selection bias: these are candidates that got hired! Which just means that they were so spectacular in some other respect that they were able to get an offer /despite/ poor interview performance. It tells you nothing actionable about your interview process.
Really you need to take an experimental approach where you randomly give offers to people who failed the interview, and see how they turn out.
Because of that, you inevitably get "weird" results like seeing that your best employees often did relatively poorly on interviews (Google did a study that produced exactly that result—their best employees often were those that failed 1 or 2 of their interviews).
But this is just selection bias: these are candidates that got hired! Which just means that they were so spectacular in some other respect that they were able to get an offer /despite/ poor interview performance. It tells you nothing actionable about your interview process.
Really you need to take an experimental approach where you randomly give offers to people who failed the interview, and see how they turn out.
I guarantee that companies (at least large companies) do reconcile hiring decisions with performance review data. Google, at least, has entire teams of analysts focused on exactly this sort of analysis.
Fundamentally, hiring is simply not an easy problem. There's a small cohort of candidates who can be reasonably confident will perform well in a job (mostly people who have performed a similar job at a competitor) that everyone competes over and a marge larger group of candidates whose possible performance is very hard to judge.
Fundamentally, hiring is simply not an easy problem. There's a small cohort of candidates who can be reasonably confident will perform well in a job (mostly people who have performed a similar job at a competitor) that everyone competes over and a marge larger group of candidates whose possible performance is very hard to judge.
I believe Google does this reconciliation between hiring decision and performance reviews.
We shouldn't ask why engineering hiring is broken. We should ask how an industry with broken hiring can succeed. Software engineering has such ludicrous margins that the labor market for software engineers can be ludicrous in equal proportion.
The result is that we can bully and cajole smart, capable people, then go on to make 6 figure salaries and makes billions of dollars in revenue.
The result is that we can bully and cajole smart, capable people, then go on to make 6 figure salaries and makes billions of dollars in revenue.
Much to be said for this.
Platonic is an odd word to use in this context.
> Breaking character for a moment, a friend of mine recently got this recruiting email from Google, who has elevated gaslighting to an art form: somehow the fact that it takes two months to get through their process has become a selling point.
The quoted email in no way supports this statement.
The quoted email in no way supports this statement.
the statement is such a blatant indefensible lie I had to wonder if I stumbled on some kind of 'point deer make horse' [0] scenario.
[0] https://epochtimes.today/chinese-idiom-point-to-a-deer-and-c...
[0] https://epochtimes.today/chinese-idiom-point-to-a-deer-and-c...
> 'point deer make horse' [0]
Your link never glosses the saying as "point deer make horse". Why did you?
The grammar of the saying is normal, far more so than usual for these, and "make" is not the relevant sense of 為.
Your link never glosses the saying as "point deer make horse". Why did you?
The grammar of the saying is normal, far more so than usual for these, and "make" is not the relevant sense of 為.
[deleted]
anecdata here:
I once was asked to explain the difference between 2 functions in a standard library that I don't think I had ever used.
That was the only question I was asked. They completely wrote me off as soon as I couldn't answer the question.
If they had just asked me to write an entire app from scratch (not counting frameworks) I could've done that for them no problem :)
I once was asked to explain the difference between 2 functions in a standard library that I don't think I had ever used.
That was the only question I was asked. They completely wrote me off as soon as I couldn't answer the question.
If they had just asked me to write an entire app from scratch (not counting frameworks) I could've done that for them no problem :)
Unless you have engineering credentials from a recognized engineering body, then you’re not an engineer. Software developer, maybe. Engineer, no.
There are no reliable software engineering credentials in the US. But there are also no reliable electrical engineering credentials, and many other things. There is a P.Eng. (professional engineer) examination, but it's really most relevant for civil engineering, buildings, and the like, and unused in most other cases.
In the United States there are no licensure requirements for Software Engineering.
I'd like to see a "speed dating" concept implemented in tech hiring.
You, along with however many other candidates rotate around among different companies. You maybe work for each company up to 1 week. At the end you get your offers and decide among them.
I've ended up working for too many lemons because of lack of visibility into how well put together they really are. I want to know ahead of time whether they really have their ish together or if the interview bubble is just a facade.
You, along with however many other candidates rotate around among different companies. You maybe work for each company up to 1 week. At the end you get your offers and decide among them.
I've ended up working for too many lemons because of lack of visibility into how well put together they really are. I want to know ahead of time whether they really have their ish together or if the interview bubble is just a facade.
We already have something kind of like speed dating for hiring: job fairs. Your idea is more like a one night stand. It would be cool if there were large scale career fairs that are hosted outside of colleges open to the general public, and then there was some sort of organized process where people could talk one on one for some period of time with representatives of the top X companies they choose. Probably will need a basic filter so there aren't tens of thousands of people per company, and spread the interviews out over several days. You always hear about networking, but outside of exclusive groups that already require money or status to be a part of, there aren't opportunities for people who need each other to meet up in an organized way and get things done.
I'm not anticipating you'll read this, but for anyone who happens to read this part of the thread, I don't think job fairs are even close to what I described above. They serve similar purposes, but in my case described above, an actual hire will occur or it won't. Job fairs, at least the ones I've been to are more like an advertising kiosk in a mall where no one you're talking to has any authority of any kind let alone deciding whether or not to hire you on the spot :)
Also, at a job fair you have no idea what the day to day life will be in your new position. In my scenario, once you are or aren't hired you will have already lived the life you will be living if you are hired.
Also, at a job fair you have no idea what the day to day life will be in your new position. In my scenario, once you are or aren't hired you will have already lived the life you will be living if you are hired.
Why did the title change (on HN)? It now no longer matches the original article ("I’ve been an engineer and a recruiter. Hiring is broken. Here’s why… and what it should be like instead.") - contrary to HN guidelines[0]
[0]: https://news.ycombinator.com/newsguidelines.html
[0]: https://news.ycombinator.com/newsguidelines.html
I'm convinced that there is no generalized "right" way to do hiring - for engineers or otherwise. Considering "engineers" as a monolith is silly and the diversity of engineers makes any attempt to generalize fail.
Different types of people fit into different cultures and work styles.
If there's anything at all that I would generalize on, it would be: "Be candid about your work culture if hiring and don't try to work some place that doesn't fit your style if applying."
Different types of people fit into different cultures and work styles.
If there's anything at all that I would generalize on, it would be: "Be candid about your work culture if hiring and don't try to work some place that doesn't fit your style if applying."
> I could try some job boards to see which companies are out there. But what would I filter on? I know a lot of programming languages but am not set on having to work in a specific one. How can I tell if I’ll hit it off with the team? I’m applying via a job board to a position I know next to nothing about — will anyone even respond?
Man I really can't stand job boards. I feel like the only way to make a good job board would have to aggressively vet companies posting jobs, which ofc would lead to it being very barren.
Man I really can't stand job boards. I feel like the only way to make a good job board would have to aggressively vet companies posting jobs, which ofc would lead to it being very barren.
I've been known to write egregiously long comments, emails, articles, but good good is this article overly long. I was really ready to blow it off when I realized -- the author is putting her money where her mouth is. She's built a very useful platform that helps connect real people with real job opportunities.
Okay. In that case, I can forgive the "cardinal sin" of bad writing. Here's the problem with hiring: organizations. Hiring practices reflect organizational ladders and career progressions. Where you see flaws in the latter, of course it will backpropagate into the former. The problem with a "platonic ideal" for how engineering hiring should work is that it requires a "platonic ideal" for how a company should work. And what is that?
How do you avoid politics as you scale up a company? Sure, engineering skills are fungibly valuable, that much is evidenced by the market. But engineering career output, and promotional success -- that part is very circumstantial and specific to the company. And I would argue hiring is part of that process -- hiring is getting promoted from candidate to employee. Every company does it differently. And the dynamics are not platonic but tribal. There's no way around that but to find the tribe you want to be a part of and accept it's a little irrational.
I remember wishing and hoping when I was younger for a platonic ideal for engineering hiring and engineering organizations that never came. I grew to understand that the warfield of political economy that the business existed inside of (including and especially non-technical and executive personnel) had so much of a major impact on what engineering even means that to conceive of its retraction or engineering in isolation was a little naive and unrealistic. Is it cynical for me to say that? Is it bad for me to say that?
Okay. In that case, I can forgive the "cardinal sin" of bad writing. Here's the problem with hiring: organizations. Hiring practices reflect organizational ladders and career progressions. Where you see flaws in the latter, of course it will backpropagate into the former. The problem with a "platonic ideal" for how engineering hiring should work is that it requires a "platonic ideal" for how a company should work. And what is that?
How do you avoid politics as you scale up a company? Sure, engineering skills are fungibly valuable, that much is evidenced by the market. But engineering career output, and promotional success -- that part is very circumstantial and specific to the company. And I would argue hiring is part of that process -- hiring is getting promoted from candidate to employee. Every company does it differently. And the dynamics are not platonic but tribal. There's no way around that but to find the tribe you want to be a part of and accept it's a little irrational.
I remember wishing and hoping when I was younger for a platonic ideal for engineering hiring and engineering organizations that never came. I grew to understand that the warfield of political economy that the business existed inside of (including and especially non-technical and executive personnel) had so much of a major impact on what engineering even means that to conceive of its retraction or engineering in isolation was a little naive and unrealistic. Is it cynical for me to say that? Is it bad for me to say that?
> recruiters spend roughly 15 hours a hire, and engineers spend about 40.
15 hours can save you 15% on someone else’s salary.
I feel used....
15 hours can save you 15% on someone else’s salary.
I feel used....
6 hours on site for engineering interview is nuts.
For some recent interviews I have had 2 hour long interviews with 2-3 people in each, so 6 hours as a total seems realistic!
Too bad I didn't get paid for my time!
Too bad I didn't get paid for my time!
My problems with hiring:
1. Resume forms. Just accept a resume. I don't have time to fill out your form that requires exact months. 2. Not hearing back. Its not hard to send a response. The ones I really hate are "we get so many responses so we'll only contact you if we like you!" come one 3. Bad recruiters. The ones who just email and call about being an automotive technician when I'm an infrastructure engineer.
1. Resume forms. Just accept a resume. I don't have time to fill out your form that requires exact months. 2. Not hearing back. Its not hard to send a response. The ones I really hate are "we get so many responses so we'll only contact you if we like you!" come one 3. Bad recruiters. The ones who just email and call about being an automotive technician when I'm an infrastructure engineer.
Having been in the field for almost 15 years, it seems to me that hiring has always kind of been hit and miss and all these timed tech interviews don't really help much as they focus too much on just code or system design. But the majority of problems I have encountered have not been technically difficult. Once you create an application with a sound system design, all the other technical stuff isn't really a challenge.
Majority of the issues are caused by requirements not being communicated, captured, or implemented properly. That's something that's not really focused on tech interviews. I just want a diligent developer who can identify potential issues, do their research, and propose solutions rather than be able to design a system in 90 minutes, because that's never happening in real life. In fact, I'd not hire someone who can claim to do so.
Majority of the issues are caused by requirements not being communicated, captured, or implemented properly. That's something that's not really focused on tech interviews. I just want a diligent developer who can identify potential issues, do their research, and propose solutions rather than be able to design a system in 90 minutes, because that's never happening in real life. In fact, I'd not hire someone who can claim to do so.
This is a pretty good breakdown of the dynamics of software engineering hiring, even if I don't follow to her conclusions.
It seems like "abstraction" is a recurring theme. The hiring manager is abstracted from the job description by the recruiter. Whether by institutional affiliation or passing a quiz, candidates are abstracted into punch cards that can be fed through the system.
Furthermore there's a seemingly overwhelming institutional bias for companies to congratulate themselves on making the right hire, and for their employees for being the right hires, that the whole thing becomes kind of circular.
It seems like "abstraction" is a recurring theme. The hiring manager is abstracted from the job description by the recruiter. Whether by institutional affiliation or passing a quiz, candidates are abstracted into punch cards that can be fed through the system.
Furthermore there's a seemingly overwhelming institutional bias for companies to congratulate themselves on making the right hire, and for their employees for being the right hires, that the whole thing becomes kind of circular.
There is no meaningful data that any hiring process--good or bad--improves the outcome of a hire. If there were, everyone would be using it.
Instead, third-party HR monoliths have moved in and snatched up (and more or less created) the 'market' for screening and filtering applicants. Larger companies sigh, throw up their hands, and say 'well how else can we deal with hundreds of applicants?'.
As if that 'funnel' of applicants contains what you think you want. As if it's just an exercise in reductionism, each applicant a data point to evaluate.
Given this, why not hire lightly and fire lightly?