Live data from Hacker News

Three hundred programming interviews in thirty days

blog.triplebyte.com

241–248 of 248 posts

Re: Three hundred programming interviews in thirty days

#241

Earlier quoted context omitted.

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

I encourage people here on HN to take a look at your footnote [2] and consider it. We talk a lot about how programming has "low barriers to entry", but this is very misleading. It really just means that there are no legal barriers to entry.

I recently interviewed at google, and while I can't talk specifically about questions, I would say that medium to difficult level questions from "Cracking the Coding Interview" are representative of what you must be able to do to a startling (in my opinion) level of efficiency and accuracy. A question like "find the sub matrix with the largest sum in an NxN matrix" is absolutely fair game, at a whiteboard, on the spot.

Think about what it takes to get to this level of competence, where you can pass an exam like this. Granted, google is notoriously tough, but it's pretty common in the industry. And as you point out in your comment, we have to do this over and over.

I read about a guy who passed the bar with 100 hours of study

http://blakemasters.com/post/37113468298/pass-the-ca-bar-exa...

The bar exam (in California) is considered one of those brutally difficult, high barriers to entry that at least you only have to do once (there are training requirements to remain active in the bar).

Now, think about how much time it takes to get up to speed with data structures and algorithms, operating systems, and combinatorics, to the level where you can solve tough problems in 45 minutes to a high level of accuracy with a dry market at a white board, under the additional pressure of an in-person interview. It's hard to even think under those conditions, in my opinion.

I really don't think it's too far off to say that if you do three interviews, at difficult tech companies, you've done something approaching passing the bar.

I've heard a few people here on HN say that while they aren't in favor of a formal barrier to entry like the bar exam, they would happily take an exam like this if it meant that they didn't have to keep doing it over and over. Where they could properly prepare for it, and take it, and pass it for once and for all[1], with a proper study path, under conditions that would be consistent and fair, and get the results back (rather than a mysterious "we don't see a match at this time").

[1] As with many formal credentials, I have no problem with further education requirements to stay up to speed. The problem here is the capriciousness of it all.

Re: Three hundred programming interviews in thirty days

#243

Earlier quoted context omitted.

Regardless of the compiler, let's say (x Some interviewers (not just the "homework") raise their bar by not allowing you to make any tiny mistake. And I just don't get it. If someone is good enough to write something like a lite version of Hacker New website in hours, I'm not going to turn him/her down because of such mistake.

What the hell. A developer who writes x If I found bit shifting in an interview code sample as a replacement for basic multiplication, I would ask the developer why they chose to do it that way. They'll either a) calmly explain that their computer science classes taught it that way or it's a habit they've adopted after writing code for embedded systems or similar where the optimization actually made a difference, or…

Or it's idiomatic for that language.

Re: Three hundred programming interviews in thirty days

#244
post #204
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…

"these tests allow the company to burn a lot of a candidate's time, but not the other way around " Oh yes the other way around. At a previous employer, two of us took 3 full time months to review over 100 qualified candidates (i.e. that returned the task) to make 10 offers. We made an offer to anybody who met our standards - whilst management initially restricted our headcount, they allowed us to expand the team as g…

Wow, you did spend a lot of time on these exams. 160 hrs a month, 3 months, 2 developers, that's 960 hours, easily. For 100 candidates, that would mean you spent almost 10 hours on average per candidate. In this case, I think you may have been spending more time on many of them than they are spending on you. However I may feel about take home exams in general, I will certainly say that clearly you are not using take-home exams externalize the inefficiencies of the interview process.

Unfortunately, I don't have any much evidence for my next statement, other than bits and pieces, but I think you are not a common case here. I don't think that most companies do anything close to what you're doing with these take home exams. My defense for this statement without much data is that companies are deliberately secretive about this - I understand it is for legal reasons, but I have no idea, none, if anyone even looked at my project.

Remember, McDowell said that this approach allows the company to burn a lot of a candidate's time, but not the other way around", but it doesn't say that they necessarily do. It's just that the equivalence (a 1 hour interview necessarily involves one hour of the company's time) isn't built into the process, it leaves the door for this kind of time wasting and abuse open, and I'm pretty sure lots of companies do abuse it this way.

BTW, if an employer promised to spend 10 hours reviewing my 6-7 hour homework project, with feedback, I'd try to find a way to make the time available, because it would be beneficial to me regardless of whether I got the job. But if they brush me off with a one liner from a recruiter a full month later, and ask people not to post the project to github (even if it might lead to interesting and novel solutions), I'm going to guess that they aren't doing what you're doing with these projects.

Re: Three hundred programming interviews in thirty days

#245
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

I was reacting in surprise, because all I saw was the Jobvite job listing, and its echo listings on the other job boards. I had a much more positive experience with the code exercise.

My experience is that what you hear is true, that you shouldn't spend significant time on job listings. The problem is that every other technique available to me had long odds. Professional network? Non-existent. MeetUps? Most people I met there have similar problems. Lunchcruit or similar gimmicks? No response, not even a lunch. I feel like I just got lucky that mavelikara gave me a chance, and I intend not to waste it.

Re: Three hundred programming interviews in thirty days

#246

Earlier quoted context omitted.

> at some point you have to rely on technical people to do their jobs. On one hand, I totally agree that technical tasks should be left to the technical people, preferably those who are actually working on the system. There's almost nothing worse than a manager trying to take technical decisions out of people's hands. > Am I wrong to think if I'm going to manage a 60-100 person organization across three timezones I d…

I hear you about having enough technical ability to understand what's going on and make sensible decisions. Certainly in a role like that and the one I have now a mix of technical and positional authority are required. But at what point does it become ludicrous? When your CIO is yelling "No, No! You have to enable the EPEL repo or you'll patch to the wrong version!"?

Yep, it's clear that neither extreme is useful, and when that's the case finding the balance is tricky.

Re: Three hundred programming interviews in thirty days

#247
post #7

Earlier quoted context omitted.

From the article, in bold: The really exciting point comes when we can re-run all this analysis, basing it on actual job performance, rather than interview results

How will they gather data about the job performance of the people who did not pass the interview? Without that, the study is only halfway done.

That's true of any hiring system though: how do you gather data on the job performance of the people who don't pass a resume screen? A coffee date? A phone screen? Missing counterfactuals everywhere.

To run a full analysis, you need to hire people randomly - both people who fail and pass your hiring process - and assess their subsequent performance. This never happens in real life.

However, you can still run an informative statistical analysis based on the variability in interview scores and performance scores. For example, the people who scored 5/5 on the interview should perform better than the ones who scored 4/5.

Re: Three hundred programming interviews in thirty days

#248
post #182

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.

The one case so far where I've seen better results using tricks like reciprocal multiplication and shifts was when there was no way for gcc to know it could throw away almost half of the bits due to input range limits. It would be kind of nice to have, say, a 19-bit integer type.
Post reply on HN