Live data from Hacker News

Interviews Can Be a Terrible Way to Identify Good Programmers

thecodist.com

51–60 of 108 posts

Re: Interviews Can Be a Terrible Way to Identify Good Programmers

#51
post #8

/sigh interview techniques really are a perennial topic on HN. > [a coding test] won't tell you squat about how good they are in a year long project with 10 other people, The author misses the point of a coding test. It's a negative rather than positive filter. Someone who does amazing on FizzBuzz is not by definition an amazing programmer. Someone who can't solve FizzBuzz however almost certainly is not a good progr…

Interviewing is a perennial topic because it doesn't make much sense.

Case in point - over the past week I've interviewed for four positions. Three gave me offers within a day, with very little effort on my part. On the other hand, one told me that I had little idea of what I was doing and told me to study up and apply again next year. And, that was after wasting my time with 3.5 hours of interviews. Of the offers I received, two were well over 120k plus great bonus. The other came in under 90k but told me that I could work anywhere in the world, whenever I wanted, as long as I got my work done.

Over that same time, I flat out rejected three recruiters from large engineering companies because their recruitment processes would have cost me $700-1500 just in opportunity costs. And, they weren't even willing to give me the info I needed to help me determine my chance of success or even my expected pay.

Everyone these days seems to believe that their company is so important that they deserve or need a team of top 1000 engineers. When in fact a top 20-percent team who bonds well together would likely be sufficient.

The topic of interviewing is fascinating because there seems to be very little science behind it. Who knows what works?

Re: Interviews Can Be a Terrible Way to Identify Good Programmers

#52

Earlier quoted context omitted.

SQL equivalent: "Explain the difference between a left join and a full join." ...seriously, this filters out a depressing number of people who put SQL on their resume and are applying for a SQL job.

There are a lot of people who've used SQL, and therefore will think it's perfectly honest and accurate to list SQL experience on their resume, and who've written perfectly fine queries to get shit done, and yet they would not be able to answer that question, especially in an interview/interrogation situation. Also, in real life, under normal working conditions, we live in the Age of Google (and books) -- if someone e…

There's a still a certain level of familiarity with the subject matter required to do a job. If the role can be defined as an "SQL job" (say something in data warehousing or reporting) - not knowing what types of joins are available could lead to terrible solutions.

I would agree with you if the interview question was more specific, say about Oracle window functions for example.

An SQL developer not familiar with full joins would be similar to a Java developer who is not familiar with interfaces, or a Javascript developer who has never heard of closures. It's a significant part of the language, not a piece of arcane reference.

Re: Interviews Can Be a Terrible Way to Identify Good Programmers

#54
I agree with having someone who's already in the role interviewing you. Let the HR and managers interview the programmers last. This way you can filter out a ton of people before they waste everybody's time. One my last interviews the guy who interviewed me was a "change management" director. I thought to myself, "This is going to be a short, easy interview."

After being the industry for a while, I feel the best way to hire someone is still on referral. Developers know good developers and the good ones tend to stick together. They also know what their friends skills are, what they excel at, and what kind of work they would recommend.

Also, in the end, I learned its not what questions they ask, it's not about the stupid quizzes they put you through. Developers have to learn it's about you knowing enough about the company or asking enough tough questions to determine if it's going to be a good fit. Developers should have as much, if not more of a responsibility in vetting the companies they choose to interview with.

Re: Interviews Can Be a Terrible Way to Identify Good Programmers

#55
post #8

/sigh interview techniques really are a perennial topic on HN. > [a coding test] won't tell you squat about how good they are in a year long project with 10 other people, The author misses the point of a coding test. It's a negative rather than positive filter. Someone who does amazing on FizzBuzz is not by definition an amazing programmer. Someone who can't solve FizzBuzz however almost certainly is not a good progr…

What about the cases where they sit you through 10 interviews and because you didn't get one question right or syntax errors on white board you wouldn't get an offe. on the plus side I can think that I shouldn't be working with them but it becoming increasingly common practice among silicon valley tech companies to ask obscure( not fizzbuzz) random coding questions that either you know it or you don't have enough time to solve in a interview. Even with a github profile and coding contributions to open source projects is not helping.

Re: Interviews Can Be a Terrible Way to Identify Good Programmers

#56

No offense, but the only advice I've learned from all these "how to hire programmers" article, as a programmer, is that it doesn't make a damn bit of difference, because every person hiring as their own idea of what works. The best thing I can do to get hired somewhere is be myself. For every person who says not to bother with a resume, there is another person who wants them. For every person who denounces certain te…

It seems to me that regardless, you need to still have a CS degree and understand (and be able to implement) algorithms of increasing complexity, even if you're making a CRUD app. But I agree, these interview posts altogether don't seem to say anything consistent.

>you need to still have a CS degree and understand (and be able to implement) algorithms of increasing complexity

One doesn't necessarily lead to the other, and the absence of A doesn't exclude B.

It's a common mistake to believe that CS cannot be self-taught.

Re: Interviews Can Be a Terrible Way to Identify Good Programmers

