Interviews Can Be a Terrible Way to Identify Good Programmers

It's better to think in terms of risks not just costs. Interviewers tend to higher people just like them, which means the team is often filled with people that think the same way and come up with the same types of solutions. On the other hand when you get someone in that can 'do the job' but has a radically different perspective they are more likely to bring something new to the table. To be overly simplistic in a team of world class programmers adding someone with a great UI background can be worth a lot more than yet another world class developer. The advantage being diversity does not require a larger paycheck.

It's a rite of passage I think. Programming interviews remind me of rushing for fraternities in college. And once you get to the on-site, the hazing begins...

They probably ask questions similar to the ones that they were asked... so over time they select people more and more similar to themselves and their culture becomes homogenous and inbred.

What would happen if you just refused to answer the question and asked them for something more practical that would actually demonstrate your skill & experience level?

I think that a lot of the frustration is coming from hackers who were rejected and find that they are left without any additional data to understand what that did or did not do that led to the rejection. Through recruiters you can sometimes hear a hint of why the rejection came, but if you work directly with a company they usually don't say anything except for "we liked you but ______"

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.