I prefer people that can voice their thoughts. This is an essential part of being a programmer, it's not limited to an interview situation. I need to know that you can communicate with the rest of the team. I need to know that when you're having problems, you'll be able to voice them and get the assistance you need.
This is definitely a hurdle for some individuals, but getting over it will make one much more successful in interviews, and on the job. Don't worry that it's "chatting" though. I don't want smalltalk, I want your thoughts, however terse they may be. Trust yourself, and understand issues are normal. There's no reason to be afraid of voicing what's in your head.
I hope you are not saying "voicing thoughts" is the same as "communicating thoughts". The former is just blurting everything you are thinking. This can be hard for folks who can think very quickly but cannot express them quickly with words, e.g., non-native English speakers, visual thinkers (remember they have to explain the pics they draw). The latter is more controlled as it is about distilling and arranging a thought in a way that another person can understand.
IMO a better approach would be to let the candidates to solve the problem while applying their technical skills as they would do naturally. If the candidate solves the problem, then ask away about the solution and how he/she arrived at the solution. [Or do we think asking well-framed questions is hard? ;)] This approach provides a more accurate picture of how the candidates operates.
That said, if you will consider the candidate's operational style in the hiring decision, then you should be up front about it. Even so, if you are looking for candidates with specific operational style, I'd say you are narrowing your picks and losing out on diversity.
That is roughly what we are doing at JankariTech.
The candidate has to work on a programming exercise (btw. we don't care about syntax, the IDE will help you to place the brackets at the right place, nor do we expect the candidate to have a complete solution at the end of the time)
After the programming the candidate comes to the interviewer and explains what she/he had done, what other ideas she had and what would have been the next steps.
We hope that gives a good chance to people who can talk easy, but also to those who first have to think in isolation.
I personally develop ideas while talking, so I find it very easy to 'discuss' with my self, but I know a lot if people who are different. I feel a lot of Western cultures give an unfair advantage to rather chatty people.
I am fine with folks developing ideas while talking but I doubt what one talks about while thinking would make sense or seem coherent to many others. Trying to make sure that the talking is sensible+coherent takes away the focus from the task of thinking.
Coding with a stranger over your shoulder who is judging you is a lot different and more intimidating than talking to a team member in the same foxhole as you. I'm watching one of these interviews, and I already feel stressed and my neurons are misfiring trying to come up with a solution. Whereas in a team environment I feel quite comfortable communicating and designing solutions in a group.
I won't disagree, there's added stress in the interview. But the purpose of an interview is to assess your skills. What other ways would I have of judging the person's communication abilities?
I have different goals on interviews. My situation biases me -- we tend to hire devs with no experience. Coding interviews are not very useful in that case. And we need to help develop their skills anyway. I believe every person has a unique combination of inherent strengths and weaknesses and that most skills are learnable to a passable level. Including technical and soft skills.
Instead of looking for skill expertise, I look for a person who is teachable (implying intellect as well as outlook). If I was hiring for an experienced dev position, I would probably look for a person who is still teachable. This kind of person tends to be a supportive team member. The people I don't want to work with (regardless of experience level or the skills they possess) are the ones who already have everything figured out. They tend to look pretty good on traditional interviews because their confidence level makes them convincing.
As far as coding tests, I have given small take-home coding challenges, but these did not play a major factor in hiring decisions. As in, we hired devs who could not yet complete them. They were more to answer the question "how close to zero are they starting?"
Even with a more experienced position an individual coding interview seems like it would have limited value for us. It could be I want to assess their problem solving ability. But we tend to solve the hard problems as a group. The stress and arbitrary-ness of individual code interviews can play a large factor in creating poor on-the-fly solutions. (Code interviews often have you solve contrived puzzles. But my instinct in a real work environment is to view contrived problems with suspicion and to try to find the Why rather than rattling off solutions.) So such an interview doesn't really indicate how they will do in position we have for them. (Another factor: it turns out our tech stack is pretty amenable to being maintained, so it takes the pressure off of making mistakes and learning from them while still delivering value.) Also, we can't really use the code interview to test for tech stack knowledge, because probably very few people use our stack. We would have to assume even experienced devs would need a couple of weeks to spin up.
For the rest of it -- verifying resume claims and evaluating various criteria -- it can be done through conversation. And it still boils down to a judgement call.
Fair disclosure of known biases: Our software department is small, so sample size is limited. I'm also saying the above as the person that chose and has been iterating on our tech.
This is absolutely not an essential part of being a programmer. There's an enormous difference between explaining something you've had time to think about on your own with your co-workers and talking out loud while you're trying to solve a difficult problem with someone staring at you and judging you.
This fails to assess every single thing you're supposedly assessing. It's not a good indicator of problem solving ability, technical skills, or communication. It's a good indicator of whether or not that person doesn't have performance anxiety issues and/or has seen that same problem before and already given it thought.
I can not wait until more companies realize how ridiculous and biased this form of interviewing is.
I totally agree with you. What do you think would be a good approach to an interview, if you had the opportunity to lay it out?
Usually when we are interviewing, I try to keep the candidate as relaxed as possible: voicing that explicitly, at the maximum two people at a given interview (with some exceptions). Doing that is easy enough, but how to actually make the candidate comfortable?
One good way (IMO) is to give enough time for problem solving through a tool like Hacker Rank or similar, and then after you have that out of the way, a friendly conversation about systems design/cultural fit/etc in person.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I prefer people that can voice their thoughts. This is an essential part of being a programmer, it's not limited to an interview situation. I need to know that you can communicate with the rest of the team. I need to know that when you're having problems, you'll be able to voice them and get the assistance you need.
This is definitely a hurdle for some individuals, but getting over it will make one much more successful in interviews, and on the job. Don't worry that it's "chatting" though. I don't want smalltalk, I want your thoughts, however terse they may be. Trust yourself, and understand issues are normal. There's no reason to be afraid of voicing what's in your head.
I hope you are not saying "voicing thoughts" is the same as "communicating thoughts". The former is just blurting everything you are thinking. This can be hard for folks who can think very quickly but cannot express them quickly with words, e.g., non-native English speakers, visual thinkers (remember they have to explain the pics they draw). The latter is more controlled as it is about distilling and arranging a thought in a way that another person can understand.
IMO a better approach would be to let the candidates to solve the problem while applying their technical skills as they would do naturally. If the candidate solves the problem, then ask away about the solution and how he/she arrived at the solution. [Or do we think asking well-framed questions is hard? ;)] This approach provides a more accurate picture of how the candidates operates.
That said, if you will consider the candidate's operational style in the hiring decision, then you should be up front about it. Even so, if you are looking for candidates with specific operational style, I'd say you are narrowing your picks and losing out on diversity.
That is roughly what we are doing at JankariTech.
The candidate has to work on a programming exercise (btw. we don't care about syntax, the IDE will help you to place the brackets at the right place, nor do we expect the candidate to have a complete solution at the end of the time)
After the programming the candidate comes to the interviewer and explains what she/he had done, what other ideas she had and what would have been the next steps.
We hope that gives a good chance to people who can talk easy, but also to those who first have to think in isolation.
I personally develop ideas while talking, so I find it very easy to 'discuss' with my self, but I know a lot if people who are different. I feel a lot of Western cultures give an unfair advantage to rather chatty people.
Nice practice.
I am fine with folks developing ideas while talking but I doubt what one talks about while thinking would make sense or seem coherent to many others. Trying to make sure that the talking is sensible+coherent takes away the focus from the task of thinking.
Coding with a stranger over your shoulder who is judging you is a lot different and more intimidating than talking to a team member in the same foxhole as you. I'm watching one of these interviews, and I already feel stressed and my neurons are misfiring trying to come up with a solution. Whereas in a team environment I feel quite comfortable communicating and designing solutions in a group.
I won't disagree, there's added stress in the interview. But the purpose of an interview is to assess your skills. What other ways would I have of judging the person's communication abilities?
I have different goals on interviews. My situation biases me -- we tend to hire devs with no experience. Coding interviews are not very useful in that case. And we need to help develop their skills anyway. I believe every person has a unique combination of inherent strengths and weaknesses and that most skills are learnable to a passable level. Including technical and soft skills.
Instead of looking for skill expertise, I look for a person who is teachable (implying intellect as well as outlook). If I was hiring for an experienced dev position, I would probably look for a person who is still teachable. This kind of person tends to be a supportive team member. The people I don't want to work with (regardless of experience level or the skills they possess) are the ones who already have everything figured out. They tend to look pretty good on traditional interviews because their confidence level makes them convincing.
As far as coding tests, I have given small take-home coding challenges, but these did not play a major factor in hiring decisions. As in, we hired devs who could not yet complete them. They were more to answer the question "how close to zero are they starting?"
Even with a more experienced position an individual coding interview seems like it would have limited value for us. It could be I want to assess their problem solving ability. But we tend to solve the hard problems as a group. The stress and arbitrary-ness of individual code interviews can play a large factor in creating poor on-the-fly solutions. (Code interviews often have you solve contrived puzzles. But my instinct in a real work environment is to view contrived problems with suspicion and to try to find the Why rather than rattling off solutions.) So such an interview doesn't really indicate how they will do in position we have for them. (Another factor: it turns out our tech stack is pretty amenable to being maintained, so it takes the pressure off of making mistakes and learning from them while still delivering value.) Also, we can't really use the code interview to test for tech stack knowledge, because probably very few people use our stack. We would have to assume even experienced devs would need a couple of weeks to spin up.
For the rest of it -- verifying resume claims and evaluating various criteria -- it can be done through conversation. And it still boils down to a judgement call.
Fair disclosure of known biases: Our software department is small, so sample size is limited. I'm also saying the above as the person that chose and has been iterating on our tech.
This is absolutely not an essential part of being a programmer. There's an enormous difference between explaining something you've had time to think about on your own with your co-workers and talking out loud while you're trying to solve a difficult problem with someone staring at you and judging you.
This fails to assess every single thing you're supposedly assessing. It's not a good indicator of problem solving ability, technical skills, or communication. It's a good indicator of whether or not that person doesn't have performance anxiety issues and/or has seen that same problem before and already given it thought.
I can not wait until more companies realize how ridiculous and biased this form of interviewing is.
I totally agree with you. What do you think would be a good approach to an interview, if you had the opportunity to lay it out?
Usually when we are interviewing, I try to keep the candidate as relaxed as possible: voicing that explicitly, at the maximum two people at a given interview (with some exceptions). Doing that is easy enough, but how to actually make the candidate comfortable?
One good way (IMO) is to give enough time for problem solving through a tool like Hacker Rank or similar, and then after you have that out of the way, a friendly conversation about systems design/cultural fit/etc in person.