-1

New take on asking the question, to keep it more specific

I want to avoid adding too much stress on the interviewee when interviewing software developers. I want to be able to assess both technical skills and interpersonal skills, in a setting where the interviewee feels comfortable and is able to perform at his/her best. What are your suggestions?

My original post suggested an approach where the interviewee was asked to discuss why one solution to a problem was better than an other, based on the assumption that you, as a developer, many times find your self looking at how other people have solved a particular problem before you.

closed as too broad by gnat, IDrinkandIKnowThings, OldPadawan, dwizum, Rory Alsop Mar 27 at 15:23

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • I'm not sure if you understood this correctly. It wouldn't be "pick A or B", rather "explain why you picked A over B, or why you want to pick parts from both". – Erik Kinding Mar 27 at 10:26
  • I think what I suggest above is sort of what you're talking about, open ended, but in a realistic setting for a developer as it's very common to solve problems based on how other people already solved them. Have you ever been given a time framed coding test with no tools but a whiteboard or pen or paper? – Erik Kinding Mar 27 at 10:34
  • I didn't feel comfortable, no, but I've never had a problem passing a test like that. I've also never met a person who likes that type of test, yet a lot of companies use them. – Erik Kinding Mar 27 at 10:37
  • 3
    Just get the candidate to do what they'd do on the job: write code. Use an IDE not a whiteboard, provide access to Google and StackOverflow, no problem. Don't get them to do pointlessly compare two approaches which they'd never need to do in a real job, and measures only their ability to bullshit. – BittermanAndy Mar 27 at 10:41
  • 2
    This question could benefit greatly from being distilled down into a single answerable question rather then 3 different ones. As such, it's currently at risk to being closed as too broad. A general question about alternatives to whiteboard coding tests would probably work and fit the 2 starts of an answer Andy and Joe already gave – Magisch Mar 27 at 12:32
1

Maybe you're using the word "threatening" in a colloquial sense, but an interview should never feel threatening to the person being interviewed. Additionally, you should never "demand" anything from the person being interviewed.

That being said, I like your idea of using collaborative interview questions that let the interviewer and interviewee discuss a problem and work it out together. This will give you not only an idea of their technical skills but of their interpersonal skills, which are just as important in establishing a healthy working relationship and environment.

  • Yes, perhaps the word threatening is a bit strong in this context, and also misleading. What I want to avoid is putting the interviewee in a position causing too much stress. Yea, I find the part about interpersonal skills very important too. Ideally the session would be sort of role playing a day at work. Maybe the format should be changed in that direction, to be more like a code review or something like that, just like @Quaestor Lucem suggests. – Erik Kinding Mar 27 at 14:59
  • 1
    Right. I'm of the opinion that the person being interviewed should be made to feel at ease. Nervousness is always a factor and you don't want to add to that by making them feel unduly stressed. I think interviews should be like conversations. – joeqwerty Mar 27 at 15:03
1

When interviewing, I usually ask the candidate's to choose one project in which they have worked on and to present it to me in a whiteboard.

From there, I ask why it was designed in that way, what would be the alternatives considered (if any at all), ask about test and delivery strategy, ask about implementation details and propose different scenarios exploring fault tolerance, scalability, high availability and other -ilities.

One option I am planning to try is to perform a code review together. Write some code or get some open source code, explain enough about the purpose of the application and ask the candidate to share their impressions about it. Of course, try to choose a piece of code that has potential for refactoring, both in code and overall design of the application.

From the type of comments they do, you can get a glimpse of their experience in the field:

  • are they only worried about formatting of code?
  • do they care about readability of the code?
  • are they looking for best practices?
  • are they asking questions about the overall design of the application?
  • are they worried with maintainability?
  • can they offer better options of implementation?
  • is the code well tested? could they offer new testing strategies?
  • are they flexible while discussing points of view? or are they dogmatic?

after the code review: can they actually implement some of the changes they proposed, or at least show in an IDE how they would do it?

  • 1
    Thank you, very constructive feedback! The code review idea is super I think! – Erik Kinding Mar 27 at 15:00
1

I think this question is coming at the problem from the wrong angle. The problem isn't "should we be doing coding problems?", but rather "what should we be looking for when doing coding problems?" It sounds to me like you may be looking for the wrong things.

Things not to do include:

  • Ensure proper code formatting during the interview (tabs, newlines, etc). IDEs do this for you.
  • Ensure all method names are correct as per standard libraries. IDEs have autocomplete for this.
  • Not allow the interviewee to go back and revise their code. Whiteboard do not easily have random-access rewrite, IDEs do. Warning: This makes whiteboard coding messy, and if you want to do whiteboard coding, expect a mess.
  • Remain silent during the entire process. The interviewee may want to bounce ideas off you. Plus, being silent causes stress; it makes the interview more like a "test" than an "interview".

Things to do include:

  • Look for basic knowledge. Do they know the basic functionalities of the standard libraries? Do they understand things like LinkedList vs ArrayList vs Map vs Set?
  • Do they understand computational complexity and how it applies to real problems?
  • If you are looking for proficiency with a specific library, do they know how to use that library? (e.g. Java 8 streaming, NodeJS promises)
  • Prompt them to pull up information you are interested in them knowing. For example, if they are using an array where they should be using a LinkedList, prompt them:

Do you know another data structure which can alleviate the problem that this function will do many inserts to your array?

It's possible that in an interview setting they got flustered; an inability to pull up one's entire breadth of knowledge of computer science on demand at a moment's notice isn't necessarily a disqualifying factor (it can be, but not necessarily).

As for your question directly: It depends on what you want to test. It is true that there exists a wide breadth of code on SO that can solve most problems. But do you want to hire someone who doesn't know how to code except to copy-paste from SO? That's probably not what you want. It's important to know that this person is able to read and critically dissect code on SO if they choose to copy it, but it's also important to know that this person knows how to write code independently.

  • Hey, thanks! This is very good input. I like the part about NOT being silent, hadn't really thought about the implications of that. Thanks a again for valuable input! – Erik Kinding Mar 27 at 15:26

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