4 ms·
Why wouldn't you just do it? I can understand if they're nit-picking syntax but I personally ask people to write out algorithms/code on the board all the time i
by thomaskcr 12y ago
Why wouldn't you just do it? I can understand if they're nit-picking syntax but I personally ask people to write out algorithms/code on the board all the time in interviews. I don't care about the code, I want to see them think through a problem. They can use any for syntax they want, even mix and match things like brackets and indentation or how control structures are defined (for i = 1 to 10 { .. } ), or use a function outside of the current abstraction level without writing it as long as they say what they're doing.
If you can't write out an algorithm or some classes that work together without a compiler/interpreter, then you're just guess and checking as you work and not thinking through what you do ahead of time. I can't program without google, but I can write out my implementation just fine -- that's what people are interested in.
I don't really get how I'm being an idiot wanting to explore how someone solves a problem in the medium they work (code) -- I'm not a human compiler so I obviously don't care if their program compiles or is even in a real language, as long as it gets across what they are trying to do and how they would do it.
Also -- you'll need to deal with stupid people forever, the way your comment is worded it sounds like you think you're smarter and better than everyone else and are "above this silliness". When interviewing I'm jaded about people who can't interact with people who they view as "below them" -- you'd hopefully not even make it in the door for an interview if you can't politely answer a question you think is dumb. Like 90% of interactions for software developers outside of their dept are answering dumb questions...
I may need to add dumb questions to my interviews to catch this...
Edit: Also -- can you explain the code you've written/your implementation? How do you include me in your problem solving? What type of questions do you or don't you ask while doing it? Where do you start/how do you start? If the HR person is there, can you explain what you're doing to them? How do you take suggestions? How do you break down your objects (this gives soooo much information about background, I can tell a lot about a developer based on how they name their classes, like people who have worked with only activerecord style classes). I can follow up with a refactoring change (substitute this for that in this situation, decide based on a configuration file - does this require a significant redesign?)
I mean come on... it gives so much information about how someone works, I think its dumber not to ask some type of question with writing "code" - it just gives so much information about a candidate that would be hard to get one question at a time. This one question can infinitely expand and lets them interact about something they know/are comfortable with (the solution to their problem).
Don't be silly.
- jhall1468 12y agoIt's a contrived situation that involves significantly more nerves than any real life situation will. I've known more than a few programmers that were perfectly capable of doing their work, but struggled through interviews because they got nervous during the coding phase. The reality of the situation is that contrived problems in stressful situations are going to result in a lot of false negatives. That may be fine for you since you may be avoiding some false positives, but that doesn't mean your particular method is "the only way."
- thomaskcr 12y agoBut its not contrived -- its like your entire job. You're literally saying "I can't perform my primary job function when there is any pressure whatsoever". That MIGHT be acceptable if you're interviewing for an entry level job. The only other reason I can think for being unwilling to do this is if you're incapable of working with other people - because whiteboarding out solutions with other devs is super common. Even "where do you think I should start, I'm a bit nervous and an idea to get me going would be great" is a perfectly acceptable question. The best interviews are a conversation -- if you turn it into a conversation where we're working together on the problem, it shows a lot about you still. If you take someone else's idea and run with it I think that's really cool, obviously if you need hand-holding it's suboptimal, but there is still a very positive possible outcome from saying "I have no idea where to start" if you're actually nervous. The only ways I can think of to fail writing out code is people skills or being completely unable to program. It's not like I expect a perfect solution in the 30-60 minutes we have, analysis paralysis is just as bad as no-knock raiding the problem. There is some type of middle ground that involves a good solution that had to be done quickly -- maybe you even mention some other avenues to explore. What if you ever have to represent my department in any capacity and someone asks you what your ideas for a problem and you just say "no, I don't do that" -- that doesn't really represent me well. I would be very surprised if being uppity about a question being "below you" ever works, you might as well just walk out the door if you're going to refuse to answer a question on "philosophical principle". The question is just a jumping off point -- its up to you to turn it into a conversation that shows me how great of a programmer you are. If your answer is telling me how dumb my interview is, then that doesn't show me how great a programmer you are at all -- it shows me you have an attitude problem.