Hacker News Reader

> I think many companies through the hiring process completely lose sight of what they are actually looking for.

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.

> they'd still subject that person to the technical monkey dance,

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?

> 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.

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.

1: https://news.ycombinator.com/item?id=23333270

I see it slightly differently.

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.

Our whiteboarding question at NeverPivot.mvp is to ask candidates to implement an algorithm to find the inverse square root of a number.

We would also subject John Carmack to that technical monkey dance because we don't believe in free handouts.

Welcome to NeverPivot.mvp! We're thrilled you decided to take the next step in your career as a NeverPivoter. Your job is to add features to the product, period. More features, better job title. That's all we can afford to do for you for now! No one with any useful experience works here, so have fun and be scrappy :)

That's rediculous thinking. It's not a handout. The guy clearly worked for his ability.

fwiw, it took me a minute to figure out but I think that the post you're replying to was a joke.

Hopefully it would have the comment "what the fuck?" in somewhere.

> Personally if I'm hiring someone I've already worked with, I don't do any interview.

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.

So here’s a counter perspective: there is no good way to interview, there are just less bad ways, which depends on your company.

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.

> The worst filter is choosing at random.

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.

It's amazing to me that, in all the discussions and articles on HN that I've read about interviewing, no one ever mentions coupling their favorite filters with gut instinct.

Not everything has to be measurable to make good decisions.

Gut instinct has the problem of doing an excellent job at rejecting candidates from underrepresented groups as well as people with backgrounds that are different from the hiring manager.

It is a method and it may even lead to great hires but it also throws fairness out the door.

but everything has to be measured to quantify if the decision was good or not.

You trust your gut when you have no other option, not because you believe it to be better than a data driven approach

> but everything has to be measured to quantify if the decision was good or not.

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 :)

You just measured our relationship based on a single comment. So yes, I along with everyone else measures relationships based on data.

It's not the worst filter. The worst filter is the one that's highly correlated with other popular bad filters. Because that way you miss out on the people that are generally discriminated against, whereas a random filter is more likely to pick them up by chance. Optimization can be counterproductive, and it's related to what other people are optimizing.

> 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.

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?

Sounds like you're making the point that no filter should be absolute - you need more than one way to evaluate candidates, and a bad result with one of them should simply be ignored if other results are great.

The other interpretation is that you need just one good candidate, meaning you'll have to filter out many - some of whom would also have been good, perhaps even better.

That sounds like you're most likely to end up with a mediocre candidate, one which passed all the filters. I'd rather take the hugely impressive whiteboarder (for example) than the mediocre everything.

Recently, a friend of mine was interviewed for a contract role at Walmart. The first question was some dynamic programming question off of leetcode. He got stuck trying to program it. After 20 mins, he gave up and told the interviewer that he was not the right fit for the role. Sure, if they are paying $250K per annum, yes go for mini programming olympiad. Walmart's staffing company was paying like $75 per hour on W2 in the bay area.

Not to nitpick, but $75 per hour x 40 hours per week x 52 weeks per annum = $156,000, which isn't exactly peanuts. According to levels.fyi, it's a bit less than entry-level for FANG companies, but still a reasonably high salary that sits squarely between E3 and E4 (Senior Software Eng) pay grades for Walmart Labs. It would be a role I would consider testing for the easier DP questions.

$156k in SF for a contractor is garbage pay. You have to pay for all your own expenses. Maybe you'd net $110k after all taxes and expenses.

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.

It looks like median wages for a programmer in SF are around $55/hr according to the BLS. So if I was hiring, I'd assume median plus 1/3 for a contractor is plenty.

https://www.bls.gov/oes/current/oes_41860.htm

It is a contract position for a senior engineer, not a permanent role.

Another problem is that the answers the recruiters want to see don't change depending on the position. You shouldn't expect a new graduate and a senior developer write the same code for the same problem.

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.

There are only seven symbols with two rules. If you skip the subtraction rule and just consider them more symbols, it goes to twelve symbols with one rule. Seems like your solution is more appropriate than a parser.

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.”

Fair enough, but he only said that after I typed in the code and successfully demonstrated that it passed all the test cases (it was a one to one, hands on interview).

If that fails the interview, especially in a startup interview of all places, then that's a red flag on their end. Shows lack of pragmatism, poor communication and unwillingness to embrace lateral thinking.

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.

Oh yeah, sounds like bad communication on his part.

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 many companies through the hiring process completely lose sight of what they are actually looking for

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.

This x 1000. I'm a contractor, so I luckily don't _need_ to find a full time position at the moment; but I occasionally stick my feet in the water to see what's available. I've interviewed with a handful of companies over the past week and around 50% of them describe problems/roles that are mostly different than the original job post. When pressed on the matter, it becomes clear that they have no idea what problem they're actually trying to solve, nor which type of candidate would be a best fit for those unknown problems.

Yes they ignore that because people don't have time to go over single person portfolio if you have 10-20 candidates.

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.

> 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.

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.

I think the user you're replying to has trust issues.

"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 always wonder why people have this second thought about these super complex and convoluted sneaky edge cases. Maybe I'm being naïve here, but I truly think that this will happen in less than the 1% of the candidates, there are just so many jobs offers to waisting the time on doing all that for a "chance" of trick one interview, which you might not even like the offer and then ending up rejecting anyways.

I think that you should work on these trust issues, the interview process is about hiring people not rejecting them.

It seems to me if everybody uses very poor tests and they're all the same, then it's very harmful to society. But if everybody uses different, uncorrelated, very poor tests, then people who have talent generally end up somewhere and there may not be a lot of benefit to improving the tests. In fact, improving the tests could lead to more correlation and excluding/wasting more talent.

"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."

This is my biggest gripe with today's technical interviewing. They act like leetcode is real world engineering.

How can your statement be largely true (90%) with all large companies having _dedicated_ HR departments with staff whose sole responsibility is to find the _best_ employees?

That's not what HRs responsibility is. > How can your statement be largely true (90%) with all large companies having _dedicated_ HR departments with staff whose sole responsibility is to find the _best_ employees?

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.

Where is the quote from (“preventing hiring managers from..."). I don't see it in the OP.

Not saying that it is right, but they probably do it because it is easier to judge based on a known problem (VS comparing different github profiles or whichever source that you choose)