Cfrtjryk

As a recruiter, I find it increasingly hard to recruit good software developers, due to the fact that it has become very easy to simply study for a job interview by reading any of those 14020 job interview questions for the software developer! books that are immensely popular these days.

It's gotten to the point where you pretty much can't ask a question without the applicant already having pre-studied at least a version of that same task and hence knows, roughly, what the solution is.

Now, this would of course not be a problem if knowledge of those problems is what we are looking for ... except, that isn't what we are looking for. Nobody cares if you know how to apply quicksort to some contrived, made-up example. The point isn't that you know how to solve those problems, the point is that you can figure it out. It's problem-solvers that we want, not problem-memorizers.

Because, once you actually get the job, you'll most likely never run into any of those problems from the job interview book again, so it's not your ability to memorize their solutions that matters, it's your ability to come up with a solution on the spot that is valuable. And yet, that is no longer testable, due to all these memorizers that read interview questions over and over.

How do we fix this issue? Because I am frankly tired of hiring promising software developers who answer each question perfectly in job interview questions, and then when you actually see them code in a real-world situation, you realize how little they actually know.

Provide the candidate with a genuine programming test in the interview - a laptop hooked up to a projector with a broken project, with a mixture of basic to complex bugs, and ask them to add some functionality, again ranging from basic to moderately complex. This is something nobody can really study for and will actually provide a showcase of their skills. Have technical people there talking to the candidate to get a feel for their personality and how they approach the problems faced.

For the job interview for my current role, I had spent 2 weeks studying programming principles, design patterns, database stuff etc. I was able to answer all the theoretical questions well and think I came across well

I was then handed a laptop which was connected up to the projector and shown a solution which contained a broken website with a defined number of errors which I had to debug and add some simple functionality. While I wasn't very familiar with the front-end framework used by the company, I was able to fix about half the bugs and then give my best guess as to what the causes were for the remaining bugs based on what I could see, and this was good enough to get me in the door.

The whole thing, between the theoretical questions and the website debugging session lasted about 2 hours.

Use Whiteboard interviews, and ask problems which are related to the skills and business domain that you're interested in. Look for people that you can work with, even if they aren't perfect matches for the position, because you can always train the right person if they have potential. Ask existing employees for recommendations (and offer a finders-fee)

Welcome new user, I've come to believe that the only way to hire software engineers is

• Just hire and pay them for a week or two on a project.

I think that's it.

It's the only way to know.

Everything else is useless.

The amount of time/money you'll spend on the sundry alternatives ... might as well just put them on the job for a week.

(Depending on your style and project, you might hire 'em for a time period (a week) or some "task" for $x. Either way.)

If you consistently take this approach, you'll likely find after a year or two that, the money you wasted doing this approach, was indeed far less than the sundry other costs of search and hiring.

After getting through enough basic questions to show that they have some minimal (by my needs) ability to write code, I move on to the tougher part of the interview, based on two subject areas, their work and my work.

Ask for information about a recent project at their current job. Even with respect to NDAs and IP restrictions, they should be able to explain the business problem, the complexity of the problems and how they overcame them. If they can't explain their own work to me so that I can understand and evaluate, then I worry about how successful they will be.

Ask them to white board a design/solution to one of your current problems. The expectation should not be a working solution but how they approach the problem. Provide enough information that they have a high level scope for the problem. They should ask good questions, and you should provide good answers so they can proceed. They should be able to sketch out some sort of solution. In the end their solution may not work out, but you will be able to see how they work on a problem and whether or not they should be able to work on the projects you will have.

• Have multiple interviewers. Your strongest engineers on the team should participate in the interview process - they definitely want to work with people better than the one's that are struggling, right?




• Ask an open ended design question. for a problem of medium complexity. Ask the candidate to write out the header file, class declarations, box diagrams, etc... Does the candidate ask clarifying questions? After he's done with a basic design, introduce a new requirement that would break his design. Is he able to pivot? Pick one part of his design and probe deeper.



• 
  

  Ask a question that probes if they have a deep understanding of the platform fundamentals. Some examples I've asked.

  
  
  
  
  
  • "How does the C++ compiler implement virtual methods?"
  
  
  • "How do closures work in Javascript?"
  
  
  • "Explain when you would ever want to use UDP instead of TCP."
  
  
  • "After you type a www.foo.com into a browser address bar, tell me about all the network activity and protocols involved to get the content on the screen."
  
  
  
  



• Probe for genuine interest in programming. "Tell me about a program you wrote for fun that wasn't for work or school." A good candidate will tell you about an app, website, or hack that he did for his own personal pleasure. A weaker candidate will only tell you about the program he wrote to figure something out for work/school.

In some ways, studying for the interview is a good thing. You probably already ask that people study about four years in a University to prepare for the interview.

Now, if your interviewing process is scripted, and the script lacks any kind of variation, then it is just a matter of time before the answers become memorized in the population. Solutions include:

1. As questions that are generated, with variable fields that require the work to be done specific to this asking of the question.


2. Change the question set from time to time, to minimize the time to build the pool of answers.


3. Change the entire approach, giving them a trivial project with specifically added bugs, asking them to fix it and add a known feature.

Also, consider the problem in the larger sense, if you are asking for information in an interview, and the information was memorized, then that should be an ideal candidate, unless you are asking for the wrong information.

You are deciding that the information isn't what is wanted, so you might be able to fix the problem by asking for the right kind of information.

Simply. You just grill the applicants on the implementation details and change requirements on them to see how they respond. Make them use what they've memorized as building blocks.

To be frank, problem memorizing isn't an issue. Memorization is actually one of the key techniques chess players use to learn the game. By memorizing algorithms your applicants are developing a library of solutions from which to work from. This means that they'll be able to solve problems better in the future, if the patterns and implementation of the patterns they're learning are actually useful.

What you need to test is that last part. By varying the problem in real time you get to see how well the applicant actually understands how to use what they've memorized. This means that you can ask them about better ways to solve the question and you can even ask them to compose their solution into a work flow to do something completely different.

What you want is someone who can solve problems. What you don't want is someone who solves problems the way you want to see them solved. If everyone's memorizing solutions, all you need to do is test their ability to use what they've memorized. When it comes down to it, everyone uses what they know to break down what they don't know. If your devs can use patterns they've already mastered to break down problems of increasing complexity, then they would have been able to reverse a linked list if they've never seen anyone do it before.

As a recruiter, this is as far as you can reasonably be expected to go without trying to get free labor out of your applicants.