Absolutely. There was a topic here about a week ago where one commenter in particular personified this line of thought (sorry I don't have a link to the comment).
Paraphrasing, they said that if they very to interview someone they're already working with and know to be a very strong contributor, they'd still subject that person to the technical monkey dance, as you put it, and if they "fail" then they wouldn't be hired.
It blew my mind that anyone can think that way. Clearly the interview hazing culture has become so entrenched that the game of the interview has grown to be an entity to itself. We seem to have forgotten the actual goal is to hire good people.
Personally if I'm hiring someone I've already worked with, I don't do any interview. What would be the point? There is nothing I can learn in 45 minutes that I don't already know from months/years working together. If I called them up from my contact list is because I already know they're capable. All I need to do is describe the role and job and ask if it is a fit for their career goals at the moment.
Someone here said that about John Carmack, which just blows my mind. Exactly how bad would his 8-Queens solution have to be to change your opinion of him?
> Paraphrasing, they said that if they very to interview someone they're already working with and know to be a very strong contributor, they'd still subject that person to the technical monkey dance, as you put it, and if they "fail" then they wouldn't be hired.
I think I might have been one of commenters you guys are talking about here: [1]. I took my downvotes without complaint, even though I think people failed to apply the "Please respond to the strongest plausible interpretation of what someone says" HN guideline.
I'm not for hazing or monkey dancing. In fact I also hate these kinds of interviews and think they should stop. I'm against special treatment for celebrities. Why should someone who is an expert at growing their personal brand get to bypass the queue with a "quick chat" interview? What does their superior SEO on their blog, or association with some name-brand popular company have to do with their development skill? Does constantly speaking at meetups and conferences actually make you a better employee? Normal no-name developers always have to go through the standard interview process, even no-names with clear, provable track records. Companies have standard processes because we want to measure candidates fairly. Many go even further to try to remove prejudices and unconscious biases from the process. All to get some kind of objective picture of the candidate's suitability.
Why should someone get special treatment to bypass all that just because their names are well-known? I say fix the "standard process" to make it better, but still send everyone through it so you are giving everyone the same chance and comparing candidates fairly.
Interviews are meant to gather information so that you can make an informed decision about hiring the candidate (and vice versa). If you already have some information, it's silly, wasteful, and a bit rude to ask for it over and over again. Suppose you got Carmack in for an interview and he flubs the programming test (maybe he's exhausted or sick or his dog died that morning). Are you really going to pass on him because he missed an edge case, or didn't see the O(1) solution? Frankly, I don't believe it.
I'm also not entirely convinced that you can have a totally "fair" standardized interview. The trade-off for being unbiased[0] is that you will instead have incredibly high variance. That imposes real and mental costs on applicants too: interviews are stressful, take vacation days, etc.
Instead, I think it's better to tailor the interview to what you need to make your decision. For a new grad, you probably do want to see some evidence that they can code. Assuming you can even get a well-established person to jump through your hoops, I'm still not sure you should. Your 45 minutes with Carmack, for example, is probably better spent figuring out if/how he will fit into the role for which you are hiring.
[0] And even...there's a lot of bias in how people prepare. I had no idea I'd be redoing a DS&A class at my first interview; I think Stanford has a whole interview prep class.
We would also subject John Carmack to that technical monkey dance because we don't believe in free handouts.
Whenever one of my former coworkers would come in for an interview, I would recuse myself from the loop. I figured it would be a waste of time for everyone and I would have an undue influence on the process, especially since they already knew I approved. I would ask to be put at the very end of the loop and then just ask the person if they had any questions about the people they talked to or anything the learned about the company that day that concerned them.
If they were just a friend who I had never actually worked with, I would interview them like normal but would still ask to be near the end so they could ask me better questions during the Q&A.
The worst filter is choosing at random. If I shuffle a stack of resumes and throw half in the trash, I have eliminated the unlucky candidates. I have certainly rejected a good number of skilled and highly qualified candidates. Regardless the filter did its job, I have fewer applications to review.
If I give candidates whiteboard problems, I filtered out thoughtful people who don’t perform well under pressure. If I look at interviewees github submission and blog posts I have filtered out intelligent people with a dearth of free time. If I combine the two filters with an OR relationship, I now let more people through and have a filter that is less effective at narrowing down candidates.
All filters filter out good candidates. Anyone who finds a way to find exactly the right candidates from a filter in a way that isn’t bespoke and is scalable is going to be very successful.
That seems more like a baseline case than the worse one. I feel like I could definitely come up with one that’s worse than random. Negative points for indications of intelligence, knowledge, collaboration, and kindness.
Not everything has to be measurable to make good decisions.
It is a method and it may even lead to great hires but it also throws fairness out the door.
You trust your gut when you have no other option, not because you believe it to be better than a data driven approach
Do you measure your romantic relationships or marriage or family interactions? Do you measure any human relationship?Because hiring and working with someone with fundamentally a relationship, not a data science or math problem.
I had a manager once who said, "if it can't be measured, it can't be managed." You sound like him. Good luck with that approach, and i hope we don't work together :)
I disagree with the filtering attitude. Everybody wants the best candidate but they are not offering the best job.
If you can, hire the first person who convinced you that it's not going to be tough to work with and build an adult and professional relationship where each side is clear on expectations and demands.
Of course if you need a specialist, then be clear (and feel free to check) that specific ability are required. But why don't you have the time to make somebody grow organically those ability/knowledge internally?
There's real contractors and then there's fake contractors which should always be called staff augmentation.
No real senior software dev contractor would accept $75/hour in the Bay area. You're looking at minimum $100/hour.
Although, "fake contractors" or staff augmentation, those can be paid $75/hour or less.
I was asked to write a Roman numeral to decimal converter in an interview for a senior developer role. I hadn't thought about it before, so I came up with a lookup table that handled all the special cases (there are only a few, such as IV and IX).
The recruiter (who was also the owner of the startup) didn't like my solution because he expected me to write a generic parser. Now, if I were him, I would have expected a senior developer to correctly determine if the specs for a 2000 year old problem could change in the near future and write the more performant solution when possible.
That being said, there’s nothing wrong with saying “I’d like to see you write a parser. Let’s make one for Roman numerals so it’s fast and simple.”
You came up with a working solution that fell outside the spectrum of what they were expecting. And they couldn't adapt their thinking/hiring process to that so more fool them.
In a generous interpretation of the situation they weren't a good fit for you anyway.
How did you handle looking up two characters vs one? Take a pass for all the doubles first and consider those negative? Or keep a history as you loop over it?
I think you're right about that. But I've also seen (from both sides of the table) that many companies also have no idea of what they are actually looking for.
People can create fake portfolios and you even have systems to make it look like you are active on git hub. Then learn to talk through the code or present that code without understanding any of it. You really really don't want to hire someone like that.
If I ask you on the spot and have discussion about something new you just had to come up with, it is much harder to bs.
It is not just about you, it is not just about company. It is about relationship. When I meet someone for the first time I don't trust them, there is so many scam artists that can tell colorful stories where they are "military paramedic just back from mission". Then this story will fall apart only after they are already months in job. If they are scammers they probably will do other bad stuff as well.
Oh come on. What’s the proportion of people doing that out of the applicants you ever interviewed?
Having a five minutes chat about any of their projects would weed them out right away.
"When I meet someone for the first time I don't trust them, there is so many scam artists that can tell colorful stories"
Sounds like they've been scammed before and are taking it out on candidates.
I think that you should work on these trust issues, the interview process is about hiring people not rejecting them.
This is my biggest gripe with today's technical interviewing. They act like leetcode is real world engineering.
HRs responsibility is to protect the company from liability in hiring, firing, promotion, retention, labor relations, wage/hour rules, etc.
To the extent that part of their public statement of purpose is helping hiring managers find the best employees, that's mostly bureaucratic euphemism for “preventing hiring managers from indulging their own conscious or unconscious racial, sexual, age-related, etc., biases in a way which creates legal problems for the company.”
Cookie cutter approaches where everyone goes through the same checkpoints and they are weighed the same way, including cookie cutter technical interviews rather than a nuanced consideration of other factors that determines the need and coverage of a technical interview, is exactly what having a significant HR department encourages.
I think many companies through the hiring process completely lose sight of what they are actually looking for. They forget that the barriers they erected (whether they be whiteboard problems, take-home coding tests, algorithmic dance on your head textbook problems, etc.) are simply signals about the actual person and their capabilities...and usually, they're _exceedingly poor signals_. That's why you end up with situations where extremely accomplished and talented developers don't pass many technical interviews at companies where they would have otherwise gone on to be outstanding employees.
And it keeps happening, and happening, and happening.
Interviewing for a developer role should be far, far, far more holistic than it is today - rather than throwing away my entire history of accomplishments and creations and just assessing me on the spot in a 2hr winner-takes-all high-stakes game of whiteboard/technical trivia.
For example:
* If I have a strong GitHub portfolio of projects I can prove I worked on, that should 100% take priority as a signal as to my capability and how I think about committing regularly, writing clear commit messages, etc.
* If I've built products I can prove I alone built and I can walk you through my code, that should 100% take priority as a signal as to how I write code, my proficiency with a particular language, etc.
* If I communicate clearly over email, have a blog with my writing demonstrating my ability to clearly communicate technical topics, that should 100% take priority as a signal as to how well I communicate.
etc, etc.
Sadly, today, I'd say ~90% of technical interviews completely and utterly ignore all the above and want you to do the technical monkey dance...because clearly, what makes a developer great is grinding leetcode for 3 months and then pretending you haven't seen the problems before during the interview.