To fix coding interviews in this country, you need to insist on having a great coder do the interviewing. In 90% of the interviews I go on, I get evaluated by an HR type who could not write any program more significant than Hello World.
What's funny is that the Non programmer interviewers are starting to administer coding tests, and they don't know what a good response is! So here I am doing a coding tests on a white board, and and I'm being tested on delivering the optimized code on the spot, basically producing the best code. So now instead of birdseed knowledge tests, we are tested for creating an algorithm from memory on the spot, a memorization game. Like Jeopardy. That's not how the best coders code, we offload most things to google searches and general process of cutting code. They don't realize this because they evaluators can't write a program. They can only understand one specific algorithm and its implementation.
So the only way to get a good coder is to take your best coder, and then hand him a stack of resumes, and ask him which ones to bring in, and have him sit down with the recruits and have him give an up or down vote.
Using non coders to filter coder resumes? The time is better spent hiring a monkey to throw darts and hire the one with the most darts. I don't care how many books on coding interviews they read.
I totally agree with you that anyone interviewing for a technical position should be technical -- if they ask you a technical question, the only answer cannot be "the answer I found in this book or learned from someone else". That's a disaster waiting to happen.
However... I've known a few great coders who were absolutely terrible interviewers. So just being great technically also isn't a sure sign that the interview will be handled well.
I think it's fair to say that if you're stretching yourself, or working on challenging problems, a reasonable amount of time is spent researching. If you don't know how to do something, you research it. Whether you find it in a textbook or on Stack Overflow, it's essentially the same thing.
Unless you think "good" coders reinvent algorithms they don't know from first principles?
I'd wager there's a difference between what jemfinch is talking about and what you're talking about.
I used to unilaterally believe that coding exercises or algorithm quizzes on interviews were silly because if I had to solve some given problem I would just google it. And that's true, I would. However, as I've gotten a little more experienced I've realized that there is extreme value in expanding the domain of problems for which I don't need to google, because either A). I've happened to read about it on my own time or B). I've encountered a particular troublesome component before.
In other words, I think it is entirely reasonable for the hiring process to properly evaluate a programmer's toolset. Yes, I think researching via Google is or should be a piece of everyone's process, but it matters greatly what kind of things you have to Google.
Do programmers encounter all sorts of algorithms when engineering software? In my experience, the only things I really need to keep in mind what are the consequences of certain data structures and algorithm types rather than their specific implementation, because often the implementations are built-in to the language, but the choice of which implementation of data structure and algorithm to use are more important. I use sorting algorithms very frequently. Usually it is just a call like "list.sort()".
Yet in interviews, the questions I get asked are more like "Implement <My favourite sort> in 20 minutes, no googling.
I mean, really?
The other day I was in an interview where I had to implement a queue in 30 minutes. The unit tests were already written and the IDE was eclipse.
I wrote the "correct" implementation for the queue in about 10 minutes but there was a bug I couldn't find; I've never used eclipse before and took a lot of time figuring out everything. In the last minute I finally tracked down my bug. I forgot to increment a variable. I fixed it and all the tests as well as the performance test passed. I didn't get the job because I took too long. (It was a graduate position and the last time I used Java was 2 years ago)
I was distracted with all the buttons on eclipse... Otherwise I'd never have missed the variable increment! I swear. Anyway the point is, if a programmer is ever implementing their own simple Java queue in production software it is not a good sign anyway. Why are you testing for that?
Good designers buy stock photos for generic things and fill in with custom bits to produce a finished piece.
Good programmers copy/pase boilerplate code and focus on the stuff that really makes it different. (iOS example) you don't write out all of the methods for a UITableView.. That would be a waste of time you copy/paste the methods you need and change the important bits.
I interpreted his statement as meaning that google searches replace the requirement to memorize minute details of things that aren't commonly used or necessary to commit to memory. For example, I may know about php's preg_match, but I haven't used it in 2 years... so if a project calls for it I can just do a quick search for preg_match and see all the details that I need to know. I didn't have to have everything in memory since I wasn't using it. We have a built-in garbage collector in our minds that slowly clears out things that we don't use. But when we do learn it for a second time it comes back very quickly.
Good coders are clever problem solvers and well-organized thinkers. They don't need to have photographic memories that store every possible command and instruction, even ones that they have never ever used and find no use for. As long as you know what is relevant for the current task and have a peripheral awareness of what else exists, you can do your current tasks and know what to search for in books or on google if something out of the ordinary is required.
I think that the tests are very important, but it's hard to do them efficiently and to create good tests that test skills that are important to the job at hand.
The tests should have well-defined constraints and instructions, and once the tests are complete the code should be the basis for a discussion about why certain choices were made.
I've basically received the same type of coding test from 10 different companies for the Sr. DevOps roles that I'm looking at... and it's really sad honestly to see what they're asking me to do. It's basically high-school CS where I'm supposed to open one file and pull out specific parts of that file and then compare it with a second file and output only certain lines from the second file based on a comparison with the lines from the first file.
The instructions are poor, and I'm expected to clarify each time with these kinds of questions: "Ok do I need to worry about memory?" "Does this need to work for files of arbitrary sizes?" "Does this need to handle error checking?" "Is it important that the code is readable & documented?" "How long do I have to complete this test?" etc...
But in DevOps, I am given a specific situation that I know a lot about... and based on the situation I am used to answering these questions myself. I should be given a specific and relevant situation... and then create a solution to solve it based on my experience and knowledge of what the constraints are when dealing with that kind of situation...
If I'm given a situation that compares the /etc/passwd file with the /etc/group file, I'm not assuming that it's reasonable/possible in even a system set up by the most bumbling sysadmin that those files would be millions of lines long each... And if they're blank or corrupt we definitely have other issues... If this script needs to run unattended for a long period of time it should have error checking and logging. But if it's just run once I wouldn't need to do everything in software as long as I:
1) make backups of the files
2) 'less' into the files and take a quick look to make sure that there aren't any surprises.
3) Run a test on copies of the files...
Wayyy back in CS 101 did it ever really matter if a one-time piece of code executes in 0.0000000001 seconds versus 0.000000000099999 ? If that is important to you, then please give me a real-world example that requires optimization. Or just specify that the solution needs to be as fast as possible. My recollection was that highly optimized code often needed to be rewritten when future assignments built on the code written in the earlier assignments.
Also fyi for interviewers... if I'm using a scripting language there might be some behind the optimizations that alters the typical CS understanding of the performance characteristics of sets, hash maps/hash tables, and arrays. (See php and python for example) It seems that any question that CAN use a hash map probably should use one in a programming interview... Scripting languages can also handle errors in a pretty amazing way that interviewers may not be familiar with. For example, splitting a string a="a:b:c::::::::::" in python by using b=a.split(':') works just fine and results in b=['a', 'b', 'c', '', '', '', '', '', '', '', ''].
Which brings up a final point... in the real-world, writing a first version of your code in a more generic and unoptimized way leads to code that you can more easily adapt in the future when you rewrite or refactor due to changing requirements. And less optimized code is generally more readable and for other coders who may actually need to read your code and make future changes it can be easier to spot problems or make changes many months or years after you finish your version. But in a coding interview, always assume that they want the most optimized version of the code... but make sure to ask anyhow just in case. Some people may actually care to see if you can code in a way that balances between speed and maintainability.
Testing is important, but it is extremely important to design tests in a way that helps reveal the characteristics that are important to the job you are hiring for. And if something is a google search away and not something that is necessary for the job, it's not something that an experienced coder will keep in their valuable brain-based memory storage.
Comments
To fix coding interviews in this country, you need to insist on having a great coder do the interviewing. In 90% of the interviews I go on, I get evaluated by an HR type who could not write any program more significant than Hello World.
What's funny is that the Non programmer interviewers are starting to administer coding tests, and they don't know what a good response is! So here I am doing a coding tests on a white board, and and I'm being tested on delivering the optimized code on the spot, basically producing the best code. So now instead of birdseed knowledge tests, we are tested for creating an algorithm from memory on the spot, a memorization game. Like Jeopardy. That's not how the best coders code, we offload most things to google searches and general process of cutting code. They don't realize this because they evaluators can't write a program. They can only understand one specific algorithm and its implementation.
So the only way to get a good coder is to take your best coder, and then hand him a stack of resumes, and ask him which ones to bring in, and have him sit down with the recruits and have him give an up or down vote.
Using non coders to filter coder resumes? The time is better spent hiring a monkey to throw darts and hire the one with the most darts. I don't care how many books on coding interviews they read.
I totally agree with you that anyone interviewing for a technical position should be technical -- if they ask you a technical question, the only answer cannot be "the answer I found in this book or learned from someone else". That's a disaster waiting to happen.
However... I've known a few great coders who were absolutely terrible interviewers. So just being great technically also isn't a sure sign that the interview will be handled well.
"That's not how the best coders code, we offload most things to google searches"
If that's really what you think, you may want to reconsider who the "we" you're talking about are.
I think it's fair to say that if you're stretching yourself, or working on challenging problems, a reasonable amount of time is spent researching. If you don't know how to do something, you research it. Whether you find it in a textbook or on Stack Overflow, it's essentially the same thing.
Unless you think "good" coders reinvent algorithms they don't know from first principles?
I'd wager there's a difference between what jemfinch is talking about and what you're talking about.
I used to unilaterally believe that coding exercises or algorithm quizzes on interviews were silly because if I had to solve some given problem I would just google it. And that's true, I would. However, as I've gotten a little more experienced I've realized that there is extreme value in expanding the domain of problems for which I don't need to google, because either A). I've happened to read about it on my own time or B). I've encountered a particular troublesome component before.
In other words, I think it is entirely reasonable for the hiring process to properly evaluate a programmer's toolset. Yes, I think researching via Google is or should be a piece of everyone's process, but it matters greatly what kind of things you have to Google.
Do programmers encounter all sorts of algorithms when engineering software? In my experience, the only things I really need to keep in mind what are the consequences of certain data structures and algorithm types rather than their specific implementation, because often the implementations are built-in to the language, but the choice of which implementation of data structure and algorithm to use are more important. I use sorting algorithms very frequently. Usually it is just a call like "list.sort()".
Yet in interviews, the questions I get asked are more like "Implement <My favourite sort> in 20 minutes, no googling.
I mean, really?
The other day I was in an interview where I had to implement a queue in 30 minutes. The unit tests were already written and the IDE was eclipse.
I wrote the "correct" implementation for the queue in about 10 minutes but there was a bug I couldn't find; I've never used eclipse before and took a lot of time figuring out everything. In the last minute I finally tracked down my bug. I forgot to increment a variable. I fixed it and all the tests as well as the performance test passed. I didn't get the job because I took too long. (It was a graduate position and the last time I used Java was 2 years ago)
I was distracted with all the buttons on eclipse... Otherwise I'd never have missed the variable increment! I swear. Anyway the point is, if a programmer is ever implementing their own simple Java queue in production software it is not a good sign anyway. Why are you testing for that?
Good designers buy stock photos for generic things and fill in with custom bits to produce a finished piece.
Good programmers copy/pase boilerplate code and focus on the stuff that really makes it different. (iOS example) you don't write out all of the methods for a UITableView.. That would be a waste of time you copy/paste the methods you need and change the important bits.
I interpreted his statement as meaning that google searches replace the requirement to memorize minute details of things that aren't commonly used or necessary to commit to memory. For example, I may know about php's preg_match, but I haven't used it in 2 years... so if a project calls for it I can just do a quick search for preg_match and see all the details that I need to know. I didn't have to have everything in memory since I wasn't using it. We have a built-in garbage collector in our minds that slowly clears out things that we don't use. But when we do learn it for a second time it comes back very quickly.
Good coders are clever problem solvers and well-organized thinkers. They don't need to have photographic memories that store every possible command and instruction, even ones that they have never ever used and find no use for. As long as you know what is relevant for the current task and have a peripheral awareness of what else exists, you can do your current tasks and know what to search for in books or on google if something out of the ordinary is required.
Some good insights hm.
I think that the tests are very important, but it's hard to do them efficiently and to create good tests that test skills that are important to the job at hand.
The tests should have well-defined constraints and instructions, and once the tests are complete the code should be the basis for a discussion about why certain choices were made.
I've basically received the same type of coding test from 10 different companies for the Sr. DevOps roles that I'm looking at... and it's really sad honestly to see what they're asking me to do. It's basically high-school CS where I'm supposed to open one file and pull out specific parts of that file and then compare it with a second file and output only certain lines from the second file based on a comparison with the lines from the first file.
The instructions are poor, and I'm expected to clarify each time with these kinds of questions: "Ok do I need to worry about memory?" "Does this need to work for files of arbitrary sizes?" "Does this need to handle error checking?" "Is it important that the code is readable & documented?" "How long do I have to complete this test?" etc...
But in DevOps, I am given a specific situation that I know a lot about... and based on the situation I am used to answering these questions myself. I should be given a specific and relevant situation... and then create a solution to solve it based on my experience and knowledge of what the constraints are when dealing with that kind of situation...
If I'm given a situation that compares the /etc/passwd file with the /etc/group file, I'm not assuming that it's reasonable/possible in even a system set up by the most bumbling sysadmin that those files would be millions of lines long each... And if they're blank or corrupt we definitely have other issues... If this script needs to run unattended for a long period of time it should have error checking and logging. But if it's just run once I wouldn't need to do everything in software as long as I: 1) make backups of the files 2) 'less' into the files and take a quick look to make sure that there aren't any surprises. 3) Run a test on copies of the files...
Wayyy back in CS 101 did it ever really matter if a one-time piece of code executes in 0.0000000001 seconds versus 0.000000000099999 ? If that is important to you, then please give me a real-world example that requires optimization. Or just specify that the solution needs to be as fast as possible. My recollection was that highly optimized code often needed to be rewritten when future assignments built on the code written in the earlier assignments.
Also fyi for interviewers... if I'm using a scripting language there might be some behind the optimizations that alters the typical CS understanding of the performance characteristics of sets, hash maps/hash tables, and arrays. (See php and python for example) It seems that any question that CAN use a hash map probably should use one in a programming interview... Scripting languages can also handle errors in a pretty amazing way that interviewers may not be familiar with. For example, splitting a string a="a:b:c::::::::::" in python by using b=a.split(':') works just fine and results in b=['a', 'b', 'c', '', '', '', '', '', '', '', ''].
Which brings up a final point... in the real-world, writing a first version of your code in a more generic and unoptimized way leads to code that you can more easily adapt in the future when you rewrite or refactor due to changing requirements. And less optimized code is generally more readable and for other coders who may actually need to read your code and make future changes it can be easier to spot problems or make changes many months or years after you finish your version. But in a coding interview, always assume that they want the most optimized version of the code... but make sure to ask anyhow just in case. Some people may actually care to see if you can code in a way that balances between speed and maintainability.
Testing is important, but it is extremely important to design tests in a way that helps reveal the characteristics that are important to the job you are hiring for. And if something is a google search away and not something that is necessary for the job, it's not something that an experienced coder will keep in their valuable brain-based memory storage.