Hacker News Reader

Comment by KaeseEs | Hacker News Reader

Perhaps the position they were interviewing you for actually involved writing efficient software, and thus required thorough knowledge of the fundamentals of computer science (data structures and algorithms &c) and systems programming?

View on HN

And certainly your day-to-day work would involve answering questions about those data structures and algorithms in real time, with your future career depending on it, without external references.

If you know something well, you can reason about it in real time.

Pressure is an artifact of the interview process that is controlled primarily by the attitudes of the interviewer and interviewee regardless the subject matter.

External references are useful for things you don't know cold. For something basic and fundamental to your job (eg. basic graph traversals, the suitability of a hash or a balanced BST to some lookup task, etc), you shouldn't need them; for something more arcane which is accidental rather than essential to your task, or something relatively advanced (eg. specifics of tries for incremental string operations), a competent interviewer will help you out and supply some information so that he can evaluate your ability to reason, design and code.

None of these things have any bearing on whether or not it makes sense for Google to focus on knowledge of the fundamentals of computer science and systems programming in their hiring interviews.

I think not. Your day to day work involves sitting in front of an editor of your choice and writing code that may or may not compile or interpret properly, may or may not contain bugs, and may or may not have the correct logic. Simply having a computer at your disposal with the Internet handy, a step debugger, or the ability to run a shell or interpreter in an interactive mode puts you light years ahead of someone struggling in front of a white board trying to remember the arguments and proper order for some obscure function they haven't used in months.

How many people actually solve problems in their day to day jobs without every looking anything up online? Or at least checking to make sure they are correct. Just having a syntax highlighting editor is light years ahead of a white board and dry erase marker.

edit: Sorry, my sarcasm detector doesn't work. I think we're agreeing.

> I think we're agreeing.

Yep. Sorry if my sarcasm broadcaster had a weak signal

SRE (Site Reliability Engineers) according to Tom Limoncelli (a Google's SRE) is a kind of sysadmin, I doubt that this would ever be the case.

Right. I interviewed for SRE at Google. It's basically a sysadmin job. You're expected to be proficient at scripting in some language (Python, Perl, bash, etc), but I would assume you're not expected to write code for most Google applications.

I would think the senior SRE engineers know enough about the code base to poke around and make suggestions ("found a bug in module.py at line XYZ that causes bad performance when thousands of users hit it"), but I got the impression that most of their top developers probably would be bored in SRE.

The thing that is ironic is that most of the people interviewing me were not in SRE, but were pure developers. How many companies do you know that let the developers interview sysadmins? I had guys asking me CompSci questions I hadn't heard since college. If the tables were turned, do you think I'd be asking a prospective developer a question about how to configure DRBD replication and heartbeat from one Linux server to another? Even though some devs might know these things from hobby-like experimentation in their free time, they are not going to be doing it on a day to day basis.

It just strikes me as a very broken interviewing system when you have developers interviewing sysadmins.

An important distinction that's missing in this discussion is that you can be either an SA-SRE or a SWE-SRE. You can figure out which is which from how the SRE job postings on google.com are phrased.

SWE-SREs have to pass SWE interviews. I work down the hall from Tim. Nobody keeps track of who came in through which side (SA or SWE), but some of the SREs I work with wrote large parts of the services they support.

> It just strikes me as a very broken interviewing system when you have developers interviewing sysadmins.

Sounds like your recruiter messed up.

I had the same issue.. was kinda like, wtf..?

And how many systems does a google sysadmin administer? :)

(Answer: a lot.)

Not entirely true. There are two sides to the SRE positions. The sysadmin side is indeed what you say they are, they work on the systems keep them running and do hardware related tasks as well as UNIX level tasks.

The software engineering SRE's work on products to make sure they are ready to scale or if something fails to fix the point of failure. They work alongside the product development teams to make sure the product is stable in production.

The two positions require two different skill-sets (I was interviewed for both sides of SRE). One requires very much computer science, data structures, programming languages, and all of those, the other sysadmin requires more knowledge about Linux, its internals, and the command line interface.

Reply on news.ycombinator.com