4

In my professional work I started noticing that the more advanced developer you are the more meaningful comments you leave on a code review.

Recently when I was asked to interview several candidates I came up with a fairly simple code snippet (these were inexperienced candidates) in several languages (so they can choose) and 'hide' well known issues in the code. For example, in a Java snippet I would use == instead of .equals(), duplicate some code, use meaningless variable names, for OOP, come up with a strange class hierarchy, etc... I came up with a range of issues with different difficulties. Then we were to discuss what is wrong with a code and how to improve it.

I found that this question gave me insight into several things. First, it was a red flag if a developer could not point out obvious issues with the code. Second, even if a developer could not find all the issues, I could point it out and they can say 'ah yeah' and talk about it in a meaningful way. It also allowed me hear them dig as deep as they wanted on certain things.

I personally find it intimidating to write code during an interview. I also find it strange when potential employees give you a 'homework' to complete at home and hand in before the actual interview. But then how else are you supposed to evaluate their programming potential? So in my limited experience, showing the code snippet worked real well.

Is there any issues with this approach or is it acceptable? Is it possible that someone does well with this task but would not be able to write quality code?

closed as primarily opinion-based by user40980, Eric King, Steven A. Lowe, durron597, gnat Aug 12 '15 at 5:51

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • To keep an opinion-based question open, please make the long-term commitment to "facilitate a good-subjective debate" on this topic, and to bring in new insights and reference materials for keeping it lively. Part of that responsibility is to "promote" this question in other circles, e.g. among your peers, your social network, your public profiles, etc., and to give promptly feedbacks on each answer, in order to steer answerers toward the relevant core issues in this question. – rwong Aug 12 '15 at 3:39
  • wonder if you have seen what interview tag says, "DO NOT USE..." – gnat Aug 12 '15 at 5:51
  • @gnat No I did not see... If I did I would have not used it... – c_maker Aug 12 '15 at 8:27
3

Having been through the job search process for several months, I can give you my perspective on the job search process as it relates to me. First, some don'ts; these are all things that many employers are doing right now, and they shouldn't be doing them:

Don't ask people elaborate questions about things that they will never use on the job.

I'm not talking about FizzBuzz. FizzBuzz exists to weed out people who can't program at all. I'm talking about asking people to design and implement a binary tree, when that problem has already been solved decades ago. Instead, ask about complexity (Big O), and perhaps how to use recursion to walk a binary tree.

Don't ask people to write perfect code.

You're not going to get that in a coding interview, especially if it's via skype or over the phone. Most people use IDE's nowadays, and you've robbed them of that tool. If part of your job skill set requires people to code in Notepad, then by all means. I doubt that's true, though.

Don't ask people to travel clear across the country for a six month commitment.

This is just a variation on "the interview that never ends." Figure out how to find talented people to interview in the first or second contact to interview, and then make the interview relevant to your job.

Stop following the herd!
Some of the things that you are doing in your interviews you are doing because Google does them, or Facebook does them. Your best hiring process is not necessarily coding contests between whiskey shots (if the lore is true). Your best hiring process is the one that best fits your company, not the latest Google or Facebook fashion.

Finally, don't ask people about things you don't already know yourself.

If you're asking someone to improve performance on a string reversal algorithm when they've already written it in the most optimum way, you're just wasting everyone's time.

Now that that's out of the way....

For example, in a Java snippet I would use == instead of .equals(), duplicate some code...

This seems like a sensible approach.

I would expect every experienced developer to already know certain things about their language of choice. I would expect a reasonably competent C# programmer to know how == differs from equals(), why strings are an exception, what IDisposable is and how it relates to using, etc. I would personally favor crack skills in their language of choice over your preferred kitchen sink of desired technology flavors of the week, since someone with excellent coding skills can easily pick those up.

I found that this question gave me insight into several things. First, it was a red flag if a developer could not point out obvious issues with the code. Second, even if a developer could not find all the issues, I could point it out and they can say 'ah yeah' and talk about it in a meaningful way. It also allowed me hear them dig as deep as they wanted on certain things.

All true.

I personally find it intimidating to write code during an interview. I also find it strange when potential employees give you a 'homework' to complete at home and hand in before the actual interview. But then how else are you supposed to evaluate their programming potential?

By the time you grant someone an interview, you should already have a fair idea whether or not you're going to hire them. When I interviewed for the job I have now, I wasn't even asked any technical questions. The person who interviewed me spent most of his time selling me on his company. He said "I already know you can do the job, subject to your references confirming that you've done the things you say you've done in your resume."

0

I think to some extent, this should be a valid evaluation of their programming skills. If someone doesn't point out the use of == instead of .equals in their review of Java, or does but can't explain the difference/why you would want .equals, they probably do not have the level of understanding of the Java language to write good code.

Additionally, in a way this task is very akin to what a developer usually winds up doing when working with legacy code. Duplicated code and weird inheritance structures are opportunities to refactor, and a good developer WILL notice them and WILL come up with a good refactor or a better design. If a developer can do that, there's no reason they shouldn't be able to write good code.

Not the answer you're looking for? Browse other questions tagged or ask your own question.