Live data from Hacker News

Three hundred programming interviews in thirty days

blog.triplebyte.com

171–180 of 248 posts

Re: Three hundred programming interviews in thirty days

#171
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.

Ah, but the willing aren't able and the able aren't willing. In any case, I'd avoid companies that recklessly fleece applicants just because they can. Once you've proven your worth professionally, begging for scraps is pathetic in any job market. For every greedy business with ten desperate applicants, there's an honest organization or untapped market ready to pay fairly for what value you offer.

The question I consider when asked to perform for free: why should anyone simply donate their knowledge to a profitable business after spending a lifetime to attain it?

Re: Three hundred programming interviews in thirty days

#172
post #27

Earlier quoted context omitted.

Yeah, we agree. We don't plan on asking everyone to do hours of work on their own. A lot of people don't have the time. However, we're also seeing a bunch of applicants who are good programmers, but become really stressed in interviews and do badly (they freeze). These people have trouble getting jobs. What we want to do is offer them the option of doing a larger project on their own, rather than our final interview.…

Interview environments are always stressful, but so are other common workplace situations. Being unable to manage stress effectively might contribute to poor on-the-job performance, even for people with great pure coding ability. The process right now seems focused on finding people who are the best at only coding. In the future, do you intend to also consider communication skills? Senior developers act as mentors fo…

It's amazing to me that a real human who has experienced job interviews could think that common workplace situations are comparable coding in front of a stranger at a job interview.

Re: Three hundred programming interviews in thirty days

#173
post #39

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…

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…

If 90% of the people pass the take home test, then why was that step necessary in the first place?

I've also soured on take-home test. I recently did a C/C++ one, I know I aced it, and I didn't even get a phone interview.

I figured out afterwards what they were doing. They were giving the take-home test to EVERYONE who applied. Then, after you submit a solution, they read your resume. After looking at my (correct) solution and my resume, they decided I wasn't worth a phone interview.

No more take home tests for me.

Re: Three hundred programming interviews in thirty days

#174

I personally hate the "take home test" approach to interviewing. I've had multiple such tests that take anywhere from 10-25 hours to complete because simply answering the question isn't enough; you need to give textbook correct answers and your code must be formatted perfectly with the requisite comments and documentation. In short, it's pretty similar to an upper-level college course's final exam; however, in colleg…

If only there was some way that people could spend a couple of years proving they had basic competence, so they didn't have to prove basic skills on every interview.

Why did I get a CS degree if every interview starts with the assumption that I'm an unqualified loser?

Re: Three hundred programming interviews in thirty days

#175
post #116

Earlier quoted context omitted.

They don't pay you for the interview, but that usually costs the company several man-hours worth of work just for the time an applicant is on-site. Should applicants be reimbursing companies for failed interviews?

Maybe. I've always thought it would be interesting to make applicants pay an application fee. This would cut down on people "spraying and praying" with their application, and would lessen the workload for companies. It would also justify spending more time and effort in reading applications, since the company isn't just wasting resources reading bad applications. Even under the current system, at least the waste is s…

There is no way in hell that you will get someone to pay an application fee on top of having to burn a vacation or sick day.

Re: Three hundred programming interviews in thirty days

#176
post #174

I personally hate the "take home test" approach to interviewing. I've had multiple such tests that take anywhere from 10-25 hours to complete because simply answering the question isn't enough; you need to give textbook correct answers and your code must be formatted perfectly with the requisite comments and documentation. In short, it's pretty similar to an upper-level college course's final exam; however, in colleg…

If only there was some way that people could spend a couple of years proving they had basic competence, so they didn't have to prove basic skills on every interview. Why did I get a CS degree if every interview starts with the assumption that I'm an unqualified loser?

Because, unfortunately, a lot of people receive CS degrees but are completely technically incompetent.

Re: Three hundred programming interviews in thirty days

#177
post #174

