I think this is a reasonable question, probably better for students who still remember their O's and Tries but reasonable enough for the intermediate quality solution -- an engineer who cannot even solve the simpler version probably cannot write algorithms at all.
That said, from the article this article links to, I find this puzzling:
> The candidate’s performance on the problem isn’t binary. The worst candidates don’t even manage to implement the fizzbuzz solution in 45 minutes. The best implement a memoized solution in 10 minutes, allowing you to make the problem even more interesting, e.g., asking how they would handle a dictionary too large to fit in main memory. Most candidates perform somewhere in the middle.
Two things I worry about: if the interview isn't "binary", how do you decide whether the candidate passed? Is doing just the simpler version fine as long as you ask for low pay? Or are you still failed? Or does it depend on whether other candidates did better, which is another way of saying you failed? It seems to me it's still binary.
And the other thing is: if the candidate did great in 10', please don't ask additional questions. The candidate is a "hire". Don't make it "interesting", an interview is not the place to shake things up to make it "interesting". Understand that for most people, interviewing is a stressful situation. For "interesting" times they have their friends and Netflix.
> Two things I worry about: if the interview isn't "binary", how do you decide whether the candidate passed? Is doing just the simpler version fine as long as you ask for low pay? Or are you still failed? Or does it depend on whether other candidates did better, which is another way of saying you failed? It seems to me it's still binary.
When I did interviews, I did a problem in a kind of similar way (although I skipped most of this article, so I dunno). I'd give the same problem to all candidates, but expectations were higher for candidates with more experience.
For any candidate, there was a minimum bar (essentially needed to be able to program a loop that did what they said it would do), and failure was a very clear signal; although I had a couple candidates that the only signal I got was anxiety.
How much over the minimum the candidate got would help decide between weak to strong hire. And then there's a group decision based on the results from everyone.
> And the other thing is: if the candidate did great in 10', please don't ask additional questions.
Part of the job as an interviewer is to fill the whole time though. If we're done in 10 minutes of a 45 minute slot, that's a lot of time to fill. Usually the next interviewer is busy until the next one. A candidate doesn't usually have 35 minutes of questions, and a trip to get snacks or drinks, etc doesn't take that long either. At that point, you just have to ask them about projects and see if they've got anything they want to talk about --- but since that's not my interview role, I won't judge that.
I did have one candidate who I was the last interviewer of the day and they didn't like my question and asked for something else and wouldn't participate at all. We were done in under ten minutes, so I just walked them out and we both got 35 minutes of our life back.
> Part of the job as an interviewer is to fill the whole time though. If we're done in 10 minutes of a 45 minute slot, that's a lot of time to fill. Usually the next interviewer is busy until the next one.
Right, I forgot this is Google and there's an in-person gauntlet to run! I would probably fail it just because a single interview usually leaves me drained.
Let me ask another question, can an engineer who solved everything in 10' screw up badly during the follow up questions which get asked to "make things interesting"? Even if this is unlikely, if it's at all possible it seems to me the optimal strategy of a good candidate is to stretch their answers as much as possible to prevent the introduction of followup "interesting" questions...
I'm not of Google, but big tech interviews are similar in a lot of ways, so yeah.
I've seen local candidates get interviews split over two days. You could probably ask for one split over several days, but not if the company is paying for a hotel. I dunno.
On my question, all the follow up work after the basics wouldn't make the rating go down. Other than like any sort of behavioral issues that came up; but I don't remember seeing anything like that; even from people we hired who later exhibited issues; they were able to keep it together during the interviews anyway.
The risk of intentionally stretching answers is that it might look like you've seen the problem before and are trying to hide it. My problem (and this problem) aren't really unique, although I didn't see too many people who had seemed to see it before; and my focus wasn't on the highly technical bits; the basics are quite simple, but there's a major downside to the simple solution with certain inputs, there's lots of ways to address that, I just want the candidate to come up with anything, it doesn't need to be the best, they don't need to know if it's the best, or how to know if it's the best, it really just needs to be complicated enough that the first code sample is more than 5 lines long; if we really ran through the problem in 10 minutes, we can spend some time exploring alternatives, but I'm not judging someone poorly because they did their way and can't think of seven others.
Typically candidates are scored on a scale. And there are multiple interviews. The final hire / no-hire is decided based on the scores and written feedback from all interviews.
My mid-mark would be where someone could write the code for the brute-force answer for both parts but couldn't get the memoize / dynamic-programming solution. That would be where I'd say "I'm not sure, look at other interviews". Otherwise I'll make a hire / no-hire recommendation.
Interesting. Thanks for the honest answer. (For the record, I'd do fine with brute-forcing both parts but would struggle with memoization in an interview context).
Depends on role and level as well. SRE or junior SWE might get a “hire” for that but a senior SWE probably would go back to the other interviews as mentioned above.
That said, from the article this article links to, I find this puzzling:
> The candidate’s performance on the problem isn’t binary. The worst candidates don’t even manage to implement the fizzbuzz solution in 45 minutes. The best implement a memoized solution in 10 minutes, allowing you to make the problem even more interesting, e.g., asking how they would handle a dictionary too large to fit in main memory. Most candidates perform somewhere in the middle.
Two things I worry about: if the interview isn't "binary", how do you decide whether the candidate passed? Is doing just the simpler version fine as long as you ask for low pay? Or are you still failed? Or does it depend on whether other candidates did better, which is another way of saying you failed? It seems to me it's still binary.
And the other thing is: if the candidate did great in 10', please don't ask additional questions. The candidate is a "hire". Don't make it "interesting", an interview is not the place to shake things up to make it "interesting". Understand that for most people, interviewing is a stressful situation. For "interesting" times they have their friends and Netflix.