4 ms·

I find it odd that so many comments here highlight the fact that people are giving interview questions that have little to nothing to do with day-to-day employm

I find it odd that so many comments here highlight the fact that people are giving interview questions that have little to nothing to do with day-to-day employment tasks. It seems to me like an enormous amount of time wasted for both interviewers and interviewees. When considering someone for a development/engineering role there are a few basic questions to figure out: 1. Does this person have competence within our technology stack? 2. Can this person communicate clearly? 3. Is this person productive/can this person be productive in our environment? 4. Does this person have characteristics that will allow them to succeed in our environment? Making people jump through hoops like some sort of dancing monkey while they are on a job hunt is needlessly cruel and is a waste of everybody's time. If you regularly see people who can't succeed with what you consider basic engineering questions, you either have a recruiting problem or you yourself have a communication problem. If you expect an interview candidate to expend 8 hours or more working on interview tasks, you should be presenting a unique enough opportunity to justify it. If you expect an interview candidate to whiteboard a solution to a coding problem that they received in the room, that should be part of your everyday work experience and you should go through the process yourself in front of them so that they have an understanding of what your expectations are. If you want to review their code and talk with them about it to determine competency, provide an example of your own code and a set of questions and answers that would be successful. Don't put engineers through a gauntlet of challenges that you would have trouble successfully navigating under the pressure of feeding your own family. They have more than one company they are interviewing with and each company has their own focus. Put them in a position to succeed and give them the chance to do so. That's what you want out of your own people - the ability to succeed given a reasonable amount of guidance and clear parameters for success. If you can't provide the guidance or the parameters for success for an interview, how can anyone expect to succeed in your actual working environment?

