nr: #1 dodano: 2016-12-18 08:12
In college we studied questions asked by interviewers, and I knew a lot of the ones I was later asked when I interviewed myself.
First off: Don't lie. This should be obvious.
Let the interviewer know you've seen something similar, talk through what you heard them ask and compare it to what you remember from before. They might stop you, or they may point out a variation in the question that you missed when you "thought you knew the answer." As an interviewer, I've done this on purpose. I've asked a variant on a previous question from their on-campus interviews, and I've had some folks keep trying to solve the wrong question - even when I pointed out that's not what I asked.
The interviewer might add new constraints to the problem and have you solve those. My questions are open ended such that if a candidate either gets stuck or breezes through, I have ways of adjusting to keep making progress. It's bad for everyone if the candidate gets stuck and produces nothing, or doesn't feel challenged and doesn't get a chance to show how they think on their feet.
Best of all, show the interviewer something new about a problem they might not have seen before. In my interviews when I was hired, we started with a question I knew... Then I showed a variant I came up with. Then we talked about something I was learning, and we did a design brainstorm on the board. (at the time I was learning C++ on my own, and we talked about how class interfaces and inheritance might be implemented starting from C.)
To reiterate: Don't lie. If you get caught, it's over.
And to the rest of us: Make up your own questions - I hate being asked a programming question out of a book. It's disrespectful and unrealistic. Come up with a question inspired by what you plan to have the candidate do.