Quote:
Originally Posted by cjd
What bugs me most is that people think these questions are worth asking!
I learn more pairing on a 35 minute "easy" coding problem with lots of potential roads to "success" than nearly anything else I've found available. Currently working to write some new options, since policy is "gotta code pair". I like to build them so they're impossible to fail (unless you do nothing) and usable at any level. All about approach and the interaction, either coaching or being coached, reviewing, etc.
In fact, people that are really good at the academic questions typical of a tech interview are among the worst I've found to work with. It probably doesn't help that my specialty is an area where only one narrow subset of skills is typically what managers and hiring process target...
|
Yeah this pretty much. Not only that but for leetcode style problems, while they do have easy, medium, and hard problems just about all of the easy ones provide sufficient feedback for what is being asked. I guarantee 80% if not more of the roles people apply to, even for Silicon Valley companies, don't necessitate anything that a harder problem would involve.
Personally when I was interviewing people two jobs ago my go to question was just stuff like: "given an array of elements could you tell me if there's a duplicate?"
Super easy, you literally just use a set, one of the easiest data structures to use. No overhead complexity to it, relevant to real life (i.e. you use an API and said API doesn't have a filter function so how do you remove duplicate return values from the list you initially get back, etc.).
You can then build on it and ask how you'd do it for a huge log file with millions of lines. Again, pretty easy and relevant and also tells me you understando how to open and read a simple text file.
Whereas yesterday I was asked to find the longest monotically increasing subsequence, and they want the ideal, efficient solution, which uses dynamic programming aka recursion, etc.