|
in reply to On Interviewing and Interview Questions
- What is a wiki?
- Assuming you've been exposed to these, it's fine, but personally, they drive me up the wall. ;-)
- What is a Design Pattern?
- It's been so long since I left school, that I don't remember formal definitions. But do you think that I'm a bad fit for your company just because I've been away from school for nearly a decade?
- What is a Code Smell?
- If it weren't for PM, I wouldn't have heard of this term. It's just a bit on the obscure side, IMO
- What are agile methodologies? (for example, Extreme Programming)
- Ask only if you religiously follow them because you want to know that the interviewee will be able to follow them. I'd flunk out of your interview here.
- What is Test Driven Development (TDD)?
- Isn't this exactly what the name implies? ;-)
- What is xUnit? (e.g. SUnit, JUnit, cppunit, NUnit, ...)
- No idea. ;-)
- Have you heard of Subversion?
- Isn't that the VCS that Linux used to use? Do you actually use Subversion? Or do you really only care that the person has been exposed to version control systems, and are willing to retrain for your specific VCS?
- Why do you want to work at our company?
- Because I'm unemployed and need some money?
- What are you good at? Bad at? Enjoy? Dislike?
- I'm good at coding, bad at stopping at 5 when I've got a deadline looming, and I extremely dislike personal time. If this isn't a question screaming for a cover-up, I don't know what is.
- What are your favourite books/magazines/web sites?
- Your company's website is my favourite. Seriously - do you want a perl geek who lives for perl, or do you want a well-balanced individual who has multiple facets to their lives and thus can think in many directions?
- What are your favourite tools? For example, if you start a new job, what tools *must* you install immediately?
- Perl?
- Tell me about the worst bug from hell (e.g. intermittent crashing program) you faced and how you solved it.
- Now we're getting somewhere. This is a question that is much harder to lie on, and will tell you a lot about the person you're interviewing. You'll see what they've done, and how they handled it. Which is important - because theoretical questions are fine, but they don't face the same time constraints as real problems. Asking, "How do you handle a bug" allows someone to wax eloquent on theoretical bugs. Asking, "How have you handled the worst bug you've faced" goes back in time to a point where they had real pressures - other classes if in school, or project deadlines if in a previous job, personal problems at home, whatever. You'll see what shortcuts they took, if any. It's a very powerful question.
- Describe in detail a recent project you developed that you are proud of.
- You may want to ask this before the previous question, and then focus your debugging question on this project. Also, ask about the role the person had in that project, why they had that role, etc.
Just a few points. Remebering that most people lie in an interview, you want to not ask open-ended questions. You want to ask very specific questions that get at the information you need. Most people don't intend to lie. They just do.
Interviewer: Does your mind ever wander during meetings?
Interviewee (to self): I can't remember any such time, so...
Interviewee: No
It's just a mix between trying to put your best foot forward, and not necessarily remembering everything in the heat of a short (30-90 minute) interview that would be easy to recall when the deadline is further away (say, end-of-day).
|
Re^2: On Interviewing and Interview Questions
by Anonymous Monk on Aug 26, 2005 at 16:10 UTC
|
But you have to admit, those triva questions are the best ones. They tell me as a potential employee that this is a fad driven company. It tells me that they're not serious about their craft. They aren't looking for professionals to help them solve problems. It sounds more like they're rounding up a bunch of low-level hacks to help a manager meet a hiring quota. It tells me the pay is low, and that they'll expect you to work 60 hour weeks like a freshly minted college grad. I'd guess that this company has a real high turnover rate, much higher than the industry average. But those are the negatives. On the plus side, if you decide to take the job, they're will be some tangible benefits. You'll be able to browse slashdot for hours on end, and no one will complain. You won't have to work very hard, because A) either this company is small, so it will likely be out of business soon, or B) this company is large and a reorganization will eliminate or vastly modify any project you should have been working on. | [reply] |
|
|
Being able to answer these trivia questions isn't
necessarily a "pass".
Indeed, for some company cultures, "I don't know" may
well be the "pass" answer. After all, as you point out,
maybe they want to avoid hiring fad-driven
developers and cyber-loafers.
Though these questions are quick to ask (and therefore cheap)
for the interviewer, their drawback is that the act of
asking them may well put the applicant off the company --
as you were. I need to re-think these type of questions.
Update:
As pointed out to me by Rhose, and pontificated
on by Paul Graham in
The Python Paradox,
these trivia questions
may also help identify those people who actually
enjoy programming and computers.
| [reply] |
|
|
...these trivia questions may also help identify those people who actually enjoy programming and computers.
Ah, maybe this is one of those things that differenciate programmers and computer scientists? People with an affinity for the informal and social aspects (chattering on the c2 wiki, etc.) become programmers. And people with an affinity for the formal and the mathematical aspects gravitate towards computer science. Thoughts?
| [reply] |
|
|
