<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>raldi</author><text>I&amp;#x27;m a Google SRE, and the first place I go when faced with a complicated problem is the whiteboard (if collaborating with others) or the legal pad (if I&amp;#x27;m trying to figure it out myself).&lt;p&gt;If collaborating with others in a remote office, I begrudgingly make a Google doc and treat it like a whiteboard.&lt;p&gt;Most of what we do involves enormously complicated systems with lots of nodes and RPC flows between those nodes, different pathways depending on the flavor of the RPC, systems spread out in different metros around the world... it&amp;#x27;s very difficult to visualize all that complexity in your head if you&amp;#x27;ve never seen it on a cocktail napkin.&lt;p&gt;For example, just last week I sketched out a diagram inspired by the famous visualization of Napoleon&amp;#x27;s campaign to Moscow (&lt;a href=&quot;http://www.aviz.fr/wiki/uploads/Research/minard.jpg&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;www.aviz.fr&amp;#x2F;wiki&amp;#x2F;uploads&amp;#x2F;Research&amp;#x2F;minard.jpg&lt;/a&gt;), primarily to help me wrap my head around a complicated RPC flow (at the first node, 32% of the RPCs are classified as XYZ. Each of those spawns 3 new RPCs that go here and 1 that goes over there...) When I got stuck, I called over a colleague, and he was able to immediately see, just by looking, where I was going wrong, and with a few strokes of the marker, set me straight.&lt;p&gt;I later turned it into a spreadsheet so I could use it to explain the model to others. Also, it was nice to be able to use worksheet functions to do the math. But I never would have been able to get that far that fast without starting at the whiteboard.</text><parent_chain><item><author>DigitalSea</author><text>This is ridiculous. I understand Google is a big company and thus needs to implement a concise recruitment process because understandable they get a lot of applicants, but the amount of tests and ways of which you were asked to solve problems is ridiculous.&lt;p&gt;When is the last time you heard of a system administrator writing down problems on a whiteboard as opposed to asking a colleague or Googling the answer? I think the real test after the initial phone call interviews and Google docs one is to sit you down in-front of a computer and make you solve real problems, not theoretical &amp;amp; made-up problems in which they ask you  to solve them in impracticable and unrealistic ways.&lt;p&gt;This is a flaw in the corporate hiring process almost everywhere in the software world. It&amp;#x27;s not the 70&amp;#x27;s any more, people rarely solve problems on whiteboards and paper. They solve them on the computer, sometimes through knowledge and their skill-set and other times through luck and Googling.&lt;p&gt;Don&amp;#x27;t feel too bad for being rejected, it just means something else could come along that&amp;#x27;s better.</text></item></parent_chain></comment><story><title>Recruitment Process for a Google Site Reliability Engineer</title><url>http://blog.lambda-startup.com/2014/03/recruitment-process-for-google-job-sre.html?m=1</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>fourspace</author><text>Former Google SRE here. Trust me, many of the problems we faced were solved on whiteboards, during chats at lunch, or via email. Most of issues we faced were of a class that simply isn&amp;#x27;t covered on basic sites like Stack Overflow.&lt;p&gt;The interview described is pretty much exactly as I remember them. SRE is actually quite difficult to get into, precisely because you need to have fairly deep knowledge on a wide range of topics. The &amp;quot;ways in which you were asked to solve problems&amp;quot; are actually the best way to determine if an application actually knows about what they will need to know.</text><parent_chain><item><author>DigitalSea</author><text>This is ridiculous. I understand Google is a big company and thus needs to implement a concise recruitment process because understandable they get a lot of applicants, but the amount of tests and ways of which you were asked to solve problems is ridiculous.&lt;p&gt;When is the last time you heard of a system administrator writing down problems on a whiteboard as opposed to asking a colleague or Googling the answer? I think the real test after the initial phone call interviews and Google docs one is to sit you down in-front of a computer and make you solve real problems, not theoretical &amp;amp; made-up problems in which they ask you  to solve them in impracticable and unrealistic ways.&lt;p&gt;This is a flaw in the corporate hiring process almost everywhere in the software world. It&amp;#x27;s not the 70&amp;#x27;s any more, people rarely solve problems on whiteboards and paper. They solve them on the computer, sometimes through knowledge and their skill-set and other times through luck and Googling.&lt;p&gt;Don&amp;#x27;t feel too bad for being rejected, it just means something else could come along that&amp;#x27;s better.</text></item></parent_chain></comment><story><title>Recruitment Process for a Google Site Reliability Engineer</title><url>http://blog.lambda-startup.com/2014/03/recruitment-process-for-google-job-sre.html?m=1</url></story>