4 ms·

I'd like to talk about this from the other side of the table - the interviewee. I think interviewing is broken but I really don't know the answer how to fix it

by zomgbbq 14y ago

I'd like to talk about this from the other side of the table - the interviewee. I think interviewing is broken but I really don't know the answer how to fix it so I have to just "play the game". I'm pretty good at "playing the game" but I am feeling the same level of interview burnout while looking for work as interviewers do looking for candidates and I can't help but think it hurts the industry overall as engineers don't look for new jobs just to avoid the hazing process of interviewing. Without trying to sound like I'm bragging, I consider myself a senior level, talented engineer. Recently, however, the startup I have been working at ran out of funds and I have been pounding the pavement looking for work. The problem is that I don't feel like any interview I have been doing, or for that matter, have ever done, is really a measure of how good I am as an engineer. It's more a stamina test to see how well I can be tortured and hazed and it makes me reluctant to take on more interviews. Most interviews are about being quizzed on the minutae of a language or about solving a programming quiz in 60 seconds while the interviewer critiques thought of every line. I just don't see how these interviews are actually filtering out bad candidates or measuring good candidates. They are measuring how someone performs in a very specific, non-realistic situation that does not emulate how every day work would occur. The worst example of this are the horrible SHL/Brainbench tests that seem to measure memorization more than skill. I do quite well on those silly tests, but I'm not sure they really measured anything accurately. I was the happiest when I got homework assignments as my tech prescreen or was asked to walk through examples of my own code with their engineering team. I feel these are less stress on the interviewee because it is code you are familiar with and are a closer exemplar of what goes every day at work. Or maybe I'm just a wimp.

