3 ms·

Yes, and I agree pseudocode should be doable if leniently judged. But I guess it's easy to be impressed with the guy who also wrote the thing out in a way that

Yes, and I agree pseudocode should be doable if leniently judged. 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?

lesuorac 4y ago
Work has a bunch of metrics and only 1 of them is _directly_ about code so if you do a good job clarifying the problem and coming up with a pseudocode solution I'd still give you a positive rating but not one of the highest ones. And to clarify, I just write a report about the interview. Other people make a hire/reject decision based on all the reports and I'd imagine if you did poorly in the code metric in all of them it'd become a reject but I don't keep that statistic. I have a feeling (but no proof) that the other people care more about what I wrote in my notes than my actual score. 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.

lesuorac 4y ago

Work has a bunch of metrics and only 1 of them is _directly_ about code so if you do a good job clarifying the problem and coming up with a pseudocode solution I'd still give you a positive rating but not one of the highest ones. And to clarify, I just write a report about the interview. Other people make a hire/reject decision based on all the reports and I'd imagine if you did poorly in the code metric in all of them it'd become a reject but I don't keep that statistic. I have a feeling (but no proof) that the other people care more about what I wrote in my notes than my actual score. 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.