> A lot of it is memory. If you have recent memory of writing, say, a bunch of tree traversal implementations, you're going to solve those problems a lot faster than someone without that recent practice.
It is a factor but not the purpose. Yes, if you don't remember how to do something, you'll have a hard time doing it unless you can derive it from first principles. There is literally nothing you could ask in an interview that would not involve memory, though. "How would you reverse a linked list in C"? Definitely some memory there. "How would you implement a hash table?" Also requires memory. "What did you work on at your old job?" Again, memory.
> And if you're talking a 45-min or 1-hr one-or-two-question phone screen, companies are putting a lot of value on that quickness.
Eh, maybe. I think studying up on interview problems is a good idea in general, because it gets you practice thinking through problems and recognizing similar situations. However, I don't consider it a positive to see someone burn through the "right" solution with no apparent thought. If you've seen the problem and don't say so, I have to lean toward no-hire, because pure rote memory is not interesting. If you have clearly done the problem recently but deny it when asked, I have to question your ethics, too. You might just be a genius, but them I expect you to seem like a genius when we discuss technical matters and not just when solving interview questions.
> I haven't seen many interviewers (as candidate or as a fellow interviewer) who truly value "talking knowledgeably about Big O notation" or "knowing what a hash table is" anything near as much as "wrote a whiteboard implementation of topological sort quickly enough." It's the latter part that I object to.
I don't ask questions like that and most of the my colleagues don't either. I do ask technically difficult questions and expect code, but I don't expect perfect code. I expect candidates to work through a reasonable solution out loud and write at least part of it in code that could work with a little polish. If you write terrible code and leave off-by-one errors everywhere and can't recognize them when prompted, it's probably a no hire.
> Friend of mine is at a place that seems to need this desperately: about 15-25 "smart people who can learn" mostly straight out of school, but a culture that's mostly the-blind-leading-the-blind and rediscovering known solutions
Your friend works somewhere with poor staffing practices, then. If you don't have some senior people promoting proper dev culture and practices, it's going to be a mess of poor engineering and reinventing the wheel.
It seems like we're mostly on the same page, just approaching it from different directions. Maybe I've just gotten unlucky in my interview experiences at startups/establish Bay Area "coding question"-focused shops. :\
I won't lie. Interviewing is tough. I've been involved with some bad interviews from both sides. I wish there was a better way, but I'm not convinced that any of the alternatives typically proposed are actually better.
I gave some interviews when I was at Yahoo that I recognize in retrospect were pretty terrible. Questions with clever/trick answers, trendy topics, etc. The only thing I never did was the pure brain teasers (a fox, chicken, and farmer need to cross a river...). I try to do better now. :\
It is a factor but not the purpose. Yes, if you don't remember how to do something, you'll have a hard time doing it unless you can derive it from first principles. There is literally nothing you could ask in an interview that would not involve memory, though. "How would you reverse a linked list in C"? Definitely some memory there. "How would you implement a hash table?" Also requires memory. "What did you work on at your old job?" Again, memory.
> And if you're talking a 45-min or 1-hr one-or-two-question phone screen, companies are putting a lot of value on that quickness.
Eh, maybe. I think studying up on interview problems is a good idea in general, because it gets you practice thinking through problems and recognizing similar situations. However, I don't consider it a positive to see someone burn through the "right" solution with no apparent thought. If you've seen the problem and don't say so, I have to lean toward no-hire, because pure rote memory is not interesting. If you have clearly done the problem recently but deny it when asked, I have to question your ethics, too. You might just be a genius, but them I expect you to seem like a genius when we discuss technical matters and not just when solving interview questions.
> I haven't seen many interviewers (as candidate or as a fellow interviewer) who truly value "talking knowledgeably about Big O notation" or "knowing what a hash table is" anything near as much as "wrote a whiteboard implementation of topological sort quickly enough." It's the latter part that I object to.
I don't ask questions like that and most of the my colleagues don't either. I do ask technically difficult questions and expect code, but I don't expect perfect code. I expect candidates to work through a reasonable solution out loud and write at least part of it in code that could work with a little polish. If you write terrible code and leave off-by-one errors everywhere and can't recognize them when prompted, it's probably a no hire.
> Friend of mine is at a place that seems to need this desperately: about 15-25 "smart people who can learn" mostly straight out of school, but a culture that's mostly the-blind-leading-the-blind and rediscovering known solutions
Your friend works somewhere with poor staffing practices, then. If you don't have some senior people promoting proper dev culture and practices, it's going to be a mess of poor engineering and reinventing the wheel.