Nice. I have a question and a couple of suggestions:
Company that currently employs me doesn’t expect candidates to know answers to “trivia” questions. During interviews we allow candidates to make up any reasonable API they might want to use. Do you think answer like “I didn’t use Filter() in a while so I’d look it up details before actually using it(a few minutes of reading documentation vs hours of debugging). Roughly it...” would work well (for something you don’t use so often you know it by heart)?
I think making the interview pleasant for your interviewer does increase your chance of success / good feedback in case the company rejects you. I don’t see it mentioned in advice I read. Maybe it’s just obvious for almost everyone but me but I think mentioning that can really help people who have technical skills but didn’t think about it.
One really useful piece of advice I got when I was interviewing was to practice answering interview questions by writing on paper / whiteboard. I had to write code using one of those during my interviews and I would have much more trouble if my writing speed was as low as it was when I started practicing (after limiting myself to writing using keyboard for some years).
Because I’m not sure what the motivations behind asking trivia questions are, I don’t know for sure how your answer would be perceived. That is likely how I would answer a question about an API I wasn’t familiar with, though filters are more of a structural aspect of .NET MVC than an API (though it’s still all functions at the bottom). Not knowing an important structural aspect of a framework you claim to be proficient in can be a red flag—though in my case I knew what they were, but did not know what they were called. (I looked them up after the first interview where I was asked about them, which was a good thing, because I was asked about them again in my last interview.) Another good lesson!
I agree that making the interview pleasant for the interviewer is a good idea. It does seem like a “too obvious to be said” sort of thing, which probably means it needs to be said more often. The question that follows is how to do that, especially if you don’t have an instinct for it.
I’ve also read the advice to practice answering questions on a whiteboard. It’s good advice, but in the interview that got me hired I didn’t actually do any whiteboarding, so I didn’t think to list it.
Nice. I have a question and a couple of suggestions:
Company that currently employs me doesn’t expect candidates to know answers to “trivia” questions. During interviews we allow candidates to make up any reasonable API they might want to use. Do you think answer like “I didn’t use Filter() in a while so I’d look it up details before actually using it(a few minutes of reading documentation vs hours of debugging). Roughly it...” would work well (for something you don’t use so often you know it by heart)?
I think making the interview pleasant for your interviewer does increase your chance of success / good feedback in case the company rejects you. I don’t see it mentioned in advice I read. Maybe it’s just obvious for almost everyone but me but I think mentioning that can really help people who have technical skills but didn’t think about it.
One really useful piece of advice I got when I was interviewing was to practice answering interview questions by writing on paper / whiteboard. I had to write code using one of those during my interviews and I would have much more trouble if my writing speed was as low as it was when I started practicing (after limiting myself to writing using keyboard for some years).
Because I’m not sure what the motivations behind asking trivia questions are, I don’t know for sure how your answer would be perceived. That is likely how I would answer a question about an API I wasn’t familiar with, though filters are more of a structural aspect of .NET MVC than an API (though it’s still all functions at the bottom). Not knowing an important structural aspect of a framework you claim to be proficient in can be a red flag—though in my case I knew what they were, but did not know what they were called. (I looked them up after the first interview where I was asked about them, which was a good thing, because I was asked about them again in my last interview.) Another good lesson!
I agree that making the interview pleasant for the interviewer is a good idea. It does seem like a “too obvious to be said” sort of thing, which probably means it needs to be said more often. The question that follows is how to do that, especially if you don’t have an instinct for it.
I’ve also read the advice to practice answering questions on a whiteboard. It’s good advice, but in the interview that got me hired I didn’t actually do any whiteboarding, so I didn’t think to list it.
Thanks!