nbm 14y ago
I've been hired on bravado, reputation, pointless trivia contests, and other ways of interviewing, and it scares me that companies are willing to take on a risk without verifying skills in some way. I've also been on the receiving side of delightful trivia questions like "What are all the ways the character '*' is used in Python?" and puzzle questions that test "creativity"/"ingenuity", whose value are totally alien to me. (I've also done online quizzes/tests, including personality ones(!)) I would like to think there's a broad middle ground in between, but that there isn't a single process that is going to be effective for all companies or for all candidates. In the past, I've used "homework" as a final step in a hiring process, which worked for some (it certainly washed out a few candidates who got passed less strenuous interviewers), but which others weren't interested in doing - including two that we hired anyway and who ended up being great coworkers. I imagine I would feel a bit put out if a startup wanted me to spend 2-4 hours on something before they allowed me the opportunity to get to understand the position and the company (especially since I would hope the startup would look at my open source contributions in lieu of the homework). New grads might have a bunch of opportunities, and they might decide on skipping something with that sort of requirement.
- Serplat 14y ago
  I think you're absolutely correct regarding "homework." It can be a good indicator of a candidate's competency, but many people don't have the patience to do it. I spent much of this past fall interviewing for an internship for the upcoming summer. It's one thing for a company to ask a candidate to devote a day to interviews, after flying them out and putting them up in a nice hotel, but it feels completely different to have the candidate complete some sort of homework. The candidates that you want to hire are likely busy interviewing with several other companies as well, and probably don't have time to work on some random assignment for your company. So, unless your company really stands out, they're just going to pass. I've found that interviews benefit both the company and the candidate, while I can only really imagine homework benefiting the company. I learn a lot about a company from the way they interview and the way developers talk about their jobs; the interaction is really important. Yet, homework assignments don't really have much interaction, and end up being a test of how much the candidate wants the job, instead of how well they fit with the job.
- mikle 14y ago
  1. Multiplication (2 * 4 = 8) 2. Power of (2**4 = 16) 3. *args and **kargs in functions definitions and function calls. 4. Imports (import * from blah). Did I miss anything?
  - nbm 14y ago
    I have no idea offhand if that's the full list - it's the list I come up with when I think about the question. But that's the thing - it's a bad question. It should be asked as "what does this do?" or "how do you do this?", like: "What does this code do: foo(1, 2, kw)?" Or: "How do you import all exported names from a module into your module's namespace?" These show your code reading and code writing skills. The original question is based on unreliable use of memory. Memory is great at slightly-fuzzy-key lookups. It is usually terrible for table scans applying a pattern filter. Think of the challenge "Provide 5 common Unix command line utilities start with t"? Most people who actually know 15 or so of them and regularly use 7 or so of them would have trouble providing all 5. Some will just blank for a minute (because there are just no pathways to work from), most will find 2 or 3. People who studied a Unix text book the night before would also know 2 or 3. A few might just totally blank and become affected by the fact they can't even remember something so easy that they will be unable to answer that question, and may affect their interview performance after that. So it just is not in your interest to ask those types of questions.

by zomgbbq 14y ago

nbm 14y ago

I've been hired on bravado, reputation, pointless trivia contests, and other ways of interviewing, and it scares me that companies are willing to take on a risk without verifying skills in some way. I've also been on the receiving side of delightful trivia questions like "What are all the ways the character '*' is used in Python?" and puzzle questions that test "creativity"/"ingenuity", whose value are totally alien to me. (I've also done online quizzes/tests, including personality ones(!)) I would like to think there's a broad middle ground in between, but that there isn't a single process that is going to be effective for all companies or for all candidates. In the past, I've used "homework" as a final step in a hiring process, which worked for some (it certainly washed out a few candidates who got passed less strenuous interviewers), but which others weren't interested in doing - including two that we hired anyway and who ended up being great coworkers. I imagine I would feel a bit put out if a startup wanted me to spend 2-4 hours on something before they allowed me the opportunity to get to understand the position and the company (especially since I would hope the startup would look at my open source contributions in lieu of the homework). New grads might have a bunch of opportunities, and they might decide on skipping something with that sort of requirement.

Serplat 14y ago
I think you're absolutely correct regarding "homework." It can be a good indicator of a candidate's competency, but many people don't have the patience to do it. I spent much of this past fall interviewing for an internship for the upcoming summer. It's one thing for a company to ask a candidate to devote a day to interviews, after flying them out and putting them up in a nice hotel, but it feels completely different to have the candidate complete some sort of homework. The candidates that you want to hire are likely busy interviewing with several other companies as well, and probably don't have time to work on some random assignment for your company. So, unless your company really stands out, they're just going to pass. I've found that interviews benefit both the company and the candidate, while I can only really imagine homework benefiting the company. I learn a lot about a company from the way they interview and the way developers talk about their jobs; the interaction is really important. Yet, homework assignments don't really have much interaction, and end up being a test of how much the candidate wants the job, instead of how well they fit with the job.
mikle 14y ago
1. Multiplication (2 * 4 = 8) 2. Power of (2**4 = 16) 3. *args and **kargs in functions definitions and function calls. 4. Imports (import * from blah). Did I miss anything?
- nbm 14y ago
  I have no idea offhand if that's the full list - it's the list I come up with when I think about the question. But that's the thing - it's a bad question. It should be asked as "what does this do?" or "how do you do this?", like: "What does this code do: foo(1, 2, kw)?" Or: "How do you import all exported names from a module into your module's namespace?" These show your code reading and code writing skills. The original question is based on unreliable use of memory. Memory is great at slightly-fuzzy-key lookups. It is usually terrible for table scans applying a pattern filter. Think of the challenge "Provide 5 common Unix command line utilities start with t"? Most people who actually know 15 or so of them and regularly use 7 or so of them would have trouble providing all 5. Some will just blank for a minute (because there are just no pathways to work from), most will find 2 or 3. People who studied a Unix text book the night before would also know 2 or 3. A few might just totally blank and become affected by the fact they can't even remember something so easy that they will be unable to answer that question, and may affect their interview performance after that. So it just is not in your interest to ask those types of questions.