Almost all interviews I've conducted have been a discussion session, not a game of programming Trivial Pursuit. I think a "stream of consciousness" discussion on programming, problem solving and other related technical matters is much more effective. Even with a junior level programmer, most will be quick to show you in a discussion what they know and don't know. It also gives you some idea about how well you sync with the other person.
Right now, I'm looking for a new job and it seems Trivial Pursuit is the name of the game at most companies. I've gotten homeworked, whiteboarded and computer science trivia questioned a lot. It's been rather annoying and frustrating at times. "No, I can't tell you how to balance a b-tree off the top of my head. If I really needed that info I'd Google it. Instead, let me tell you how I wrote a web service and application to keep multiple manufacturing lines supplied and synchronized. Or, maybe the one that coordinated logistics across several warehouses."
As for what I ask or like to be asked in interviews at the senior level, I like a discussion of previous projects. What approach/pattern was used? What were the more complex problems solved and how were they solved? Was the project a success with users? How did you interact with users? How did you delegate tasks to junior programmers on your team? How did you usually mentor junior programmers or new mid-to-senior level developers on your team? How did you handle testing and deployment?
How do you reject solving these challenges? Do you simply say it like this - no, I won't be solving it? :) Though I'm sure you have a very polite but firm way of saying it.
I don't necessarily reject entirely but I redirect them to fit the context of the job I'm interviewing for, almost always a .NET/C# developer position. For example, I would explain that I would use built-in language features, such as LINQ and generics, to handle sorting, linked lists and so forth. I would emphasize that I don't want to reinvent the wheel when the language offers a rich set of features that have been exhaustively tested.
Almost all interviews I've conducted have been a discussion session, not a game of programming Trivial Pursuit. I think a "stream of consciousness" discussion on programming, problem solving and other related technical matters is much more effective. Even with a junior level programmer, most will be quick to show you in a discussion what they know and don't know. It also gives you some idea about how well you sync with the other person.
Right now, I'm looking for a new job and it seems Trivial Pursuit is the name of the game at most companies. I've gotten homeworked, whiteboarded and computer science trivia questioned a lot. It's been rather annoying and frustrating at times. "No, I can't tell you how to balance a b-tree off the top of my head. If I really needed that info I'd Google it. Instead, let me tell you how I wrote a web service and application to keep multiple manufacturing lines supplied and synchronized. Or, maybe the one that coordinated logistics across several warehouses."
As for what I ask or like to be asked in interviews at the senior level, I like a discussion of previous projects. What approach/pattern was used? What were the more complex problems solved and how were they solved? Was the project a success with users? How did you interact with users? How did you delegate tasks to junior programmers on your team? How did you usually mentor junior programmers or new mid-to-senior level developers on your team? How did you handle testing and deployment?
Thank you, Frank. This is very interesting.
How do you reject solving these challenges? Do you simply say it like this - no, I won't be solving it? :) Though I'm sure you have a very polite but firm way of saying it.
I don't necessarily reject entirely but I redirect them to fit the context of the job I'm interviewing for, almost always a .NET/C# developer position. For example, I would explain that I would use built-in language features, such as LINQ and generics, to handle sorting, linked lists and so forth. I would emphasize that I don't want to reinvent the wheel when the language offers a rich set of features that have been exhaustively tested.
That's a good advice on how to handle this, thank you!