Live data from Hacker News

We can't judge another programmer's abilities in a 60 minute interview

linkedin.com

151–156 of 156 posts

Re: We can't judge another programmer's abilities in a 60 minute interview

#151
post #27

Earlier quoted context omitted.

Funny that this was brought up. I agree fully that it's rare. But...a friend of mine was "den mother" for graduate students in a top 20 comp sci program. The students were often doctoral candidates but could also be MS students doing a thesis. A large part of her job was prepping them for interviews with companies like Google, MS, Oracle, etc. Here are a few gems she had to remind/inform them of. "Yes, you have to sh…

If I was going to an interview with a company like that, I would want to know - will they reject me if I wear a suit? If so, what is safe to wear?

It depended on the company. MS interviewers came in khaki slacks and buttoned down shirts. Google came in jeans with lots of ink and piercings on display.

Part of my friend's responsibility was to give feedback to the interviewers. Her students were passing over MS to go to Google, despite MS offering significantly more for a salary. Their interviewers asked her for feedback to figure out why. She had to politely say that Google was seen as cooler. (The cooler impression wasn't just the image gained from the interviewers, it was the problems Google was trying to solve. But, the interviewers added to the company's image of "coolness".)

She held this position probably a decade ago and left after a few years. Things may be different now.

Re: We can't judge another programmer's abilities in a 60 minute interview

#152
I am approaching 1.5 decades as an employed software engineer. Interviewing culture seems to change a little over the years, but usually in other wacky directions that leave me feeling entirely disengaged from the industry. I also very much love my vocation, though it alone is not enough to keep me enduring through the insanity of technical interviews , "cultural fit" assessments, and the violence of linear reductionism.

Articles and discussion threads like this are pretty much the only reason Im willing to interview at all (and thus remain in the industry). So thanks for sharing, Im glad to know other people are aware of how bonkers this is.

The long version takes years of explaining.

The short version is: I am highly allergic to cognitive dissonance.

Re: We can't judge another programmer's abilities in a 60 minute interview

#153
post #73

Maybe making the 'extended interview' process more formal would be a good thing. Formally have an internal 'contract' worker process where anyone they might want can be hired in to a trial pool, and projects can bring in the trial worker for small things quickly (maybe writing unit tests, or a fresh set of eyes, etc). Every month review performance, make a decision to offer job as X, keep on for another month, or let…

Why in the world would anyone be interested in doing this? Companies are competing for talent, not the other way around.

Because there are people out there looking for work. It's not trivial for all programmers to find a job. I am in particular really awful at the entire applying and interviewing process (except funny little algorithms problems, I can kill those). It's a stressful, amorphous blob of everything I hate.

What the parent of your comment describes sounds a lot like a specific kind of contract-to-hire, which if it's done well can be really effective. I get to show off that I can actually develop software well, a company gets to judge me on more than just an hour (or maybe a day) of questioning.

Unfortunately it can be pretty exploitative if done wrong. It's easy for it to become an unending period of low-paid work where you're just hoping that one day it'll turn into a real job.

Re: We can't judge another programmer's abilities in a 60 minute interview

#154
post #48

Earlier quoted context omitted.

Because if you can't FizzBuzz, you definitely aren't going to be able to pick up the codebase in a satisfactorily short amount of time. If you come in in gross clothes and swear, you're not going to fit the company culture. If you're rude to your interviewer, you're not likely to be less rude to your other coworkers. etc.

I cannot recall the last time I interviewed someone for a position other than intern who could not at least muddle through a FizzBuzz problem. I'm talking hundreds of candidates. The likelihood of a "lucky streak" as long as that if "can't FizzBuzz" is common (i.e. not an outlier) is small. Usually when I dig into a person claiming "can't FizzBuzz is common" the result is I find what they're calling "FizzBuzz" is not…

I have to assume you are doing some kind of very strict resume screening or your application form is behind a puzzle or something - I 100% guarantee if you post your job broadly and interview everyone who applies you will have a very bad fizz buzz rate (and probably go insane), and I believe that if you do filter but try to keep an open mind to non-traditional backgrounds you will have a pretty significant fizz buzz fail rate. (I too oversee the screening of hundreds of candidates out of thousands of applicants.)

Re: We can't judge another programmer's abilities in a 60 minute interview

#155
post #60

Earlier quoted context omitted.

I've also "heard" that the ratio of people who fail at fizzbuzz is truly disturbing even if they have impressive CV's. It makes me wonder, though. Has anyone ever just admitted they failed at fizzbuzz here on HN? I can imagine someone bombing it if they're nervous or if they forgot the modulo operator in their language of choice and got lost doing it an "ugly" error-prone way because they were too embarrassed to chan…

I've wondered before how many of the "OMG tons of candidates can't fizzbuzz" anecdotes come down to messing up syntax or forgetting the name of something in the language they're using and mixing in something from another language, or making a plausible but incorrect guess. I could definitely see doing those things in an interview, and I've usually been considered the "smart one" or one to come to with weird/low-level…

I really don't think it is very many. There are clear patterns of failure for fizzbuzz - the biggest is the "copy-paste programmer" who sees a blank canvass and just has no idea where to start. Then you have your people who can write conditionals but can't reason about them - they will very often end up with a solution that compiles, but always prints the number no matter what, or never prints FizzBuzz, or some other obvious error that should be apparent on a quick review of ones code. Most of these people also take 10-15 minutes to write it out, where competent programmers consistently bang it out in five minutes or less. (And yeah, some of them probably know it by heart by now. Oh well.)

Screening someone who just absolutely can't program at all is, IMHO, by far the worst part of technical interviewing.

Re: We can't judge another programmer's abilities in a 60 minute interview

#156

Earlier quoted context omitted.

>Companies with defined, well established revenue streams need to build mentoring programs that turn mediocre developers (solid C) into good (solid B) developers. Those employees tend to be the most loyal and are capable of a great amount of menial to boring coding tasks without complaint. In general, when coding, if you're doing a menial or boring task you're doing something wrong. E.g. I've worked with a ton of med…

>In general, when coding, if you're doing a menial or boring task you're doing something wrong. E.g. I've worked with a ton of mediocre developers who don't automate the menial tasks and end up doing the task manually, sloppily and slowly. That’s total BS. Development is full of boring mediocre tasks such as fixing spelling mistakes in UI controls, updating help messages for dialog boxes, or porting the product from…

>That’s total BS. Development is full of boring mediocre tasks such as fixing spelling mistakes in UI controls, updating help messages for dialog boxes

I would say this counts for much less than 1% of what I have to do. A lot of this stuff is in files which I can give product owner control over, too.

>or porting the product from one build system to another.

And this isn't boring. Build systems are tricky and filled with pitfalls. The worst thing you can say about build systems is that it's not a prestigious task.

>I’ve lost count of the number of times a clever programmer has tried to automate the process and completely mucked things up, forcing me to go in and fix things manually.

Yeah, and fixing things manually in that case is boring. As I put it above "if you're doing a menial or boring task you're doing something wrong" and you precisely described "something wrong".

>That’s exactly where a great product manager can mentor a mediocre developer in making a sensible change.

Product managers are not the right people to teach this kind of thing.

>Of course. It’s also vastly better that to be born rich so one doesn’t have to work at all.

Unlike being born rich, which is out of your control, you are able to exercise some degree of control over whom you work with.

Post reply on HN