3 ms·

The best real world problems I encounter at Google take months of learning to fully comprehend. They are not trivial, and have a huge base. Even a simpler real

The best real world problems I encounter at Google take months of learning to fully comprehend. They are not trivial, and have a huge base. Even a simpler real world problem whereby it takes days of research is not respectful of your time. I've seen people note they can't take a 6 hour time-out of their busy work/home lives to do coding challenges that are popular among startups. So the balance is in-person interviews. Ones where you have to give difficult problems, ones you haven't seen before and ones that don't take days to explain. This usually means algorithmic, data structures, or mathematical in nature. They have subtleness, depth and complexity. As for 'reverse a string', you'd be surprised how many people who have "programming jobs" who apparently can't do basic programming. And do I use these skill sat my job here? Yes. All the time. I'll spare you the spiel about "everything's different at scale". Google is a different kind of company that attempts to solve as many problems as possible with CS. For reference, I work at Google, given interviews here, and passed the interview bar twice. Once at 29 and once at 39. Some of my coworkers are older than me. Many of them have children. Some are younger than me. I see plenty of people in the office with grey hair (I work in the SF office). I refuse to defend past practices, but I believe the company currently sincerely overall seeks to be the best employer for any age. Small pockets of suck happen, but the internal transfer rules let you switch without your manager's permission. The interview process is known to not be perfect, but that is inevitable for any process - nothing is ever perfect! However, the interviews do involve whiteboard problem solving. I understand some can't do it, and this is one of the blind spots. I personally love diagrams, and think visually, so it works for me. I also prefer when my colleagues use diagrams as well.

zanethomas 10y ago
Good points. I do understand that Google has no reason to modify its interview process to accommodate my personal style, but then I'm not really complaining, I just never wasted my time applying. About diagrams. I had the whiteboard experience once and will avoid repeating it. When I get a problem I want to sit back and think about it. The interviewers kept insisting that I draw diagrams, and that interrupted my thought process, they were not impressed. However that does not mean I am incapable of making diagrams once I've sorted the problem out in my mind. After I've arrived at a proposed problem solution I like to produce a written document with just enough information to convey the problem and the solution approach, together with whatever diagrams, data structures, and pseudocode are required to communicate. That's how I roll. ymmv :)
- ryanobjc 10y ago
  Here's the thing... without explaining your thought process, how do you even demonstrate you have one? How do you get depth of understanding? It's via a conversation, over a hard problem. With lots of stops in between. As a side note, I think there are fundamental limitations to "solve entire problem in mind" - tooling, including written word, pens, pencils, crayons, paper, documents, diagrams, whiteboards, provide methods for expanding your working memory. One other thing "just enough information" is a phrase that worries me. I've seen a lot of academically written papers that basically "by implications you should know that the resulting answer is X". I'm not sure this is your style or not, but it is one style that personally I believe has no place in the workplace. Convey your ideas clearly, and help your coworkers.
  - zanethomas 10y ago
    I would be entirely comfortable in an interview explaining my thought processes and if I stumble into a whiteboard interview again I will try to do that. The result couldn't be worse than my previous result. With regard to your other two points I either wasn't clear or you took my comments too literally. Be that as it may, let me clarify. I do form my entire impression of the problem and various solutions entirely in my mind, without the aid of external memory. However, and this is important, that evolves out of research. During research I build something like an intuitive understanding of the problem. Along the way I consider possible solutions to the evolving problem, solutions by others or that happen to occur to me. Eventually, usually at night when it's quiet, I have an insight, which often turns out to not be quite right. Rinse and repeat until I have something that seems good. At which point I will sketch out some data structures (as struct or object like things, or simple diagrams) and some pseudo code to operate over the data. If that finds a flaw in my idea I go back for more rinse and repeat cycles. When I say "just enough information" I mean just enough for any engineer with sufficient experience and background to fully understand the problem and solution. I don't leave anything out, I want feedback and I don't want the feedback to be "huh?". By "sufficient experience and background" I am leaving open the possibility that there might be someone in the group who doesn't quite get it, but to tell the truth most good solutions to most problems turn out to be reasonably simple, simplicity is one of my target criteria. Simple solutions are easier to implement, less likely to have bugs, and if the solution is both simple and good the performance is likely to be at least acceptable as well. Better? :)

zanethomas 10y ago

Good points. I do understand that Google has no reason to modify its interview process to accommodate my personal style, but then I'm not really complaining, I just never wasted my time applying. About diagrams. I had the whiteboard experience once and will avoid repeating it. When I get a problem I want to sit back and think about it. The interviewers kept insisting that I draw diagrams, and that interrupted my thought process, they were not impressed. However that does not mean I am incapable of making diagrams once I've sorted the problem out in my mind. After I've arrived at a proposed problem solution I like to produce a written document with just enough information to convey the problem and the solution approach, together with whatever diagrams, data structures, and pseudocode are required to communicate. That's how I roll. ymmv :)

ryanobjc 10y ago
Here's the thing... without explaining your thought process, how do you even demonstrate you have one? How do you get depth of understanding? It's via a conversation, over a hard problem. With lots of stops in between. As a side note, I think there are fundamental limitations to "solve entire problem in mind" - tooling, including written word, pens, pencils, crayons, paper, documents, diagrams, whiteboards, provide methods for expanding your working memory. One other thing "just enough information" is a phrase that worries me. I've seen a lot of academically written papers that basically "by implications you should know that the resulting answer is X". I'm not sure this is your style or not, but it is one style that personally I believe has no place in the workplace. Convey your ideas clearly, and help your coworkers.
- zanethomas 10y ago
  I would be entirely comfortable in an interview explaining my thought processes and if I stumble into a whiteboard interview again I will try to do that. The result couldn't be worse than my previous result. With regard to your other two points I either wasn't clear or you took my comments too literally. Be that as it may, let me clarify. I do form my entire impression of the problem and various solutions entirely in my mind, without the aid of external memory. However, and this is important, that evolves out of research. During research I build something like an intuitive understanding of the problem. Along the way I consider possible solutions to the evolving problem, solutions by others or that happen to occur to me. Eventually, usually at night when it's quiet, I have an insight, which often turns out to not be quite right. Rinse and repeat until I have something that seems good. At which point I will sketch out some data structures (as struct or object like things, or simple diagrams) and some pseudo code to operate over the data. If that finds a flaw in my idea I go back for more rinse and repeat cycles. When I say "just enough information" I mean just enough for any engineer with sufficient experience and background to fully understand the problem and solution. I don't leave anything out, I want feedback and I don't want the feedback to be "huh?". By "sufficient experience and background" I am leaving open the possibility that there might be someone in the group who doesn't quite get it, but to tell the truth most good solutions to most problems turn out to be reasonably simple, simplicity is one of my target criteria. Simple solutions are easier to implement, less likely to have bugs, and if the solution is both simple and good the performance is likely to be at least acceptable as well. Better? :)