3 ms·

I often google even very basic shit. If the IDE doesn't give me the structure of the for loop in a given language, I look it up. If I forget how to split a stri

I often google even very basic shit. If the IDE doesn't give me the structure of the for loop in a given language, I look it up. If I forget how to split a string, I look it up. If I forget what the print statement looks like, I look it up. 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.

lesuorac 4y ago
> I often google even very basic shit. 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.
- lordnacho 4y ago
  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

> I often google even very basic shit. 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.

lordnacho 4y ago
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.