5 ms·

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 int

by 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.

by geebee 12y ago

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.