#57
post #32

Earlier quoted context omitted.

SQL equivalent: "Explain the difference between a left join and a full join." ...seriously, this filters out a depressing number of people who put SQL on their resume and are applying for a SQL job.

What is a full join? I've been working with Oracle for 10 years and I've never used that term. I know what a left join is and an outer join, but not a full join.

It's an outer join.

Re: Interviews Can Be a Terrible Way to Identify Good Programmers

#58
I'd think a good way to hire great developers is to hire and fire quickly. I see this mentioned time and again, yet very few people actually live by it. The process would then turn into a trial period beyond which you are good to go. If you want to have a group of good developers, just operate along the lines of "I give myself X months to notice that this new hire is bad." If you want a group of great developers, switch your mode of operation to "I give this new hire X months to impress his/her peers."

The people who can make the judgement call are usually the hire's peers based on their daily interactions, so how would management be able to get its hands on this knowledge without turning the company culture into a disaster where people always feel like they are being continuously judged by their peers and have to watch their backs?

Re: Interviews Can Be a Terrible Way to Identify Good Programmers

#59
post #51
post #8

/sigh interview techniques really are a perennial topic on HN. > [a coding test] won't tell you squat about how good they are in a year long project with 10 other people, The author misses the point of a coding test. It's a negative rather than positive filter. Someone who does amazing on FizzBuzz is not by definition an amazing programmer. Someone who can't solve FizzBuzz however almost certainly is not a good progr…

Interviewing is a perennial topic because it doesn't make much sense. Case in point - over the past week I've interviewed for four positions. Three gave me offers within a day, with very little effort on my part. On the other hand, one told me that I had little idea of what I was doing and told me to study up and apply again next year. And, that was after wasting my time with 3.5 hours of interviews. Of the offers I…

People make several mistakes when analyzing interview techniques:

1. The interviewer and interviewee are after similar and complementary things.

Wrong. The interviewee is trying to find out if the work is interesting, whether or not this would be a good place to work, whether or not he or she could work in that environment with that team and so on.

The interviewer (or rather the employer) is trying to fill a position. This is really important.

Some make the mistake of thinking that if an interview process doesn't evaluate the interviewee accurately it has failed. This is grossly inaccurate. The point of an interview process shouldn't be to look at a single candidate but to look at the process of filling a position, which may well span interviewing many candidates.

A false positive (someone who looks qualified but isn't) for an employer can be incredibly costly. The cost of a false negative is essentially zero as long as the employer can otherwise adequately fill the position.

To spell it out: if an employer gets 50 applications, has phone interviews for 8, brings in 4 for face-to-face interviews and makes two offers, one of which is accepted, the employer has gained the desired result. The fact that a qualified person was rejected along the way (false negative) is essentially irrelevant.

2. Your worth is constant.

Wrong. You said it yourself. You got several different offers. You're implying that if you had been accurately gauged market conditions would have you valued roughly similarly.

Company A might be desperate. Company B less so. You may fill a niche far better at one employer than another. One employer may simply be more cashed up and able to pay a better salary. A given employer may simply suck at negotiating or be under a misconception about market value. The list goes on.

Likewise, your desirability to the employer factors into this and it goes beyond technical skills. If the employer thinks you'll be a great fit and they'd really like to work with you, that improves your worth (to them).

3. Companies are looking for the same thing.

Clearly this is wrong but I do see this attitude come up, typically being implied by showing mismatches in offers as "proof" or similar.

There are many examples of this. For example, all other things being equal I've found that an MIT graduate is much more likely to hire other MIT graduates. The same is true for Stanford, CMU or [insert school here].

Part of this is the "social proof" element (going to a great school and/or working for a top-tier employer can be a huge advantage). But more than that it comes down to cultural similarity, common background and being a known quantity (to some degree).

This is of course different for every employer.

The real problem with interviewing, particularly at larger organizations, is that people who are bad at it are doing it. Interviewing and assessing potential colleagues is a skill and a talent. Some people have it. Some don't.

I've seen another comment here that said you need great engineers to do interviewing. I disagree. Many great engineers seem to be essentially savants who are often ill-equipped for the social discourse entailed in interviewing.

To interview an engineer I firmly believe you need to be an engineer (the same goes for managing engineers) but you don't need to be a rock star. You just have the right additional skills.

Re: Interviews Can Be a Terrible Way to Identify Good Programmers

#60
post #5

One of my favorite questions is: "What's the best bug you've ever found?" Usually I get a "Huh?" The really stellar folks will tell you about the bug that took two weeks to find and boiled down to a single missing comma in a vendor's library routine. Or /something/. But "Huh" is a bad sign. "Huh?" is not a fail, but it usually correlates with people who can't write a function to find the length of a string, and I see…

Oh boy.

I seem to remember the

  (member 1 '(1 2 3)) -> t
  (equal '(1 2) '(1 2)) -> t
  (member '(1 2) '('(1 2) '(3 4))) -> nil
bug. It took me just three hours, but boy was it annoying. In the end, it was just me not knowing the language of course.
Post reply on HN