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;
};
```
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).