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

61–70 of 123 posts

Re: Hired – Technical Interview Score

#61

Post by vthallam »

mkozlows wrote: post #46
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…

Memorization? It's a factorial function. You shouldn't need to study or memorize anything to implement a factorial function. If you can't come up with this algorithm off the top of your head, that is legit telling something about your problem-solving ability.

Not particularly factorial problem, but the general interview questions require some amount of prior knowledge about the techniques. Topics like math based or bit manipulation, permutations/combinations have questions which are often asked in Interviews and require some prior knowledge to be able to give optimized solutions.

Re: Hired – Technical Interview Score

#62

Post by geebee »

mkozlows wrote: post #54
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.

Certs are worthless. Generally, the most terrible programmers out there are loaded down with certs.

Largely agreed about certs. But the actuarial exams aren't worthless. We may need to look to a new model.

Re: Hired – Technical Interview Score

#63

Post by bit_logic »

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…

Some comments here are asking what would be a better process. I think a big step is just stopping with the requirement to get the optimal solution. If I was doing these interviews, brute force is fine. If they can come up with a brute force and write code for it, they completely pass my coding bar. Some may say that's a low bar, but it's not. Because expecting anything more is going into rote memorization territory of algorithms. It's also not realistic. In the real world, brute force is always the first solution and it's the right first choice for a number of reasons:

- Brute force is often simple to understand. That directly translates into maintainable code.

- The business constraints on the input size may make the brute force an acceptable solution.

- If you need a better optimized algorithm, brute force is a great place to start. It's basically your test case generator for verifying that your more complex algorithm is right.

After they get brute force code written, the coding part is over and the rest of the interview is about discussing why it's brute force and what we could do about it. But no more coding is expected. It's a chance to be creative. If they want to talk about improving the algorithm that's fine, let's draw some diagrams. They want to throw more hardware at it? Sure, let's talk about how to scale that. Maybe they've actually seen a business problem before that was similar? Great, let's discuss how you solved it.

Re: Hired – Technical Interview Score

#64

Post by chrisdbaldwin »

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?

345 x 27 = 2415 + 6900 = 9315

You don't need a calculator. Use your brain and show your work.

Re: Hired – Technical Interview Score

#65

Post by pklausler »

Don't just whine about bad programming interview practices. Suggest something better that wouldn't have more false positive hires (i.e., candidate can't program, but can pass interview), and maybe fewer false negatives (candidate can program, but gets filtered out anyway).

This is a hard problem. Kindly think about it from the perspective of a technical interviewer who really has no idea whether the candidate on the other side of the table can program a computer or not and has to make a hire/no-hire call in 45 minutes.

Re: Hired – Technical Interview Score

#66

Post by nwellinghoff »

logfromblammo wrote: post #26
kyberias wrote: post #9

Earlier quoted context omitted.

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…

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

Re: Hired – Technical Interview Score

#67

Post by jxramos »

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

Some comments here are asking what would be a better process. I think a big step is just stopping with the requirement to get the optimal solution. If I was doing these interviews, brute force is fine. If they can come up with a brute force and write code for it, they completely pass my coding bar. Some may say that's a low bar, but it's not. Because expecting anything more is going into rote memorization territory o…

+1 for test case generator, some of our libraries even have a dividing path between optimized vs brute force modes just so we can be certain of correctness in unit test and what not. Correctness first with all the testing infrastructure and TODOs to at a later time go in and lay better algorithms down/execute general refactoring.

Re: Hired – Technical Interview Score

#68

Post by dopamean »

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

Some comments here are asking what would be a better process. I think a big step is just stopping with the requirement to get the optimal solution. If I was doing these interviews, brute force is fine. If they can come up with a brute force and write code for it, they completely pass my coding bar. Some may say that's a low bar, but it's not. Because expecting anything more is going into rote memorization territory o…

I really like this comment a lot because it mirrors my experience with brute force type solutions to problems. It's pretty much what I always start with because on my first pass I need to prove that the problem can be solved in the first place. Then that gives me a baseline where I feel comfortable making changes and trying to optimize. Like you said, very often because of business constraints the optimization only needs to go so far and so an "optimal solution" may not necessarily be the one that is fastest in benchmarks. It may be the one I can get out today that solves the business problem now.

Re: Hired – Technical Interview Score

#69

Post by jxramos »

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…

I like your style on this one, basically pulling out these: "I was on fire the day I solved it in the recent past, I just don't know why I can't pull it together today"

Re: Hired – Technical Interview Score

#70

Post by sulam »

lolc wrote: post #35
rafiki6 wrote: post #14

What has this proven exactly? Has an study been done to show a strong correlation between these test scores and ACTUAL programmer productivity? What two metrics are you correlating here? All I see is a score. Is this score valuable? I see nothing outside of pure speculation or opinion to suggest that's the case in the link. And anyone who wants to rebut and say, "that's an impossible task" or "but we know what it tak…

While I don't know whether this has been studied, I would expect the interview results to correlate well with years of experience for example. I think what these interviews test best is your ability to interact with your peers. Candidates who interface badly with other people would have trouble getting a good score. So yes some brilliant people will bomb those interviews. And some talkers will manage to pass one inte…

I'm not convinced they correlate with years of experience. In fact they may well inversely correlate. I give a relaxed algorithm design screen to candidates (of which roughly 70% pass -- I'm a soft touch) that include a problem that is mildly academic in nature. New grads are the ones that tell me they already know it and I have to move on to the next problem (which, amusingly, they never have experience with). Experience people often have a vague recollection of what it does, but not enough of a recollection to prevent me from learning something from the discussion about how to get it done.
Post reply on HN