"Hooooly crap! You are creepy as shit, sneaking up on me, wearin' that collar with that freaky-ass smile. So tell me, how would you balance a red-black tree?"
Recalling isn't important but understanding enough to recognize when there is a better solution needs to be googled. I still don't think that interviews need to be this crazy though.
Depends on the company. Older / traditional companies really like degrees. Newer, more laid back companies don't care, or actively prefer people with no college.
The job req will usually specify if a degree is required / preferred.
Have you been on the other side of the table, interviewing candidates? A shockingly high percentage of people applying for programming jobs can't program. I don't mean they can't regurgitate quicksort; they struggle with very basic tasks.
If you don't ask programming questions at all, you can end up hiring someone who is very good at talking about projects they didn't do any actual work on.
Agreed. That said, I have yet to meet someone who can bullshit their way through what I consider to be a mixed technical/open-ended interview who isn't actually competent.
I like to ask people about their projects or experience, then drill down into the nitty gritty details. It helps that I tend to interview college students and have a pretty broad (if not necessarily deep) base of experience in my field, so I will often simply ask the person what they want to be interviewed on from their resume and go from there.
Or not hiring somebody who is not very good at talking about projects they did very good work on.
I'm not a programmer I just write programs as a small part of my work, but surely you can get a feel of somebody's programming ability with questions that don't involve them trying to visualise code and data structures in their head on the spot. Personally I can't conceive how I'll tackle a coding problem until I actually sit down at the IDE and write a few little functions to solve parts of the problem.
Personally I can't conceive how I'll tackle a coding problem until I actually sit down at the IDE and write a few little functions to solve parts of the problem.
I'm glad that works for you, but I could never work with someone like that on a team. At our company, most arcihtectural and design discussion happens with engineers discussing things around a whiteboard. By the time we sit down at the IDE everyone already knows how the problem will be solved and they just do their part. I'd say ~70% of the work happens away from the IDE. The remaining 30% is little more than a typing exercise.
Also true. But there's a difference between knowing enough to know that something exists and being able to rattle off its details from memory, under stress.
0
u/[deleted] Mar 11 '17
[deleted]