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.
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 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.