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

Three hundred programming interviews in thirty days

blog.triplebyte.com

Post reply on HN
Print view View original

231–240 of 248 posts

Re: Three hundred programming interviews in thirty days

#231

Post by kriro »

Maybe I glanced over it but who did the candidates interview for? Were those just simulated interviews or are they working with companies that actually hire people? Or are they hiring for themselves? I'm very confused by what "success" means. The last paragraph indicates that it wasn't actually used for a hiring process? I see a commenter on their site has the exact same reaction.

Either way I applaud every afford to improve the hiring process. However I'm a tad bit skeptical. They should release the dataset (unless I missed it) because it's pretty convenient that the results seem to indicate that hiring can be improved by a quiz which they could build and sell.

I'd be interested in the following screening filter: Have a programmer at the company read through the projects the candidates supplied (as a replacement to "read CV") and then come to a conclusion of yes/no. No projects = no job offer by default. You can always think of a different approach for people with no projects if you feel like you should hire from that group. Possibly have multiple programmers read the code and discuss it.

Re: Three hundred programming interviews in thirty days

#232

Post by mavelikara »

crdoconnor wrote: post #207
geebee wrote: post #39

Earlier quoted context omitted.

I did this once. After a take home quiz that took about an hour, I had a 6-7 hour "homework" problem. I did it, and sent it in. It took the company a month to get back to me, though I did stay in contact with the recruiter. The final answer, delivered by the recruiter, was "we've decided not to more forward at this time." No other feedback. I have no idea if anyone even looked at it - I never did speak to a dev at th…

Ironically, the last time I complained about this practice on hacker news for exactly the reasons you described, somebody weighed into defend the practice, and an job applicant at his company weighed in to say "my application to your company was not even rejected, it was just ignored for months": https://news.ycombinator.com/item?id=9437516

The comment referred to here is one I made, and let me expand on the incident.

Firstly, the job application that Decade mentioned in that thread was not the coding assignment, but was a resume.

We will not ignore an answer submitted to our coding assignment. Also, we do give feedback to the candidate if we decide not to proceed. We have had candidates who sent in a revised submission which incorporated fixes to our earlier negative feedback and we have been glad to proceed[1].

This meme I see often on HN that people who do hiring are some antagonistic bastards out to get you is simply not true. I am as much a programer as any one of the candidates. I have tried to design the interview process - at least in my part of the organization - to be fair and humane ("Do unto others.." etc) But I also have the other constraint that I have to make the process scale - hence the coding assignment. We are not using the code sent in by candidates in production. We have spent significant time developing the assignments - say, an order of magnitude more man hours than it would take for a typical programer to code up a solution.

I honestly believe that the "interview problem" is an essential complexity caused by the way the industry is set up[2]. I also do believe that a solution to the problem will not be handed down to us from the heavens. Each one of us programers have to help with the solution. Every time we get a chance to conduct an interview show some empathy and respect. Also, teach the professional recruiters working on your hiring team to also show the same. Make it clear that ill-treating any fellow programmer, even one which is not fit for the current role, will permanently ban that recruiter from working with you ever in any capacity. I also welcome efforts like Starfighter, Triplebyte etc from more prominent members of this community.

Now, the aftermath. After that thread, Decade followed up with me and we ended up sending him the coding assignment. Decade completed it and send us back the result, and my colleague's assessment of it was "This is the best code I've seen for this assignment. Let's take the next step". Few days later Decade came in for an onsite interview where he met various members of the team. We made him an offer, which he accepted. I am delighted to report that he started on the job the week before last!

[1] This is very rare, though. We do not hear back from most candidates. Few argue with the feedback, of course.

[2] My thoughts on the topic are at https://news.ycombinator.com/item?id=1964932. The advantages of this set up, IMO, far out-weigh the negatives cause by "interview problem".

Re: Three hundred programming interviews in thirty days

#233

Post by mycelin »

foldr wrote: post #182
lockes5hadow wrote: post #133

Earlier quoted context omitted.

Even in C I would point out that the compiler will likely make such a trivial optimization for you. That was clearly a company full of morons.

