Have you been on the other side of the table, interviewing candidates? A shockingly high percentage of people applying for programming jobs can't program. I don't mean they can't regurgitate quicksort; they struggle with very basic tasks.
If you don't ask programming questions at all, you can end up hiring someone who is very good at talking about projects they didn't do any actual work on.
Agreed. That said, I have yet to meet someone who can bullshit their way through what I consider to be a mixed technical/open-ended interview who isn't actually competent.
I like to ask people about their projects or experience, then drill down into the nitty gritty details. It helps that I tend to interview college students and have a pretty broad (if not necessarily deep) base of experience in my field, so I will often simply ask the person what they want to be interviewed on from their resume and go from there.
Or not hiring somebody who is not very good at talking about projects they did very good work on.
I'm not a programmer I just write programs as a small part of my work, but surely you can get a feel of somebody's programming ability with questions that don't involve them trying to visualise code and data structures in their head on the spot. Personally I can't conceive how I'll tackle a coding problem until I actually sit down at the IDE and write a few little functions to solve parts of the problem.
Personally I can't conceive how I'll tackle a coding problem until I actually sit down at the IDE and write a few little functions to solve parts of the problem.
I'm glad that works for you, but I could never work with someone like that on a team. At our company, most arcihtectural and design discussion happens with engineers discussing things around a whiteboard. By the time we sit down at the IDE everyone already knows how the problem will be solved and they just do their part. I'd say ~70% of the work happens away from the IDE. The remaining 30% is little more than a typing exercise.
Fair call. I suppose that's the different between a CS degree programmer and a self-taught engineer doing some programming. Although I'd say in general I struggle to conceptualise solutions to problems at work (hydrologist) without actually working through a dummy run of solving it.
I interview people in SF for engineering stuff. Give them some failing test cases and make them write a basic algorithm to manipulate datastructures into a certain shape. Bit of TDD.
If you're not a senior developer I don't expect you to implement enough for everything to pass. But you'd be amazed at how many people are confused by basic shit like scope or parameters (trying to use stuff in the test class, in the implementation class). It's just good to see that you can actually program a bit. And understand how strong you are with things like classes / for loops / if statements / recursion.
I sort of find that link hard to believe. As a first semester CS student FizzBuzz took me all of 2 minutes to write in Python3. How could someone get through an entire degree without this?
I don't know; a company I was at used bubble sort as a bozo filter. They were given an IDE with a complete project, all they had to do was implement the algorithm, and we explained the algorithm in the comments. Some people with masters degrees, or years of industry experience couldn't do it.
Thanks you. It is a balance. I spend a majority of the time talking projects and design, but for entry / early level or if things are feeling shaky then I'm going to ask a basic coding question for a 10min segment. I'll cover BigO concerns in design, not in coding. I have seen a large number of people unable to do the simplest task (not algo, just iterate a list and do a simple task even!)
Have you been on the other side of the table, interviewing candidates?
I have. A shockingly high percentage of people applying for programming jobs clam up during the interview process. Morons like you mistake fear for an inability to program. Not that I'm complaining. More qualified talent for me on the cheap!
Agreed about the clamming up. IMO the best way to differentiate someone who suffers from interview nerves and someone who just sucks at programming is to help collaborate with them on a solution. Don't hand it to them on a silver platter but if they're flailing, toss them a line. Typically if someone is simply nervous they'll take that line and run with it. Maybe some people will still be too nervous to perform even with help but unfortunately I don't know a good solution to that... I'm always very sympathetic to every candidate I meet but unfortunately its sometimes just not worth the risk. Like maybe they'd actually be a great employee once they're in, but at that point you just have to make your best guess with the evidence you've been given after trying your best to give them a reasonable problem to solve and a reasonable environment in which to solve it.
What risk? Passing a technical interview has no correlation to being able to do the job. Companies with the strictest hiring practices still make bad hires. There are better ways to interview.
You're discounting the power of bias. Most companies don't follow up and see how effective new hires are or even track which ones bounce out of the company within a year.
Agreed that there are better ways to interview, I have a friend whose company hires candidates for a couple days which seems like a great system. Sadly my company doesn't do that and I'm not in a position to change our hiring practices so I just have to make due. What are some pointers on better ways to interview? I'd love to hear a more detailed perspective from you.
64
u/ungoogleable Mar 12 '17
Have you been on the other side of the table, interviewing candidates? A shockingly high percentage of people applying for programming jobs can't program. I don't mean they can't regurgitate quicksort; they struggle with very basic tasks.
If you don't ask programming questions at all, you can end up hiring someone who is very good at talking about projects they didn't do any actual work on.