Hiring Is Broken and Isn’t Worth Fixing
daedtech.com
daedtech.com
Wow, OK. I suppose this is fine for someone who doesn't actually want a job, or in those rare times when the hiring market favors candidates. But in most cases, the company will just move on to the next resume in the pile. Why bother with this kook when there's a line of people outside eager to have a shot?
>“Hmm… you know what? I’m really sorry, but I think maybe we got our wires crossed somewhere here. I’ve had experience on the hiring side of this sort of interview style in the past, and I’ve seen it result in some really sub-optimal matches, so I’ve adopted a policy of having certain deal breaker cues in the interviewing process. So at this point I can safely say I’d be unlikely to accept an offer, and I really wouldn’t want to waste any more of your time."
Expected response: "Well........ Bye."
I appreciate the effort put into wording that nicely, but really all you're saying is, "Company, you need me more than I need you, and I expect YOU to jump through MY hoops." This is only true when you're a one-in-a-million talent. It's not going to work for the other 999,999 people.
The thing is, not all companies do this. And there a LOT of other companies besides Google and The Usual Suspects. Heck, there are a lot of companies that aren't "tech companies" but they still employ developers. And they are probably less likely to do the whole "grill you on Data Structures 101" thing than Google. It's something to consider...
Exactly this! IMO these are some of the best types of jobs too. You generally have real problems to solve and can see the impact you are making in the business.
Get in, figure out how things work and how you can be useful and then build a reputation of getting things done.
There is sometimes push back on implementing things partly because non tech doesn't always understand the benefit. But if you are good at explaining and showing how something will save them money by streamlining a process or make them money by reducing friction somewhere, you almost always get the green light.
I had an offer an hour later and this is a fantastic place to work.
I actively avoided places with broken processes and it paid off in spades.
I'll make the Work-Life Balance > Compensation choice every time.
This is about as 'real world' as we can make it, and it's generally worked out well. It's still problematic since it requires a physical block of time, and that eliminates some candidates who are currently working, but it's the best we've found so far.
1. Is it documented well enough that we can deploy and run the code ourselves?
2. Is the code clean, well structured, documented, etc.?
3. Does it run with no errors?
4. Does the output do a reasonable job of satisfying the requirements?
It's pretty open ended, which is itself a mixed blessing. Some people will look at it as an opportunity to really show off and show what they can do, and "flex their muscles" so to speak. Others may be intimidated by the lack of more detailed requirements. It's not a perfect test, but it works pretty well for us.
The one other risk is that the candidate will use a language that nobody here is qualified to evaluate (like FORTRAN), but in practice that hasn't been an issue.
I refuse to take captive positions partly because of the craziness in the workplace but also because I can make much more contracting then what most employers are willing to pay.
Funny thing is now you are starting to see companies looking to hire contractors and wanting to make the contractors jump through these silly hoops (taking silly quizzes, take home projects, etc.)
I always come back with a proposal that includes cost & timeline to complete the take home project. I have gotten a couple gigs that way :)
So she asks me, "How much of your time to I spend writing code?" I tell her, maybe 10%-20%. And then she jumps right into asking algorithm complexity questions and generic trivia: what is the average run time of quicksort, what is 356 in binary, estimate 2^20, etc. I was getting some of them right, some of them wrong, but eventually I had to stop her and say "Look, I don't really know what is going on right now. You told me you were contacting me based on my experience, but now you're asking questions that don't have anything to do with what I do. It sounds like the role you're trying to fill doesn't align well with my experience." That was pretty much the end of the conversation.
It's not even that I feel like I shouldn't get vetted. I should! But do it based on what I know. Ask me linear algebra trivia, or how robotics algorithms work and their time complexity, or ask me about topology or statistics or machine learning. Why are you grilling me on sorting algorithms?
I think if it works anywhere, it's going to be at smaller shops, where they don't have a line of candidates stretching around the block.
uh, no. he doesn't expect them to do anything, especially not jump through any hoops, because he doesn't want to work for them. end of story. that's it, there's no catch. have a nice life.
if you don't understand that, it's no wonder you're on the other side of this fence.
also, your use of the word "need" is telling of your mindset.
My time is more valuable to me than theirs. They jump through my hoops.
I get that in a good month, and 90% of them are clueless and inappropriate.
Which is... right now. I think this strategy could absolutely pay off. And your objection seems to be that if you say these things then the company isn't going to hire you - that's the point. It isn't a negotiation tactic, it's "I am taking this interview procedure as a reflection of the company as a whole and that gives me sincere reservations as to whether I'll be a good fit".
No, I wouldn't recommend this when you're fresh out of college. But many experienced developers absolutely do not know their worth - you shouldn't have to go through that crap when your resume clearly states you are capable.
As long as you have the right skills and live in the right area. I live in Dallas and want an embedded job. If it weren't for my clearance, nobody would give a shit about me.
No it is not. I have a job. I'm too busy taking time out of my day to explain concepts that I barely use and not going to be using at employer who is asking them. That is the broken part. They are passing up on good hires with irrelevant crap because some them don't have the time.
> Why bother with this kook when there's a line of people outside eager to have a shot.
Because the kook that refuses to explain merge sort might be better at the job than the guy who desperatly jumps through hoops.
Who cares if the kook is better if the other one is good enough? At some point, "better" hits diminishing returns and is no longer worth it. It's the reason "we only hire the top X%" attitude is wasteful bullshit for most companies.
Well the whole point throwing out CS trivia questions is to find the better candidate. It is the diminishing returns... by simply restricting your candidate pool to people that have the time to jump through hoops.
If a 10x programmer turns a 3x team into a 1x team, that super-genius isn't worth having.
And this is why I hate working with primadonnas who think they're brilliant.
Brilliant people can often be easygoing and a great benefit to their teams. They do it by moving the whole team forward. They're never 10x individually in that case, but they may elevate a 3x team to 5x.
edit: Find me an engineer who is both brilliant and humble, and I'll bend over backwards to hire that person.
And I suggest that 3X a small team may be less than 10X the one person. Maybe a better team is one that supports a brilliant developer, making a deliverable out of their prototype. That's another way to manage it.
The thing about programming is that it is a relatively easy form of automation of data processing, so whereas a single developer can have multiples of impact far greater than a traditional office worker, and sometimes even greater than the impact of a traditional office manager (because software is more scalable than people), you can get a multiplicative effect when you combine great programming with great programmer management and collaboration. This is where you'll find a lot of my programming heroes. For example, what Yehuda Katz did with Bundler in terms of gathering community input and hammering something into shape to solve a whole host of hairy problems with RubyGems which no single individual could completely grok is inspiring. The amount of impact a project like that has on the productivity of thousands is impossible to quantify. I guess Linus Torvalds would be the quintessential example of that, for his ability to channel the efforts of thousands of developers in a cohesive direction while maintaining an impressive standard of quality.
So being 10x, 100x, 1000x is possible, but it depends on working on the right problems with the right people.
Now, we all hate a lot of the above stuff, and many companies handle these things better than others, but it did mean the only reason he was "20x" was because he didn't do 90% of the stuff that was expected of everyone else.
Maybe the company culture needed to change, but until it did, everyone else looked really bad compared to him, even though they were essentially spending their time trying to deal with his crap without help.
I wouldn't call that person a 10x programmer. I think that the only meaningful way to define a 10x programmer is someone who has ten times the contribution to the company's bottom line of an average programmer (i.e., someone who would actually deserve to be paid ten times as much as an average programmer, but could probably be hired for far less than that). However, if someone produces 10x more code than the average programmer but "turns a 3x team into a 1x team", then their net productivity is negative and they should be immediately fired.
>Yea but he also might just be a person who only works on the stuff they like and shrek the other stuff.
Yeah normal interview questions can give answers to that.
Yes...and? That's why they're looking for someone. If you're confident in your skills, why would you be grateful for employment?
Aside from Apple, Google, Facebook, do companies have this? Hasn't industry been complaining constantly that there isn't enough talent?
"Expected response: "Well........ Bye.""
So? The person just expressed their intention to not work for the company. You're acting like the company choosing to pass is now a terrible consequence.
"Company, you need me more than I need you, and I expect YOU to jump through MY hoops."
They're not really asking them to jump through hoops. Just don't be stupid.
And yeah, the company needs workers more than the worker needs the company.
(I assume "on-in-a-million" is an exaggeration to mean "exceptional")
How skewed do you think the market is? Many here talk about developer shortage, suggesting an employee's market. But let's assume this is an employer's market, and the employers can really chose: how exceptional exactly does one have to be to afford to be picky about the interviewing process? My guess would be between one-in-ten to one-in-a-hundred. No more.
I think this is really about status. Employees have lower status than their employer. They owe them obedience and loyalty (by law in most countries). Employers even expect a fair bit of deference most of the time. They expect the prospective employee to "know her place", and that includes putting up with dubious trivia questions.
Sure, if you must work at some top hot shot reputable company, you need to put up with their processes, however silly or gruelling. Or you could decide they're not so hot after all, and search elsewhere.
Even then, done right, refusing to jump through hoops raises your status. By acting like you're bargaining from a position of strength, your strengthen your position. If on the other hand you let them taking you for granted, they'll think less of you.
Now there are those who expect spineless sheep. They tend to reject me. Fine with me, I would be unhappy with them anyway.
But he's saying it's okay to walk away from what you know from the hiring process is likely to be a bad job.
If you're destitute, desperate and dying on the street, this is bad advice.
If you are already happily employed, this is good advice.
If you are somewhere in between, it's something interesting to think about. Almost as if it were in a long-form blog posted on Hacker News.
If you find the companies you're interviewing with consistently fail your test, then bring your pattern-identifying skills to bear and figure out why. Maybe all of the companies you're interviewing at have something in common (they're all startups, they're all Fortune 500s, the CEO isn't technical, the roles are too senior/junior). In which case you should break the pattern and apply for work at different types of companies.
Or possibly the pattern lies within yourself. Do you consistently fail the same kind of technical tests? Does your answer to a specific question ("Can you show us a large codebase you've worked on? Oh, you can't?") tend to elicit the same negative answer? Then maybe you should focus on strengthening those weaknesses.
So...make tech even more of an old-boys club than it already is? Because that's what people will be complaining about if the only way to get a job is to know someone or be known.
Really, there isn't a solution here. Any system you use to allocate desirable jobs to an oversupply of applicants will result in folks who believe they were unjustly excluded. What would fix the problem is for people to define "desirable" in different ways, with a bias toward "the place that I actually ended up at". Love what you do, don't do what you love.
When you say, "What would fix the problem is for people to define 'desirable' in different ways, with a bias toward 'the place that I actually ended up at'," that seems to me very much what he is suggesting.
Problem is, "building personal relationships with promising talent" doesn't scale, and so the companies that do it have to pick who the promising talent is. They usually do so through other markers of status (where you went to school, who you know, who your parents are, etc.), which just perpetuates existing inequalities. Everybody thinks that they are the beautiful unique snowflake that hot companies will want to know, but when they find out that those beautiful unique snowflakes are other people, they cry foul.
(Interestingly, 3 of the 4 companies mentioned above imploded spectacularly, while companies with noticeably impersonal and impartial application processes - like Google or YCombinator, for example - are still going strong. That might be an indication that the "treat everybody as a cog, but at least treat them fairly" approach tends to work better.)
I got an offer from them, but I declined without hesitation. I interviewed at Facebook and that process was great. At least one of my coding interviewers did read/skim my github code beforehand. Woo, keep it up!
There's already a baseline of bullshit to deal with everywhere anyway, it's part of almost any job. If a company thinks there's so much bullshit and/or difficult people to deal with that they need to screen for it during interviews, that seems like a HUGE turnoff to me wanting to work there.
At the end of the day, programmers are not emergency workers and need some rest and calmness to do their work efficiently.
Deadline stress more often involves doing research and making decisions quicker, and then putting in the effort to write the code in a more efficient manner to get it done on time.
Interview stress is more just like "Fuck, fuck, fuck, am I doing this the optimal way? Is my thought process here really stupid? Should I make an assumption/decision here or ask for clarification? Would they rather me be more thorough or more self-sustaining? Fuck, I have to do this in 10 minutes? And with no Google/SO?" etc...
I get the part about being busy and not devoting adequate time to reviewing a candidate's portfolio (though sometimes you're pulled in at the last minute), but I wouldn't take this out on someone--I'd hope we all remember what it's like being on the other side of the desk.
However, I'd like y'all to consider the problem from the other side of the table. I conduct a lot of technical interviews. I desperately want to avoid bad hires. How do I avoid the bad hires? It's a really hard problem and there are consequences from both false positive and false negative signals.
Google asks "big-O" type questions not because they're shibboleths or useless trivia. It's practical knowledge in an environment where things often have to scale up to absurd degrees. Most candidates haven't had experience in that kind of environment, so interviewers are looking for signs of aptitude. Knowing which kinds of algorithms can scale up is a sign of that aptitude for those kinds of problems.
Lately, I've been asking more questions from the domain of what I call "programming in the small" -- the kinds of things that crop up when actually writing or reviewing or debugging code. I do this because I've learned that the ability to construct an airtight Boolean predicate expression to test for a well-defined condition is a survival skill for good programmers.
If you're a good candidate, then I'm sincerely sorry that I waste some time (for both of us!) talking with you about some basic stuff rather than having a more interesting technical conversation.
If I have provided a GitHub account with some interesting code, then sure as hell I have demonstrated that I am able to compose "airtight" boolean expressions.
Just like I have to be informed about your company before interviewing, take your time to inform yourself about me.
The amusing thing about this is, from what I can tell, Google actually only needs a small number of people with the deep knowledge. Much of the work there still involves things like "developing CRUD apps", just on top of the platforms and infrastructure the smaller group developed for it.
Which led to a characterization I once heard from an ex-Googler of the company as a place where "they hire top CS Ph.Ds to do incredibly boring code-monkey work".
Like standardized testing, the way to win is to get good at taking the tests. Even if you disapprove, this is how you get a job. I've accepted this.
The ideals are always nice to have, but if I have to fight with a new hire over every built-in process because he doesn't immediately see the value in it, I'm going to get irritated at him.
Maybe this should be a rule of thumb: Don't criticize anything during your first six months. If it's your first job out of school, don't criticize anything during your first year. Learn what's really going on, and why things are the way they are. Then you can criticize.
While there are plenty of processes out there that likely don't need to be, there are I'd venture a lot more where the value generated isn't necessarily obvious to the guys in the trenches. I'm happy to explain this to anyone who asks (and have) and we occasionally even have an issue crop up where hey, look how useful this "busywork" you did earlier is right now, but the point is to a certain degree you should expect to simply obey the stated rules even if you don't IMMEDIATELY see their value. It's just respectful.
I'd also say it's far too easy to conflate "mindless obedience" and "respectful behavior" these days.
If you need to recruit, you need to offer at least one, preferably all three.
Excellent. As we all know, the tech industry's biggest problem is a lack of insularity and out-of-control diversity and this strategy is sure to help.
The negative cost associated with one bad hire can often outway the gain from one great higher. So if a company has to pass up on some great candidates in order to maintain quality they are going to do it.
Are there better ways than trivia questions and whiteboard coding to prevent bad hires? Of Course. One of my co-workers brings up the hiring practice at his old job. They would fly all potential candidates out to their office and have them work (paid) with the team for one day. From there, they would take their top picks and have them work (paid) for a week. From that group they would choose who to hire. My co-worker always remarks about how great of a process it was. However they were also only ever hiring for one or two positions a year. When you're trying to hire as many qualified applicants as possible, these kinds of in depth interviews just aren't efficient enough.
So the negative cost of hiring a bad applicant, in addition to the problem of trying to hire as many people as possible with minimal cost leaves us with interview techniques that don't cater to everyone. But they do do a good job of weeding out bad applicants, even if that does mean passing on good applicants.
Now I'm not saying this is the right way to interview, I just think this aspect is commonly left out of these discussions.
A company can look at my online work, read my written communication, have a nice chat on the phone, and then perhaps can hire me for a short contract to write a component to see how things work out. If they don't they don't have to pay.
I'm also considering not allowing video on the calls also, and will experiment with that. For the last five years I haven't gotten any work from startups (even though I specialize in python and javascript) and wonder if it is due to the fact that I don't dress like a lumberjack and am not as young as I used to be.
I've never considered live video of me a requirement in any professional or technical context a requirement unless I was actually doing something visual that explicitly requires it. When on the job I've never even bothered asking if it was ok to not have my camera on, and in interviews I've never thought twice about letting the interviewer know that I won't have a video stream up. Sometimes its because I genuinely can't (either poor internet or the fact that I don't have a webcam for my desktop) or I just don't feel like it. It's not about some high-minded principle regarding discrimination or a tactical decision or anything, I just don't think that video conferences add anything to audio in any situation except visual presentations or personal/emotional contacts (GF or family). I've been in a LOT of live calls in a lot of contexts and I've never noticed the other party having any issue with this, no interviewer has detectably taken it negatively.
I'd also like to add that I don't always have my camera off, just that I don't feel any pressure to justify myself when it is turned off, which is most of the time.
Coincidence? I don't know.
This is a clearer signal than "cultural fit" (whatever that means).
Can also serve as a good source of questions - can the candidate answer questions about his/her own code? Much more meaningful then some riddles or BST traversal.
1. A single bad hire can do immense damage to a team and organization. I never fully appreciated this until I saw the consequences of bad hires, and as a hiring manager it's one of my biggest fears.
2. Labor laws and HR exist. You can't just willy-nilly fire people, there's a process in any well-functioning company to protect employees from management and vise versa. As a hiring manager this will generally reflect poorly on you.
This has caused interviewers, who are in the position of power, to make the process thorough and straining to protect themselves.
In many ways my philosophy has been shifting to the article's, which is to grow much more slowly and carefully. I don't think this scales well, but it leads to a personal process I can feel good about. I've been networking to meet people within the community, and I hope my future hires either come through personal knowledge of them or vetted referrals.
Google is actually capable of this kind of interview, but it's rare. I was referred to a manager a few years ago by an ex-coworker, and the whole process was great. I met the whole team, I went to lunch with the manager, he told me I could contact him if I had any questions, etc. I didn't end up joining, but I left with a very positive opinion of the manager and team.
Most dev jobs are at-will, no?
This happens sufficiently often that HR has responded with policies to carefully document exactly why people are being fired. Furthermore they often try to get fired employees to sign contracts saying that they won't sue. These policies make it considerably more difficult to fire people.
Does this happen often enough to worry about? Moreover, how do google-style brainteasers filter out litigious individuals?
The brainteasers won't reduce what fraction of hires would be litigious. But they will reduce how many people you need to fire right away, which reduces your exposure to that kind of litigation.
Also note that company's unwillingness to tell you WHY they didn't hire you is another HR recommendation for avoiding lawsuits. The problem is that the more you say, the easier it is for it to be quoted out of context and made to look like you're biased against people based on age/gender/religion/etc, which could be grounds for a lawsuit. A lawsuit that doesn't even have to be winnable if it would cost more to win than to settle out of court...
I thought you could, at least in right-to-work states, if you bothered to make up an excuse that wasn't one of the forbidden ones.
Once google stops asking whiteboard, big o questions hiring will be "fixed". As simple as that. This is the only to fix it, we don't need endless discussions every week about this.
Anecdata, but all the people I know who work at Google tell me the interview is the hardest part. One of them spends their time fixing low-hanging bugs in Python
Interviews will never be fixed. case closed.
Great advice for hiring the first 50-100 hires after that your hurting your self. You just need meat that point.
What do you think of our trash guy he has 4 phds and we pay him 400k a year.
If reading/skimming github repositories is too long, maybe developing visualisation tools, machine learning tools would help for that.
I wonder why Google has not already done that, although they are known to automate their system administration heavily, for instance.
I'm desperately looking for competent developers right now. I don't ask HR for help, and I don't really filter by CV: anyone who considers himself a "senior" is going to get a skype call from me. But the first thing I give them is an assignment, 4-8 hours of work for a candidate of desired skill level. I tell candidates this estimate right away, and after sending it out several dozens times already I haven't met a single one who would say "sorry, I'm to busy to work on that for free". Before starting this process, I was sure this will going to be a problem, and I was sincerely surprised that it didn't happen once.
- If they have public code, talk about that. Maybe ask them to add a feature onto THEIR code.
- If they have no code, give them the option of take-home work or a whiteboard test or a live coding session.
- If they have no code and don't want to do a take-home or whiteboard or live coding session, and you are both senior level, then just talk about work. It should be pretty clear whether they'll be a fit.
- If they have no code, don't want to do a take-home or whiteboard or live coding session, and are NOT senior level, you should probably pass.
People will probably feel better and do better in the interview when they feel they can have a choice in how they are examined because they can plan to show their strengths.
The only downside is that with this is it becomes a bit more difficult to track how well your interviews go with a grading rubric or something.
I mean, both parties want something.
The best interviews I had (now I'm freelancing so I don't have to do them anymore) were when the employer had no idea how to interview.
They asked me what I did and what they do and told me what they want from me.
I asked them how they work and what they have to offer.
The moment they tried to set up some interviewing process, with special questions asked by people with no technical skills and strange tests, everything went downhill...
I do think that the data structures and algorithms whiteboard exams amount to more than "trivia" and I do think there is value in them (my problem with them as I've posted on this board, is that because our industry lacks a proper exam respected widely by our peers, we have to re-take this exam over and over. It would be like an actuary having to demonstrate a knowledge of calculus and linear algebra on the whiteboard over and over, throughout a career - no wonder developers are eventually fatigued by it and stop wanting to play the game).
That said, I like his solution. Just don't do it. I'll still take the algorithm exam, but I won't do take-homes anymore, and I may have missed out on some good opportunities because of it. I just won't do this, largely because it's too large a time investment on my part without a comparable investment from the company in evaluating my application.
Here's the problem - we don't work in a free labor market. I've done my 12 rounds on HN with people about this, but here it is again - we work in a field where silicon valley employers have convinced congress that there is a "shortage" of programmers. This has led to legislation that allows employers to bestow the right to live and work in the US on employees, and the employer retains that right for the duration of the employee's tenure. It is possible to move from one job to another under limited circumstances, but by and large, the visa terms don't really allow the worker to change fields, quit and start a company, or pursue a different career path entirely.
Because it is generally difficult to immigrate to the US without family reunification or a few other insider tracks, tech visas provide one path to do this. As a result, high tech employers are in a position of amazing power over their workforce. They really can say "we will allow you into the US if you study what we say you should study, interview how we say you should interview, work on the projects we say you should work on, live where we say you should live, and accept the salary we say you should receive". Yes, there are a few requirements on salary, but without the right to quit and leave (including with no job lined up), the employee's bargaining power is greatly reduced.
Now, some of us are indeed free agents as individuals, but until all of are free to choose our own path in life, as long as substantial numbers of us are not allowed to do this by law, employers will not have to make the adjustments the market demands when all workers are free.
This is why I support general skilled immigration, but I oppose putting corporations in control over a worker's right live in the US, including determining the circumstances under which the worker is allowed to arrive initially.
Nobody owes me a job under my conditions, and I accept that when I refuse to participate in certain types of interview processes. But nobody owes a corporation a worker under their conditions, and they really seem to be having trouble with this idea.
The last two jobs I took were with companies that treat people with respect, and I would now never go back to a big American megacorps HR drone hiring tech test filter rubbish again.