Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hired – Technical Interview Score

refdash.com

Post reply on HN
Print view View original

91–100 of 123 posts

Re: Hired – Technical Interview Score

#91

Post by kearneyandy »

nxsynonym wrote: post #45

Would an industry-approved certification be a viable replacement for on the spot technical interviews? Somebody feel free to change my view - but I don't see why there can't be a standardized certification (could be broken up into specific areas of tech/comp sci/programming) that proves the applicant is competent in the industry standards, and just focus on the personal/soft skills/culture fit of the interview.

I think this is a good idea and would speed up interviewing at companies since you would be able to focus on the match. It does rely on companies actually knowing what criteria they are looking for and to be upfront about it, which unfortunately, is not common.

The real problem is that very good candidates are often not motivated to get certs, since they likely don't need them. However with the added benefit of speeding up the interviewer process, I think more people would do it and it could then become a standard and not a negative signal.

Re: Hired – Technical Interview Score

#92

Post by logfromblammo »

nwellinghoff wrote: post #66
logfromblammo wrote: post #26

Earlier quoted context omitted.

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…

What do you mean you can "only meaningfully do 22 different factorials within the bounds of a 64-bit architecture anyway"?

The 52-bit mantissa of a 64-bit double is only sufficient to represent all the significant figures of 22! and a 64-bit integer can only represent 20!, so if you want larger factorials with full precision, you need to use more bytes for your numeric representation.

Not many real-world applications require precision greater than a double, but pure mathematics can calculate millions of [decimal] digits of an irrational number just for amusement. A cryptography application, for instance, would need full precision, whereas an engineering problem might be perfectly fine with fewer significant digits.

Re: Hired – Technical Interview Score

#93

Post by megy »

ashark wrote: post #29
lloeki wrote: post #22

Earlier quoted context omitted.

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 wh…

That is a bit ridiculous. It shows everyone who the project is tracking, and how inline with reality estimates are. I am not sure why you guys find it so hard to comprehend why that is useful?

Re: Hired – Technical Interview Score

#94

Post by bogomipz »

bit_logic wrote: post #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 p…

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

Indeed. Now the default seems to be companies sending out a Hacker Ranks test consisting of 5 separate problems, a countdown timer and zero human interaction.

I can't help but think that recruiters are playing a part in pushing for this online Hacker Rank test bullshit.

It feels to me that as the quality of people working as recruiters goes further into the toilet the reliance on the Hacker Rank puzzle test seems to increase.

Re: Hired – Technical Interview Score

#95

Post by jnordwick »

koala_man wrote: post #58
alexandercrohde wrote: post #3

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,…

> we never get told what we're being scored on in advance I make a point of not telling you. I want you to demonstrate that you're able to work out the requirements when you're given a task. Some people will take a task, go off for a few weeks, develop ill-fitting solutions, and then say "well, you didn't say you wanted unit tests" or "you didn't tell me it had to support files that can't fit in memory". Others will…

I generally give all the important parts of the question up front. Having to fish for requirement isn't the point.

Re: Hired – Technical Interview Score

#96

Post by jldugger »

justboxing wrote: post #88
mkozlows wrote: post #60

Earlier quoted context omitted.

Take home is great, except people cheat. People even cheat on early screening questions knowing that an interview is coming up. (In a previous role, I gave applicants the same -- very trivial -- question that they had already coded the answer for in a do-at-home screening. I wasn't secretive about this, either, I told them that this is the exact same question they had already answered. A significant percentage of the…

> except people cheat. I never understood this. In a programming / software development job more than any other job, aren't you very likely to fail at delivering on the job, if you cheat on the interview and tests?

But the money's good while it lasts, right? And you can always 'fake it until you make it' on the job too, right?

Re: Hired – Technical Interview Score

#97

Post by heartbreak »

justboxing wrote: post #88
mkozlows wrote: post #60

Earlier quoted context omitted.

Take home is great, except people cheat. People even cheat on early screening questions knowing that an interview is coming up. (In a previous role, I gave applicants the same -- very trivial -- question that they had already coded the answer for in a do-at-home screening. I wasn't secretive about this, either, I told them that this is the exact same question they had already answered. A significant percentage of the…

> except people cheat. I never understood this. In a programming / software development job more than any other job, aren't you very likely to fail at delivering on the job, if you cheat on the interview and tests?

If cheating is defined as looking up the solution on Google, I frequently cheat while performing my job responsibilities.

Re: Hired – Technical Interview Score

#98

Post by dajohnson89 »

mkozlows wrote: post #60
justboxing wrote: post #49

Earlier quoted context omitted.

I've been attending a lot of phone screens, and in-person interviews for a Senior Software Engineer ( C# / .Net ) Position. Here's some feedback. YMMV. 1. Don't ask questions that are hard to explain over phone. For instance I was asked if I've used Lambdas in C# and I said, "Yes, extensively.", next question was. "Explain to me what a Lambda is.". I gave the textbook definition for it, and he was expecting more, so…

Take home is great, except people cheat. People even cheat on early screening questions knowing that an interview is coming up. (In a previous role, I gave applicants the same -- very trivial -- question that they had already coded the answer for in a do-at-home screening. I wasn't secretive about this, either, I told them that this is the exact same question they had already answered. A significant percentage of the…

is take home great? if you have a full time job, any sense of home life, is being asked to code a small project in your spare time (and on a limited time basis) sane? I did two this year, and tbh I think the next company that assigns me one I'll just decline.

Re: Hired – Technical Interview Score

#99

Post by heartbreak »

jnordwick wrote: post #95
koala_man wrote: post #58

Earlier quoted context omitted.

> we never get told what we're being scored on in advance I make a point of not telling you. I want you to demonstrate that you're able to work out the requirements when you're given a task. Some people will take a task, go off for a few weeks, develop ill-fitting solutions, and then say "well, you didn't say you wanted unit tests" or "you didn't tell me it had to support files that can't fit in memory". Others will…

I generally give all the important parts of the question up front. Having to fish for requirement isn't the point.

I like to leave at least something small ambiguous to see if clarification is requested. My clients rarely give unambiguous requirements, so I feel it’s pertinent to the job.

Re: Hired – Technical Interview Score

#100

Post by kyberias »

throw401 wrote: post #48
kyberias wrote: post #20

Earlier quoted context omitted.

Personally, I think that asking people to write code in interviews brings very _limited_ data. However, from my experience, it usually is also a very _strong_ signal. Narrow but strong. For example, if a candidate cannot implement a simple algorithm (like the factorial here), he very likely has poor skills. If he can implement it without too much trouble, that's a good sign, but he only proved that he probably has so…

And is the signal still strong if candidate has a bad day or for some other reason cannot get the right focus in that specific moment? Moreover, I think it's highly unprofessional to reinvent the wheel by writing most algorithms for production. I always first look for a bullet proof library for that. Won't you use a calculator for 345 x 27?

Yes, I think it is fairly _realiable_. It reveals whether the candidate can't really write code.

Again, the idea of the coding test in interviews is not to produce production quality code. It is testing that the candidate's brain can write some code. Try to understand that.

Is it a perfect measurement? Of course not.

Also, the idea is to select an algorithm that doesn't require encyclopedic knowledge of different algorithms. Even (any) sorting algorithms may be too complex for this purpose.

Post reply on HN