My experience is a little skewed, in that all of the companies I have worked for in “recent” history (let’s call it the last 7 years), have needed to be small, scrappy, and highly effective.
Whether a product company, a consultancy with a delivery department, or a more traditional software vendor relationship, every company I work for has need for a small number of developers to produce new / rebuilt / renovated products, in a few short months.
Because of this, when I interview a candidate, I find the canned algorithms to be utterly useless. I don't need to know that they have memorized Cracking the Coding Interview, nor that they have memorized the minutiae of a given language.
I need to know that the person can learn, regardless of where they are in their journey (with different levels of expectation, based on the role). As such, I generally try to go on a programming journey with them; whether they do the typing, or I do, or we whiteboard, I will start with a completely trivial problem like “How would you add 1 to each element in this list?”. This is a “can you write any code at all” litmus (because I will have offered to type, they just need to give me the gist of their algorithm), which has actually caught a couple of people who were completely unfamiliar with code, whether imperative, declarative, FP, OO, or just old-fashioned structured programming statements. I try to make clear that there is no single “right” answer I expect, and that there are no trick questions.
Assuming they are capable of answering the question, or typing a solution, I don't really care how they solve it; my goal is now to build on and evolve their solution.
I want to slowly get them to the limit of their comfort zone, in some small way. Never used recursion? Let's try. Never mapped over a list of data with a transformer? Let's implement a map function. You know all of this stuff? Move onto recursive, variadic auto-currying, or architecting a library to automate bumping semver based on commit messages — wherever the path leads (again, role/experience/salary bracket in mind).
I want to see how a person reacts to learning something new. Even if I have to hold their hand through the explanation, or the implementation. That’s fine, too.
The next step, then, is to pose a problem that requires the learning we just went through. It doesn't need to be a massive challenge; if we invented a map function with a transformer, how might we make a filter function, with a predicate that takes the same input, with this predicate, and returns this output?
In my head, I am keeping tabs on how the person responds to being out of their element. Are they terrified? Are they going to throw their hands up, and storm out in a huff? Are they going to be dangerously stubborn, and antagonistic? Are they inquisitive, or curious, or eager?
See, on top of coping with the unknown, learning, and applying the knowledge, how the person responds in these situations is important, when they are put in a small team with a known culture. I have said no to some of the smartest interviewees, because they had meltdowns when we did something out of their ordinary, or I questioned their programming ideology (not contradiction, just “why do you think that _?” or “tell me about why you chose to _.”) within the journey. “Because if you don't do it my way, you are stupid” is generally a no from me.
At the end of the day, I expect this person to be faced with things they have never even heard of before, and in a short timeframe, they will have to gain an understanding and make progress. There will probably be support, but if the person is going to be fatalistic, or feudalistic, it isn't going to work for a team with a limited number of seats and a limited amount of time.
The rest of the interview is standard fare.
Like I said, not everyone’s experience, but this is how I approach interviews and why.
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.
My experience is a little skewed, in that all of the companies I have worked for in “recent” history (let’s call it the last 7 years), have needed to be small, scrappy, and highly effective.
Whether a product company, a consultancy with a delivery department, or a more traditional software vendor relationship, every company I work for has need for a small number of developers to produce new / rebuilt / renovated products, in a few short months.
Because of this, when I interview a candidate, I find the canned algorithms to be utterly useless. I don't need to know that they have memorized Cracking the Coding Interview, nor that they have memorized the minutiae of a given language.
I need to know that the person can learn, regardless of where they are in their journey (with different levels of expectation, based on the role). As such, I generally try to go on a programming journey with them; whether they do the typing, or I do, or we whiteboard, I will start with a completely trivial problem like “How would you add 1 to each element in this list?”. This is a “can you write any code at all” litmus (because I will have offered to type, they just need to give me the gist of their algorithm), which has actually caught a couple of people who were completely unfamiliar with code, whether imperative, declarative, FP, OO, or just old-fashioned structured programming statements. I try to make clear that there is no single “right” answer I expect, and that there are no trick questions.
Assuming they are capable of answering the question, or typing a solution, I don't really care how they solve it; my goal is now to build on and evolve their solution.
I want to slowly get them to the limit of their comfort zone, in some small way. Never used recursion? Let's try. Never mapped over a list of data with a transformer? Let's implement a map function. You know all of this stuff? Move onto recursive, variadic auto-currying, or architecting a library to automate bumping semver based on commit messages — wherever the path leads (again, role/experience/salary bracket in mind).
I want to see how a person reacts to learning something new. Even if I have to hold their hand through the explanation, or the implementation. That’s fine, too.
The next step, then, is to pose a problem that requires the learning we just went through. It doesn't need to be a massive challenge; if we invented a map function with a transformer, how might we make a filter function, with a predicate that takes the same input, with this predicate, and returns this output?
In my head, I am keeping tabs on how the person responds to being out of their element. Are they terrified? Are they going to throw their hands up, and storm out in a huff? Are they going to be dangerously stubborn, and antagonistic? Are they inquisitive, or curious, or eager?
See, on top of coping with the unknown, learning, and applying the knowledge, how the person responds in these situations is important, when they are put in a small team with a known culture. I have said no to some of the smartest interviewees, because they had meltdowns when we did something out of their ordinary, or I questioned their programming ideology (not contradiction, just “why do you think that _?” or “tell me about why you chose to _.”) within the journey. “Because if you don't do it my way, you are stupid” is generally a no from me.
At the end of the day, I expect this person to be faced with things they have never even heard of before, and in a short timeframe, they will have to gain an understanding and make progress. There will probably be support, but if the person is going to be fatalistic, or feudalistic, it isn't going to work for a team with a limited number of seats and a limited amount of time.
The rest of the interview is standard fare.
Like I said, not everyone’s experience, but this is how I approach interviews and why.