Live data from Hacker News

Hired – Technical Interview Score

refdash.com

21–30 of 123 posts

Re: Hired – Technical Interview Score

#21
post #16

Earlier quoted context omitted.

> This is one reason why most interviewing is a subjective clusterfuck (not just software, I suspect). This is why I get a laugh out of people complaining about whiteboard-style interviews. Far and away tech still has one of the most intensely meritocratic hiring processes. Not perfect, sure, but better than almost every other industry. The majority of high-skilled jobs rely heavily on pedigree, education, social sta…

> Almost every other industry relies heavily on pedigree, education, social standing, references, sociability, etc. Almost every industry, including tech, relies heavily on those things as pre-interview filters. Tech is not a meritocratic exception here.

How many traders at Goldman Sachs don't have degrees from Penn/Harvard/Yale/etc? I bet not very many. Yet some of the best developers I know are self-taught or went to no-name schools.

My SO works in media and I can assure you the hiring process there is completely, thoroughly, perniciously subjective. Experiencing her job search really gave me appreciation for the fact that taking a test is 80% of my interview process.

Re: Hired – Technical Interview Score

#22
post #7
post #5

Earlier quoted context omitted.

> giving of graphs and other media that are meant to project an idea of objectivity Agile has the same issues.

Would you like to elaborate? What "agile graphs" fail and why?

Burndown charts, planning poker, difficulty weights, priority tiers, team velocity over time, milestone progress bars.

I’ve yet to see someone tell me with a straight face that they hold any value like what we want them to be.

Re: Hired – Technical Interview Score

#23
I'm assuming this is a fake interview to show off the interview feedback for your platform? If so, I think it looks great and is a huge part of what's missing from the current "standard" engineer interview. Receiving feedback like this would be incredibly helpful in figuring out what I'd need to work on to pass technical screens.

The fact that there's very little proven correlation between being able to jump through these hoops and being a good programmer is another story altogether, but I like this!

Re: Hired – Technical Interview Score

#24
Have we reached the tipping point yet? How much worse does the technical interview process need to get before the industry finally decides enough is enough?

When this all began, it was with the justification that it's not about getting the right answer, it's about seeing how you think and approach a problem.

Companies don't even pretend this is the case anymore. It's now just expected rote memorization of algorithm patterns, talk about it with the right terms and key phrases, still pretend like the candidate had some brilliant "aha" moment, when both sides know it's bullshit, and write the solution on the board as fast as possible without errors.

A completely pointless process that's now heavily pushed by an entire industry of tech interview prep (websites, books, interview coaches, etc.) When I now read a discussion about tech interviews, I wonder how many are industry shills who want to keep pushing the narrative that the process is great, but you just have to keep practicing and studying more, using the right materials of course.

There's also the side effect of ageism. Who other than college grads or seniors in college has the free time to study for this process? Those with families and full time jobs are of course going to have a hard time. Even if they manage to find some free time here and there, how can they compete with someone in college with no responsibilities who has time to hundreds of problems? The simple answer is they can't. The college grad will always look smarter and faster in the interviews.

Re: Hired – Technical Interview Score

#25
post #7
post #5

Earlier quoted context omitted.

> giving of graphs and other media that are meant to project an idea of objectivity Agile has the same issues.

Would you like to elaborate? What "agile graphs" fail and why?

Burndown charts and the like, one imagines.

Re: Hired – Technical Interview Score

#26
post #9

Clearly the person didn't run the code. The factorial function returns an int. The factorial of 13 is already too big for a 32-bit int. The factorial of 21 is bigger than a 64-bit int.

I think the code people have to write in interviews is not supposed to work/scale in the real world. The purpose usually is to test whether the candidate can implement a correct algorithm. Even though this is Java (?), it's used more like pseudo code. A follow up question could be: "Do you see some problems with running this with big numbers? How would you scale it?"

A double only has 52 bits of precision, but in a factorial, every second number in the multiplication has at least one factor of two in it, so you could get to 22! that way without any loss of precision.

