Live data from Hacker News

Three hundred programming interviews in thirty days

blog.triplebyte.com

71–80 of 248 posts

Re: Three hundred programming interviews in thirty days

#71
post #58

Earlier quoted context omitted.

I've had a different experience on the hiring side of the table. The coding exercise that we provide as part of the interview has been very successful in surfacing the skill and talent of the programmer. By using that screening device, we have assembled a team of very sharp programmers. It's totally worth filtering out people who choose not to spend the time. Even though we end up losing some potential candidates, it…

A take-home test has a 0% chance of being cheated on? Are you sure you're talking about the same thing here?

Our exercise can't be cheated on because we discuss it with the candidate during the in-person interview and even ask them to change the code in a simple way.

Also, the exercise is designed to be original and so a solution can't be Googled.

Re: Three hundred programming interviews in thirty days

#72
Most of the problems of coding interviews can be solved by good reference checking. Code problems in isolation will never expose how a developer will do when faced with real-world issues, users, QA, and teammates.

Why are people so afraid to pick up the phone and talk to references? I'm always happy to give out my references, and always delighted to talk about the good devs I've worked with, with specifics about what they've done.

Standardized tests don't work for schools and don't work for jobs.

Re: Three hundred programming interviews in thirty days

#73

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 feel that if you are asking a company to invest $100k/yr on you, it is not unreasonable for them to ask for a few hours of your time.

Re: Three hundred programming interviews in thirty days

#75
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.…

I personally prefer it to a point. My only request when I get this type of interview is that I'm allowed to make the project and requirements public on my github for future interviewers. If I'm doing a free project I feel it's fair.

I am curious why you have that requirement. What is the fairness you are striving for?

Re: Three hundred programming interviews in thirty days

#76
post #61

Earlier quoted context omitted.

I've had a different experience on the hiring side of the table. The coding exercise that we provide as part of the interview has been very successful in surfacing the skill and talent of the programmer. By using that screening device, we have assembled a team of very sharp programmers. It's totally worth filtering out people who choose not to spend the time. Even though we end up losing some potential candidates, it…

The problem is that you don't actually have a clear measure of who you're rejecting. Every company uses a similar argument to support their (very different in every case) interview process. The fact that it allowed you to build a great team does not mean that you could not have built a better team by giving other options as well.

True, I see your point, but you also can't just hand-wave away our results. I've been on many development teams that did not have a strong technical screen like this, and those teams suffered from having some technically weak members (people would would always be breaking the build, would write unmaintainable code, or would just plod along and always need help). Our team of six has none of those problems: every one of us is a strong and disciplined programmer.

The other benefit of the coding exercise is that it might filter out a certain level of impatience. We don't have coders who can't be bothered to follow [insert team process convention here].

Re: Three hundred programming interviews in thirty days

#77
post #27

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…

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 for junior employees, and often need to coordinate projects across multiple teams.

Re: Three hundred programming interviews in thirty days

#78
post #63

Many fields require serious professional certification. You can't become a doctor unless you go through a board certification that includes simulated patient interaction. Likewise, you can't build a bridge or a dam without engineering certification. IMO, this article demonstrates the need to certify software engineers; using a process similar to the interviewing process described. Therefore, when hiring, we can skip…

Professional licencing processes establish minimum standards of competence, training and education. They do not guarantee excellence and a license represents that its holder is no worse than the worst legally allowable practitioner. Half of all surgeons are below average. You don't want one of them if you have a choice.

Re: Three hundred programming interviews in thirty days

#79
post #19

> In our first 30 days, we've come up with a replacement for resume screens, and shown that it works well. What's the metric that shows it works well? > The really exciting point comes when we can re-run all this analysis, basing it on actual job performance, rather than interview results. And how precisely do you measure job performance? If this is achievable, I've got a line of companies out my door that would love…

Measuring job performance is hard. A good analogy is measuring intelligence. The IQ test is clearly bullshit (it does not come close to reflecting the complexity and high dimensionality of human intelligence). That said, it's a useful research tool. Across a large number of people in aggregate, it can be used to learn things (like that leaded gas was a really bad idea). We'll be doing the same sort of (very imperfect) measurement of job performance.

Re: Three hundred programming interviews in thirty days

#80
One of the most enjoyable and mutually effective interviews I had included a one-hour pairing session which was language agnostic that required me to describe how I'd implement a basic data structure. The interviewer drove and implemented. This was then followed by a day long session of pairing on real problems with a number of different interviewers. Lunch was spent with some of the other team members, where we discussed basic things like culture, day-to-day affairs, and each of our histories.

This was a great approach to me, because it didn't particularly focus on anything outside of the present. We worked on solving real problems, and contributing to the project. It's a great, low-stress, method of gauging if someone has the chops for what is typically the "day-to-day" life at the given shop.

Post reply on HN