5 ms·

>This guy is looking to employ himself This is the key shortfall in interviews across all skills, not just tech. Most people tend to gravitate towards the fami

by Peroni 12y ago

>This guy is looking to employ himself This is the key shortfall in interviews across all skills, not just tech. Most people tend to gravitate towards the familiar and naturally nothing is more familiar than yourself. This also affects bias towards gender, race, etc.

mattxxx 12y ago
Agreed
jnbiche 12y ago
>This is the key shortfall in interviews across all skills, Sorry, but as someone who changed professions after 10 years in another profession (which was pretty universally viewed as a "brainy" type of work), I strongly disagree. My interviews (of which I had several over 10 years) were always done respectfully, and first and foremost were interested in teamwork skills, personality, and work habits. But when subject matter expertise was examined, my interviewers probed exclusively for knowledge we used in our everyday work. My former colleagues are uniformly appalled to hear what tech interviews are like. Likewise my wife, who works in yet another profession. Edit: Downvote away. I love working in software development, but until software developers face up to the fact that their interview process is actively discouraging more people from entering the profession, there will continue to be a "skill shortage" (a term that is also bandied about for political reasons, but that's another story). It's not management that conducts these kinds of interviews, it's fellow devs. Edit 2: And just to clarify, I'm not talking about knowing time/space complexity and common data structures and algorithms, all of which are important. I'm talking about asking puzzle problems like Tower of Hanoi and then marking people down for using an iterative instead of recursive solution.
- geebee 12y ago
  Very few of us will ever know what it's like to be hired as a mid-level programmer and lawyer, physician, or dentist. But my impression is that programming interviews are roughly analogous to quizzing a mid-career physician on end of chapter exercises from a second year college organic chemistry textbook. Of course, it could be that towers of hanoi is more relevant to the day to day practice of programming than ochem is to radiology. Or it could be that the process of becoming a physician is sufficiently regulated that you just don't need to worry about whether people have the required background, so physicians only have to pass their exit exams once, whereas programmers have to pass a randomly chosen subset of it every time they interview.
  - jnbiche 12y ago
    >my impression is that programming interviews are roughly analogous to quizzing a mid-career physician on end of chapter exercises from a second year college organic chemistry textbook. That is a strikingly accurate analogy. And regarding exams/licensing/certification, I'd gladly study to pass an extremely hard software engineering exam in order to not have to go through insipid interviews every 2-3 years.
    - geebee 12y ago
      I've read about the california state bar and how difficult and brutal it is to pass. It's a three day exam, and I'm sure it's tough. But I like to remind people of what I experienced last time I interviewed. It was for three different jobs, and interviews took about four and a half days. Topics covered were: Add a node to binary tree Print it recessively Print it iteratively Prove that the dual of the primal is the primal of the dual, using matrix notation. Find the long term state probabilities in a Markov chain. Write various sql statements (showing that you know outer joins, among other things) Denormalize a set of sql tables Swap two integers without creating a third variable Print all permutations of a string Formulate a linear program, then demonstrate that it can be done with a greedy algorithm that doesn't require an optimization formulation Write a good hashing function Answer questions about what actual data structures back the different container classes in Java Sort a bunch of things Show how to find the most common character in an n-length string with a minimum number of storage variables (i.e., no using a hash and picking it at the end, you have to keep a counter that swaps around) Design a database for a restaurant reservation system… That wasn't even all they asked. That's just what I remember. It was days of exhausting, 8-hour interviews. As programmers, we go through this over and over. I didn't get an offer, probably because I hadn't really done markov chains or data structures in a while and seemed fuzzy on my answers. I usually study a lot prior to an interview, but I was very busy around that time with programming work. Yeah, one reason I don't interview much anymore is that I feel I've loaded those topics into my short-term exam ready memory for the last time.
- anindyabd 12y ago
  It doesn't seem that the author actually asks candidates to code up the Tower of Hanoi in an interview. > I usually start with a fairly easy warm-up question — some sort of a toy problem like an operation on lists or trees, often the kind of thing that has a neat recursive solution. Binary tree problems and some linked list problems often have fairly obvious recursive solutions -- perhaps that's what he's referring to. I doubt anyone would consider the Tower of Hanoi problem "easy". It's definitely an interesting one to investigate in a blog post say, or for one's own enrichment -- it seems like that's what the author is doing. Of course there's no way of knowing the author's intentions unless he himself clarifies it, but this is what I think.

by Peroni 12y ago

mattxxx 12y ago

Agreed

jnbiche 12y ago

>This is the key shortfall in interviews across all skills, Sorry, but as someone who changed professions after 10 years in another profession (which was pretty universally viewed as a "brainy" type of work), I strongly disagree. My interviews (of which I had several over 10 years) were always done respectfully, and first and foremost were interested in teamwork skills, personality, and work habits. But when subject matter expertise was examined, my interviewers probed exclusively for knowledge we used in our everyday work. My former colleagues are uniformly appalled to hear what tech interviews are like. Likewise my wife, who works in yet another profession. Edit: Downvote away. I love working in software development, but until software developers face up to the fact that their interview process is actively discouraging more people from entering the profession, there will continue to be a "skill shortage" (a term that is also bandied about for political reasons, but that's another story). It's not management that conducts these kinds of interviews, it's fellow devs. Edit 2: And just to clarify, I'm not talking about knowing time/space complexity and common data structures and algorithms, all of which are important. I'm talking about asking puzzle problems like Tower of Hanoi and then marking people down for using an iterative instead of recursive solution.

geebee 12y ago
Very few of us will ever know what it's like to be hired as a mid-level programmer and lawyer, physician, or dentist. But my impression is that programming interviews are roughly analogous to quizzing a mid-career physician on end of chapter exercises from a second year college organic chemistry textbook. Of course, it could be that towers of hanoi is more relevant to the day to day practice of programming than ochem is to radiology. Or it could be that the process of becoming a physician is sufficiently regulated that you just don't need to worry about whether people have the required background, so physicians only have to pass their exit exams once, whereas programmers have to pass a randomly chosen subset of it every time they interview.
- jnbiche 12y ago
  >my impression is that programming interviews are roughly analogous to quizzing a mid-career physician on end of chapter exercises from a second year college organic chemistry textbook. That is a strikingly accurate analogy. And regarding exams/licensing/certification, I'd gladly study to pass an extremely hard software engineering exam in order to not have to go through insipid interviews every 2-3 years.
  - geebee 12y ago
    I've read about the california state bar and how difficult and brutal it is to pass. It's a three day exam, and I'm sure it's tough. But I like to remind people of what I experienced last time I interviewed. It was for three different jobs, and interviews took about four and a half days. Topics covered were: Add a node to binary tree Print it recessively Print it iteratively Prove that the dual of the primal is the primal of the dual, using matrix notation. Find the long term state probabilities in a Markov chain. Write various sql statements (showing that you know outer joins, among other things) Denormalize a set of sql tables Swap two integers without creating a third variable Print all permutations of a string Formulate a linear program, then demonstrate that it can be done with a greedy algorithm that doesn't require an optimization formulation Write a good hashing function Answer questions about what actual data structures back the different container classes in Java Sort a bunch of things Show how to find the most common character in an n-length string with a minimum number of storage variables (i.e., no using a hash and picking it at the end, you have to keep a counter that swaps around) Design a database for a restaurant reservation system… That wasn't even all they asked. That's just what I remember. It was days of exhausting, 8-hour interviews. As programmers, we go through this over and over. I didn't get an offer, probably because I hadn't really done markov chains or data structures in a while and seemed fuzzy on my answers. I usually study a lot prior to an interview, but I was very busy around that time with programming work. Yeah, one reason I don't interview much anymore is that I feel I've loaded those topics into my short-term exam ready memory for the last time.
anindyabd 12y ago
It doesn't seem that the author actually asks candidates to code up the Tower of Hanoi in an interview. > I usually start with a fairly easy warm-up question — some sort of a toy problem like an operation on lists or trees, often the kind of thing that has a neat recursive solution. Binary tree problems and some linked list problems often have fairly obvious recursive solutions -- perhaps that's what he's referring to. I doubt anyone would consider the Tower of Hanoi problem "easy". It's definitely an interesting one to investigate in a blog post say, or for one's own enrichment -- it seems like that's what the author is doing. Of course there's no way of knowing the author's intentions unless he himself clarifies it, but this is what I think.