3 ms·
1. I am an engineer (of the electrical variety) 2. I don't believe in memorizing stuff, I believe in understanding stuff... which is why I'm an engineer. You
by valdiorn 12y ago
1. I am an engineer (of the electrical variety)
2. I don't believe in memorizing stuff, I believe in
understanding stuff... which is why I'm an engineer.
You say: "his answer will always be "Why? What problem are you trying to solve?"
Indeed, I WANT people to ask this question. Then I'd like them to suggest why a linked list is or isn't a good candidate for that problem. I will ask them to suggest an alternative method of solving my problem. A good interview is a conversation, but if the candidate has literally no questions to ask, and nothing to provide, and can't even solve the most basic problems that could be memorized, then why would I want him? If a candidate can't come up with a half-decent approach to a problem as simple as FizzBuzz or making a simple data structure container like a linked list; a problem which dwarfs in comparison with what I do on a daily basis at my job, he has no business sitting next to me.
You also say: "Asking an engineer to solve an imaginary problem on the spot is idiotic. "
Well, that just happens to be my job! My boss comes down, asks me "could you solve this problem for me?" and my answer is "I don't know, but I'll try!" and off you go. so my entire job is about solving unknown problems. Isn't yours? I'm not setting up WordPress sites or chaining together SAP modules (not that there's anything wrong with that, I used to do something like that for several years...), we actually solve problems that don't have known solutions, and the amount of data we work with also poses some unique problems. So our interview process is a miniature, and yes, imaginary, version of what you might be tasked with on any given day.
Finally, to clarify, this it the stance I take with people who claim to be "experienced experts". If I'm interviewing an intern or a junior developer, my approach will obviously be very different.
- mrcold 12y agoBut you're not giving your candidates problems, are you? You're giving them specific scenarios with strict algorithmic constraints. In any engineering job the boss asks us to build a system or a tool. He never says solve this very specific task using these very specific rules. You have a lot of freedom when it comes to the actual implementation. Why aren't you replicating this in your interviews? Why do you insist on code tests? Why aren't you insisting on the result? That's what your boss wants. I'm pretty sure he doesn't care about your ability to solve stupid trivia and academic tests. This is why I'm saying you're a bureaucrat. You read somewhere about fizzbuzz and code tests and you stopped there. Didn't think for yourself. Just gobbled up what some other guys decided was good. Want great conversations and to be amazed by experts? Give them real life problems to solve. You will look incompetent too if I start interviewing you with stupid "How do you do X?" questions.
- valdiorn 12y agoYou've already made up your mind about who and what I am based on 3 paragraphs of text (which I wrote in a somewhat sarcastic and aggressive tone, I know, to make it a bit more funny to read, and to invoke some response). But I'm going to level with you: if my expert can't handle a simple problem with training wheels, like FizzBuzz, it is a very strong indicator that attempting to give him a bigger problem to solve (but not code) is a waste of time.
- deleted 12y ago[deleted]
- petervandijck 12y agoYour expert baker example is spot on. I know a chef who asks new cooks to cook a scrambled egg. If they can't do that right (and many can't), it points to real problems with their basics. If they feel cooking a scrambled egg is somehow below them, that's not good either.