The problem is that many (most?) interviewers have no idea how to effectively coax a candidate along. They usually sit there in silence for an awkwardly long period of time and then fail the candidate, or offer totally irrelevant hints that don't reflect how someone would actually think about the problem.
I nearly always use a glorified DFS and I find that roughly
- 50% of the candidates cannot write an iterative or recursive function (never mind actually solve the problem).
- 15% of the candidates can't figure out how to pass data recursively (i.e. a counter) and resort to a global or do it incorrectly (i.e. pass-by-value which won't work).
- 10% start with an iterative solution and change to recursive once they start having trouble (IMO good call but it is solvable iteratively).
- 10% actually come up with a completely correct answer.
~ 5% test their solution with non-provided input.
Sometimes I do wonder what prep the candidate has been given. A lot of the time they seem afraid to add a new function and instead only modify the provided template (do-able but obviously more difficult).
You're thinking that the difficulty of the question matters, but it doesn't. The difficulty is the situation. You freeze up in an interview, but then immediately after the interview you go back and solve the same problem quickly, because the anxiety is gone, and nobody is standing over you watching. But you don't get a second chance after you're rejected.
If you're not anxious, you can solve very hard problems. If you are anxious, you can't solve very easy problems. Many interviewers are astonished that candidates can't do FizzBuzz or whatever, but it's often because these interviewers don't understand fundamental human psychology, and expect everyone to be a robot with no emotions.
I tend to freeze big time in tech/mathy interviews unless I feel there is a good emotional connection with the interviewer.
Naturally, someone interviewing me who's just written a for loop in the language is going to wonder wtf I'm doing in the interview, because to them it seems like something everyone would know.
Someone who understands how to think about the problem could easily get disqualified because they don't have the little things to hand.
Ok but can you not write a pseudocode version of say fibonacci recursively? Like I don't dock people _just_ because their code doesn't compile and when I go to run it through a bunch of test cases I wrote, I'll fix compilation issues. So if you write `for(int i=0;` but the interview was in JS so `int` doesn't work I won't care.
But I guess it's easy to be impressed with the guy who also wrote the thing out in a way that compiled, even though you were not testing for that?
At some point the code deviates enough from the platonic ideal that it's no longer a perfect score. The issue is when that is?
A candidate that is able to quickly produce a correct compilable solution is more impressive than one that doesn't come up with a solution but there are a lot of shades of gray here. Often a candidate rushes to code a solution without checking (either with me or just with an example) that the solution even works. That is not more impressive to me than a candidate who "spends too long" clarifying the problem and coming up with a solid algorithm and runs out of time to code it.
You don't need a perfect score to get hired. Honestly coming up with the "most efficient" algorithm but having no clue about its performance characteristics (i.e. big-o) is going to get you a lower score than a slower algorithm but really understanding it. I do the same for correctness, if you know a part of your algorithm is "wrong" I won't dock as much because IMO you'd run that part through some test cases cause you're suspicious (i.e. should a `<` be a `<=` or even more complex logic). w.r.t. big-o, I've yet to find a candidate that coded a workable algorithm and doesn't know what it is and also couldn't deduce it when given examples (i.e. say you have 6 elements in the array, how many times do you look at their value? 36. say you have 8 elements? 64. say you have n elements? n^2).
That said, I've worked at several places and this is the first one to have a rubric for interviews. Definitely "Write down what success looks like for the exercise" is the part of the article I liked the most. And to that I look for (1) did they clarify the problem (2) can they come up with an algorithm / break the problem up into something workable (3) is what they coded what they designed (4) do they know it's runtime. (4) is pretty much directly one of the metrics so if I don't ask it I don't feel that I can justify the highest rating and from the rest I figure out what I think the other metrics should score.
You mean back up the stack via the return statement?
or via parameters in the function call?
Like I could have a recursive solution that returns the sum of the length of the sub-arrays or I could just pass a mutable object and update the length there.
Which way would depend on the exact problem (i.e. Strings would be best collected in a StringBuilder rather than concatenated but `lengthParam` would probably more clear if it returned a number instead of using the Array).
```
const lengthParam = (a,p) => {
if(Array.isArray(a)) {
for(let c of a) {
lengthParam(c,p)
}
} else {
p[0] = p[0] + 1
}
};
var b = [0]
lengthP([1,2,3,[4,5],[6]], b);
console.log(b[0]) // 6
``` ```
const lengthParam = (a) => {
let count = 0;
for(let c of a) {
if(Array.isArray(c)) {
count += lengthParam(c)
}
else {
count++;
}
}
return count;
};
```
Yet the OP's suggestion was this: "don't have 500 interviews. Have at most 2 or 3 which altogether should not take more than 2 to 3 hours of somebodys time."
In other words, the OP was recommending satisficing rather than optimizing.
Companies waste so much time on interviewing. Their own time and candidate time. Hundreds of interviews, multiple rounds, just a massive amount of time for 1 job. It certainly feels like they're trying to optimize rather than satisfice.
Most companies will also prefer the candidate who who projects tallness and youth.
Maybe these biases are something that companies need to overcome?
One can be very confident in one's work yet be anxious in a job interview.
Ex: being anxious about a job interview might really mean they get anxious in high pressure situations, talking with unfamiliar people, etc.
Depending on the role, these situations could easily be ones you encounter at work as well.
1) In an interview, you can lose the job at any moment for any little reason, because you don't even have the job yet, whereas on the job you're very unlikely to lose your job at any moment for any little reason. It typically takes gross incompetence or insubordination to get immediately fired. I've written plenty of software bugs in my career, as has everyone I suspect, but I've never been fired. I've lost plenty of jobs in interviews though.
2) The stakes are personally higher in a job interview, especially if you're currently unemployed. You can claim theoretically that the stakes are higher on the job, because "millions may be lost", but those aren't your millions, they're the company's millions. The company losing millions may suck for the company, but it doesn't necessarily mean you lose your job. Companies lose millions yet continue in business. Whereas if you don't get a job at all, you'll eventually run out of money and become homeless. That is the highest of stakes, for you.
3) If you've had a job for a while, then your coworkers already know that you're competent. They aren't suspicious of you or sitting in judgment of you, because your work has already been seen and judged. Whereas in a job interview, it is a stranger sitting in judgment of you. The issue isn't necessarily "talking to strangers" but rather you have a stranger who is wondering if you're a "faker who can't code your way out of a paper bag", and you have to prove to them otherwise in an hour.
4) In a job interview, someone is standing over you watching your every move while you work. Unless you do pair programming (which I dislike), most programmers are sitting alone at the computer most of the time, not having someone else stand over them. And even if you do sit with a coworker at the computer on the job, the process is usually collaborative rather than judgmental. You and a coworker sit together to solve a programming problem together, not so that your coworker can judge you and give you an evaluation which determines whether you get paid or not.
5) The tests given in job interviews are usually totally artificial and often have nothing to do with the job. You're just given a test — sometimes ill-defined — out of left field, at the spur of the moment, and you have to solve it in a few minutes, because the job interviewer can't sit and wait for you to take however long you need. People who interview a lot, or who are coached in interviewing techniques, apparently learn that there are tricks to interviewing, and you can ask the interviewer multiple questions to clarify and talk through the process, but someone who doesn't interview much doesn't know this. You rarely get such artificial, out of left field problems at work that need immediate solution. At work, you have meetings, discuss the product, discuss what's needed, before you work on things. Or if there's a work "crisis", the crisis has to do with your company's codebase, which you're already familiar with and may have written yourself!
I could go on and on and on, but hopefully that's enough to show that the pressures of job interviews are unique and not the same as work pressures, no matter how bad the "emergency" at work.
One more thing about different pressures and psychology: It's well known that many people have a specific fear speaking in front of groups of people. So why is the notion so strange that people have a specific fear of job interviews. I have little doubt that there are firefighters, who rush into burning buildings for a living, who would feel sick at the idea of giving a speech in front of a thousand people in a non-burning building. Anxieties are not all the same, they're often very specific.
It's sad to me, though not surprising, that many hard techies don't understand human psychology and have a hard time empathizing.
I do also think that for most roles an interview situation is extremely different to what your job is going to be like.
I've been working 10 years, can get things up and running pretty fast, learn fast, but I'm super anxious in interview (and I've done hundreds). I'm just an anxious person, so most of the time I completely freeze up. Perhaps finding a better way to interview is a better way to hire for diversity.
I think there are two camps of people: truly incompetent liars that look good on paper and people just straight up bad at interviewing who are perfectly qualified. So how do you give the latter a fighting chance?