danielbarla 9y ago
The question of relevance reminds me of an anecdote. (Before that though; I tend to agree with your points.) A distant acquaintance interviewed for a secretary position. It didn't go well, because she was asked a general knowledge question (something along the lines of: "name some of the planets in the solar system"). She was furious with how irrelevant and unfair this was. It makes me wonder though, would I have hired her? I probably wouldn't have asked that question, but still. When someone is missing some really basic knowledge - even if it's irrelevant - it's not a good sign, per se.
- gwbas1c 9y ago
  One of the things I like to do is ask a factual question about a technology listed on the candidate's resume that isn't required to know in order to hack something together, but is something that "you should know" if you've been working in a particular technology for a few years. These are part of the warm-up, I'll ask one or two right at the beginning of the interview and then move to the real questions. Examples are: "How does the autorelease pool work?" (Objective C before everyone switched to ARC.) or "How do you ensure that an object is garbage collected," (C# and Java.) These are more about judging a candidate's real knowledge versus stated knowledge. Someone who's spent 8 years in Objective C better know how to use the autorelease pool; and someone with at least a year of experience in a garbage collected language better know how to ensure that an object is collected.
  - sobani 9y ago
    As someone who has worked in C# for about 8 years: you can't. You can call `GC.Collect()` and hope. But far as I know the GC will do a best effort and gives no guarantees. Of course that's besides that fact that I would need strong arguments to accept a `GC.Collect()` anywhere in the code. But to call it just to ensure an object is collected? Oh boy.. Depending on the case you could add some code to the `Dispose(bool)` method to know when your object is collected, but also in that case you risk flipping a Bozo bit.
- roguecoder 9y ago
  Why? Everyone has some things that are "common knowledge" that they don't know. Trivia isn't called "trivia" because it matters.
  - danielbarla 9y ago
    Well, aside from categorising such basic knowledge as "trivia", it's definitely not about taking one random, useless fact, and failing the interviewee on it. Rather, it's an example of a lowest common denominator question that everyone who has primary school education should laugh at, and move along. Hitting a hole at this level does imply some major issues with the person's general knowledge. It's fair to wonder what else will be missing in that person's repertoire, and how they will cope in random situations. Similarly, if a programmer fails the question "in the alphabet, which letter comes after A", I'd be worried, and rightfully so. I'd give them a chance to recover from that, just to make sure it wasn't a once-off, but it's not excusable.
sqeaky 9y ago
You say we need to figure a few basic things out, how do we do if a person has basic confidence if not by asking them questions. Please keep in mind that resumes nor any other data from the candidate can be trusted, because a huge amount of candidates lie or are mistaken about their own skill. I once interviewed a candidate who claimed to have 10 years of SQL experience but couldn't write a query on the order of "select * from table_name". Fully half of all people I have interviewed failed to convince me they could write anything more complex than "Hello World". I am not advocating hours and hours of needless hoops, but a candidate for just a about any programming job should be able to Write a working fizzbuzz implementation. Questions on the order of fizzbuzz can and do eliminate a huge number of possible candidates.
- Steeeve 9y ago
  > Please keep in mind that resumes nor any other data from the candidate can be trusted That's not a problem that is unique to software, yet nobody asks directors to prove their budget forecasting skills during an interview, or has their tech writers go through the process of building automated indexes or varied pagination. If you suspect someone can't write fizzbuzz, send them packing. Don't waste their time or yours. They've already instilled a lack of confidence which would mean that they would be facing adversity on day 1.
  - roguecoder 9y ago
    Tech writers are certainly asked to create technical documents to demonstrate their skills. Chefs might be a good model too; it absolutely the case that before hiring a chef they have to plan a menu and cook. We aren't business people: we do actual productive things.
    - Steeeve 9y ago
      > Tech writers are certainly asked to create technical documents to demonstrate their skills. In an interview? Not that I've ever seen. Reviewing a portfolio is not what we're talking about. > Chefs might be a good model too; it absolutely the case that before hiring a chef they have to plan a menu and cook. If a chef is expected to plan a menu and cook as part of their interview process, they are going after a very high end job. They know the kind of food that the restaurant serves. They are provided with the tools, equipment, and ample prep time to properly consider their course of action. And let's not pretend that every chef has to go through a live cooking trial for every job, or that most high end chef's would not throw a hissy-fit and walk out the door if you assumed that they would show up to an interview ready to plan a menu and cook a meal. --- "what? You've never heard of fizzbuzz? It's a simple game that..." cue a terrible explanation of the game missing key requirements that the interviewer expects the interviewee to just know. So now the developer not only has to come up with a set of code under pressure, they have to do so with a set of unclear requirements. And what the heck, why not take away their daily development environment to ensure that they are more uncomfortable and let's have them do it on a whiteboard so they have no hope of resolving simple syntax errors that arise because this particular developer floats between four different languages at his current job. What you see as a game to weed out a littany of liars and cheats is seen entirely differently from a job-seekers perspective. "I have 15 years experience building complex systems and this jackass wants me to write kiddie code on a whiteboard to prove what, exactly?" I'd rather not work for somebody who operated off of the assumption that I was a liar and a cheat upon our first meeting. The only reason people subject themselves to this kind of treatment is because they _need_ a paycheck.

danielbarla 9y ago

The question of relevance reminds me of an anecdote. (Before that though; I tend to agree with your points.) A distant acquaintance interviewed for a secretary position. It didn't go well, because she was asked a general knowledge question (something along the lines of: "name some of the planets in the solar system"). She was furious with how irrelevant and unfair this was. It makes me wonder though, would I have hired her? I probably wouldn't have asked that question, but still. When someone is missing some really basic knowledge - even if it's irrelevant - it's not a good sign, per se.

gwbas1c 9y ago
One of the things I like to do is ask a factual question about a technology listed on the candidate's resume that isn't required to know in order to hack something together, but is something that "you should know" if you've been working in a particular technology for a few years. These are part of the warm-up, I'll ask one or two right at the beginning of the interview and then move to the real questions. Examples are: "How does the autorelease pool work?" (Objective C before everyone switched to ARC.) or "How do you ensure that an object is garbage collected," (C# and Java.) These are more about judging a candidate's real knowledge versus stated knowledge. Someone who's spent 8 years in Objective C better know how to use the autorelease pool; and someone with at least a year of experience in a garbage collected language better know how to ensure that an object is collected.
- sobani 9y ago
  As someone who has worked in C# for about 8 years: you can't. You can call `GC.Collect()` and hope. But far as I know the GC will do a best effort and gives no guarantees. Of course that's besides that fact that I would need strong arguments to accept a `GC.Collect()` anywhere in the code. But to call it just to ensure an object is collected? Oh boy.. Depending on the case you could add some code to the `Dispose(bool)` method to know when your object is collected, but also in that case you risk flipping a Bozo bit.
roguecoder 9y ago
Why? Everyone has some things that are "common knowledge" that they don't know. Trivia isn't called "trivia" because it matters.
- danielbarla 9y ago
  Well, aside from categorising such basic knowledge as "trivia", it's definitely not about taking one random, useless fact, and failing the interviewee on it. Rather, it's an example of a lowest common denominator question that everyone who has primary school education should laugh at, and move along. Hitting a hole at this level does imply some major issues with the person's general knowledge. It's fair to wonder what else will be missing in that person's repertoire, and how they will cope in random situations. Similarly, if a programmer fails the question "in the alphabet, which letter comes after A", I'd be worried, and rightfully so. I'd give them a chance to recover from that, just to make sure it wasn't a once-off, but it's not excusable.

sqeaky 9y ago

You say we need to figure a few basic things out, how do we do if a person has basic confidence if not by asking them questions. Please keep in mind that resumes nor any other data from the candidate can be trusted, because a huge amount of candidates lie or are mistaken about their own skill. I once interviewed a candidate who claimed to have 10 years of SQL experience but couldn't write a query on the order of "select * from table_name". Fully half of all people I have interviewed failed to convince me they could write anything more complex than "Hello World". I am not advocating hours and hours of needless hoops, but a candidate for just a about any programming job should be able to Write a working fizzbuzz implementation. Questions on the order of fizzbuzz can and do eliminate a huge number of possible candidates.

Steeeve 9y ago
> Please keep in mind that resumes nor any other data from the candidate can be trusted That's not a problem that is unique to software, yet nobody asks directors to prove their budget forecasting skills during an interview, or has their tech writers go through the process of building automated indexes or varied pagination. If you suspect someone can't write fizzbuzz, send them packing. Don't waste their time or yours. They've already instilled a lack of confidence which would mean that they would be facing adversity on day 1.
- roguecoder 9y ago
  Tech writers are certainly asked to create technical documents to demonstrate their skills. Chefs might be a good model too; it absolutely the case that before hiring a chef they have to plan a menu and cook. We aren't business people: we do actual productive things.
  - Steeeve 9y ago
    > Tech writers are certainly asked to create technical documents to demonstrate their skills. In an interview? Not that I've ever seen. Reviewing a portfolio is not what we're talking about. > Chefs might be a good model too; it absolutely the case that before hiring a chef they have to plan a menu and cook. If a chef is expected to plan a menu and cook as part of their interview process, they are going after a very high end job. They know the kind of food that the restaurant serves. They are provided with the tools, equipment, and ample prep time to properly consider their course of action. And let's not pretend that every chef has to go through a live cooking trial for every job, or that most high end chef's would not throw a hissy-fit and walk out the door if you assumed that they would show up to an interview ready to plan a menu and cook a meal. --- "what? You've never heard of fizzbuzz? It's a simple game that..." cue a terrible explanation of the game missing key requirements that the interviewer expects the interviewee to just know. So now the developer not only has to come up with a set of code under pressure, they have to do so with a set of unclear requirements. And what the heck, why not take away their daily development environment to ensure that they are more uncomfortable and let's have them do it on a whiteboard so they have no hope of resolving simple syntax errors that arise because this particular developer floats between four different languages at his current job. What you see as a game to weed out a littany of liars and cheats is seen entirely differently from a job-seekers perspective. "I have 15 years experience building complex systems and this jackass wants me to write kiddie code on a whiteboard to prove what, exactly?" I'd rather not work for somebody who operated off of the assumption that I was a liar and a cheat upon our first meeting. The only reason people subject themselves to this kind of treatment is because they _need_ a paycheck.