Beyond that, "it depends" on what you're doing with the results. It's very likely that the developers' time would be better spent removing the factorial from the calculation that uses it, than on making the factorial calculation better at calculating factorials.

Besides that, since you can only meaningfully do 22 different factorials within the bounds of a 64-bit architecture anyway, just pre-calculate the results and make it a lookup table. Returns in O(c).

Re: Hired – Technical Interview Score

#27
post #16

I don't know what to make of this. Looks like a potential headache. As an engineer in an interview, we never get told what we're being scored on in advance (naming, speed, coming up with wonky edge-cases, scalability to 1million times workload, versatility, mentioning a bunch of relevant buzzwords (bloom filters!), confidence?). This is one reason why most interviewing is a subjective clusterfuck (not just software,…

> This is one reason why most interviewing is a subjective clusterfuck (not just software, I suspect). This is why I get a laugh out of people complaining about whiteboard-style interviews. Far and away tech still has one of the most intensely meritocratic hiring processes. Not perfect, sure, but better than almost every other industry. The majority of high-skilled jobs rely heavily on pedigree, education, social sta…

Suppose you have a job for a Kernel hacker. You have John, who has zillions of non-trivial patches applied upstream available, but "flubbed a BFS traversal". And you have Joe, who you haven't heard before but took a whole year doing nothing but traversing graphs and trees to pass your interview. Who would you reject?

Re: Hired – Technical Interview Score

#28
post #16

Earlier quoted context omitted.

> This is one reason why most interviewing is a subjective clusterfuck (not just software, I suspect). This is why I get a laugh out of people complaining about whiteboard-style interviews. Far and away tech still has one of the most intensely meritocratic hiring processes. Not perfect, sure, but better than almost every other industry. The majority of high-skilled jobs rely heavily on pedigree, education, social sta…

Suppose you have a job for a Kernel hacker. You have John, who has zillions of non-trivial patches applied upstream available, but "flubbed a BFS traversal". And you have Joe, who you haven't heard before but took a whole year doing nothing but traversing graphs and trees to pass your interview. Who would you reject?

Whiteboard interviews are not for hyper specialized roles. They're for companies who get hundreds of applicants every week. Right tool for the job.

In this instance if I were John I probably wouldn't want to work for the company anyways because they clearly have no idea how to hire.

Re: Hired – Technical Interview Score

#29
post #22
post #7

Earlier quoted context omitted.

Would you like to elaborate? What "agile graphs" fail and why?

Burndown charts, planning poker, difficulty weights, priority tiers, team velocity over time, milestone progress bars. I’ve yet to see someone tell me with a straight face that they hold any value like what we want them to be.

Their value is that they make the client comfortable with estimates that are explicitly fuzzy BS, which is vital since there's no way it makes sense for the client to pay for the time it'd take to give them a non-fuzzy, non-BS estimate. It also deflects them from attempting to get non-fuzzy, non-BS estimates out of you in a fraction of the time it'd otherwise take—the reputation and authority of the Agile brand is what gets them to do this, not any actual utility it has.

That agile estimation is fuzzy BS is a certainty. But it's a nice comforting blanket to help clients accept "we're just gonna start working on this, if you decide you don't want us to work on it anymore tell us to stop," which is important because that's the most cost-effective way for the client to spend their money, in many cases.

It's nowhere near as accurate as anything resembling an actual engineering estimation process, but ain't no-one got the time/money for that. It's probably a little better than the seat-of-pants "just give me a ballpark right now (but I'm totally gonna hold you to it, gee isn't it weird how we're always fighting fires and in crunch mode?)" that it's replacing as far as accuracy, but more importantly it makes that crap not happen (assuming it's functioning correctly).

Re: Hired – Technical Interview Score

#30
In 4 - 6 weeks I'll be interviewing again. If anyone asks me to implement an algorithm during an interview, I'm going to search for the answer and use it. I don't have time to waste nor do I want to work for a company that wastes time which is money. How can they afford me if they keep wasting it?
Post reply on HN