In fact GCC will virtually always produce optimal code for multiplication by a constant. Targetting AVR, for example (which doesn't always have hardware multiply), GCC produces more compact code if you use '*' than if you use '<<'. Similarly, any attempt I made to multiply by non-round constants using bitshifting and addition led to less compact code.

Uh, extremely unexpected.

Re: Three hundred programming interviews in thirty days

#234

Post by ankitml »

IndianAstronaut wrote: post #157
eitally wrote: post #16

Earlier quoted context omitted.

My wife is in this position now, and it's not for a programming job. She works in pharmaceuticals, in pharmacovigilance & risk management. She does a lot of data analysis & writing (the latest report she wrote for Health Canada & the FDA was 461 pages). A company she's interviewing with asked her to do a sample writing task as part of her application/interview. She hasn't decided whether it's worth it or not. For som…

>spending (her estimate) 12-15 hours doing pro bono work just to apply somewhere is ridiculous. Keep in mind that in today's job market, there are probably 10 people lined up who are willing to do just that.

Doing something because you can is the worst reason to do so.

Re: Three hundred programming interviews in thirty days

#235

Post by NickPollard »

mjfisher wrote: post #227
bbcbasic wrote: post #212

Earlier quoted context omitted.

I have had an interview where both the (x * 8) and (x << 3) would have been frowned upon, for using a "magic number".

Good, I think? It wouldn't be a deal breaker at interview for me (or even something we test for, come to think of it), but they were right in that it is a magic number. Unless you are doing something where the context is so perfectly obvious that number should be an 8, it's better off tagged as a constant so the next dev to come along has a better chance of understanding your code.

Indeed:

  static const int eight = 8;

  x * eight;
Sometimes magic numbers are just that - numbers. Adding constant definitions is often a good thing, but sometimes just adds noise.

Re: Three hundred programming interviews in thirty days

#236

Post by [deleted] »

NickPollard wrote: post #235
mjfisher wrote: post #227

Earlier quoted context omitted.

Good, I think? It wouldn't be a deal breaker at interview for me (or even something we test for, come to think of it), but they were right in that it is a magic number. Unless you are doing something where the context is so perfectly obvious that number should be an 8, it's better off tagged as a constant so the next dev to come along has a better chance of understanding your code.

Indeed: static const int eight = 8; x * eight; Sometimes magic numbers are just that - numbers. Adding constant definitions is often a good thing, but sometimes just adds noise.

[deleted]

Re: Three hundred programming interviews in thirty days

#237

Post by darklajid »

protonfish wrote: post #6

It's great to see some objective research being done on this, and I am very interested in following the results. They mention evaluating the effectiveness of giving a candidate a project to do "in their own time." I recently had a interview that included this and I can share the result: I accepted an offer from a different company that didn't require it. I doubt my life is that different than anyone else's, with a fu…

Spending that much time to qualify for a single job is too much to ask of anyone

How can you state that as something absolute? I certainly understand your position, but I would be _glad_ to do something like that. My reasons

- I hate white boards and quizzes. I would fail those, probably.

- I'm not interested in travel time, just because. Give me 'homework' and only meet if you're prepared to make me an offer (other issues notwithstanding - it's okay if you reject me afterwards if I show up without wearing pants) without any more bullshit

- I value my free time, but I also love to work on Things™. Any such 'homework' assignment would be a tiny pet project to drag me away from YT/HN/Awesomenauts and force me to learn something that I might not have picked myself

In fact, I even thought about posting an Ask HN sort of thing to offer (limited somehow, day-job and being a dad and all) working for free in exchange for the input. I just haven't done it so far, because of fear of failure/rejection.

So - you state a good point: People might not want to invest the time. But please speak for yourself only, not for the industry. I very much like the idea of presenting work done at home.

That said, I probably wouldn't do both. If someone asks me quizzes first (and I manage to pass for weird reasons, stars align) I wouldn't invest more hours. You, the employer, just wasted hours with crap while you could've gotten ~reasonable~ accurate ideas about my work. If someone asks me to do one of these assignments, invites me to come over and THEN starts the quiz BS I'd probably get up and leave.

Employers: Pick one way to test my skills. My preference: Judge skills in a remote/async process, use the face time to check for a cultural fit / negotiate / talk about the company, position and job: "We invited you after seeing your work, here's why you should work with us, this is the offer and these would be your coworkers - let's chat and do the tour"

Re: Three hundred programming interviews in thirty days

#238

Post by raverbashing »

mycelin wrote: post #233
foldr wrote: post #182

Earlier quoted context omitted.

In fact GCC will virtually always produce optimal code for multiplication by a constant. Targetting AVR, for example (which doesn't always have hardware multiply), GCC produces more compact code if you use '*' than if you use '<<'. Similarly, any attempt I made to multiply by non-round constants using bitshifting and addition led to less compact code.

Uh, extremely unexpected.

Not really, simplifying simple operations (like multiply by a constant) is pretty much Compilers 101 / Dragon Book kind of stuff

Re: Three hundred programming interviews in thirty days

#239

Post by nickzoic »

NickPollard wrote: post #235
mjfisher wrote: post #227

Earlier quoted context omitted.

Good, I think? It wouldn't be a deal breaker at interview for me (or even something we test for, come to think of it), but they were right in that it is a magic number. Unless you are doing something where the context is so perfectly obvious that number should be an 8, it's better off tagged as a constant so the next dev to come along has a better chance of understanding your code.

Indeed: static const int eight = 8; x * eight; Sometimes magic numbers are just that - numbers. Adding constant definitions is often a good thing, but sometimes just adds noise.

I think you mean

    static const int days_per_week = 8;
:-).

Re: Three hundred programming interviews in thirty days

#240

Post by Scarblac »

RogerL wrote: post #24

"as soon as we started doing them however, I saw a problem. Almost everyone was passing." Why is that a problem? Maybe almost everyone is decently good (as evidenced by having a string of jobs, and presumably, references), and your interviews are creating tons of false negatives.Or heck, vice versa. You don't know. You are presuming your conclusions. You have no basis to make conclusions yet, you just have incomplete…

If they want to market themselves as being great at screening candidates so that they send only the best to interviews at client companies, then a test that 90% pass isn't of much use to them.
Post reply on HN