I personally hate the "take home test" approach to interviewing. I've had multiple such tests that take anywhere from 10-25 hours to complete because simply answering the question isn't enough; you need to give textbook correct answers and your code must be formatted perfectly with the requisite comments and documentation. In short, it's pretty similar to an upper-level college course's final exam; however, in colleg…

If only there was some way that people could spend a couple of years proving they had basic competence, so they didn't have to prove basic skills on every interview. Why did I get a CS degree if every interview starts with the assumption that I'm an unqualified loser?

Because lots of people with CS degrees don't have basic programming competence?

Re: Three hundred programming interviews in thirty days

#178
post #146

Earlier quoted context omitted.

Interview stress is of the type I call "defusing the bomb": everything at stake, essentially immediate time constraints and confrontational. This never occurs in real life.

"Unfortunately something not so different sometimes does. E.g., you're at a startup, you have a critical demo for your best-hope customer, it was scheduled very aggressively because the CEO wanted to fit the customer's availability, it's happening in one hour, and nothing is working. Not exactly confrontational (though it could easily get that way if you aren't careful) but just as stressful. Of course it's far bette…

So you're interviewing someone and basing a large part of the experience on something that would otherwise happen maybe 0.1% of the time? Also that CEO sounds like an asshole.

Re: Three hundred programming interviews in thirty days

#179
post #99

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…

My last company had a screening coding problem that was designed to take around a day (although it didn't have to; when I did it as a reference point, it took a couple of hours). I was always kind of astonished how many applicants were willing to do the whole thing, given, as you say, that they often already had a full-time job and/or were applying for multiple positions. We always gave really extensive feedback on i…

When you get a coding assignment, you have no idea if they're going to give honest feedback if you submit a solution, or if they're just going to say "Thanks for applying, but we decided to go in a different direction."

Re: Three hundred programming interviews in thirty days

#180

I've done over 1000 interviews and my experience agrees with their findings that talking about a project is not a good predictor of coding. I usually left detailed resume questions for the end since so many candidates would bomb the coding part of the interview. I'm surprised they didn't get stronger results from fizz buzz, but I noticed among the candidates I saw that the percentage of 'non-coders' is substantial bu…

I really don't mean to cast aspersions on your interviewing abilities, but the common factor in all of the interviews you've conducted is you, and how you talk to a candidate abut prior projects can really matter. At one extreme you have "tell me about your last project" free-form. At the other you have highly-specific drilling down on a relevant technical issue (e.g. flow-control mechanisms in Ethernet networks) or…

I totally agree with you that the "ask about projects" question requires care. And, yes, I did see differing results depending on how the discussion went. When I did the question, I've run it as both a 1-minute quickie and a 15-minute conversation. I tried my best to dig an solid technical exposition out of the candidate if I could.

Typical cases where the project discussion was not helpful:

* Senior engineers could often talk in great detail about things they'd built, but then would most often bomb coding questions.

* A lot of MS/PhD-level new grads could give great talks (about almost anything) but again would bomb coding stuff.

* Lots of ESL candidates struggled tremendously to convey basic project details, but nevertheless were solid coders. From my TAing experience in grad school, I noticed that there are a lot of ESL CS students who have poor oral communication skills but are orders of magnitude stronger at written communication. (This made strong textbooks and written references crucial to the courses I TAed).

* Sadly we hired quiet a few senior / PhD-level people who could give great talks, were highly responsible, but were eventually fired for poor coding. (There were also some management disasters associated with those cases, but stronger coding skills would have helped them nevertheless).

Interviewing has both subjective and 'objective' parts. The most objective data one can collect are things like completion times, the actual code written, and (perhaps) raw contextual data like a measure of the candidate's mood (were they sweating like mad?). Project discussions rarely recover solid objective data. So, I'd definitely recommend against outsourcing those questions to a service like Triplebyte, and junior employees should probably also not be spending 15 mins on projects for /every/ candidate.

Post reply on HN