4 ms·

90% Answers (and when they're wrong)

26 points by MPSimmons 16y ago

gchucky 16y ago
I'm curious now: what would be a more appropriate solution for each of the cases he gave (rsync, and mysqldump on a large database)?
- cagenut 16y ago
  The first one would be hard to do without writing code. Thats probably what the googler intended, but of course not how a sysadmin is going to approach the problem. The second one would be a mix of xtrabackup and/or lvm (or san) snapshots on a slave. I've read this particular guy's blog a bunch of times before (its thin pickings out in the sysadmin blogosphere). His rush to the 90% answer bias is almost certainly a byproduct of his work environment, a small shop where ordering laptops is more a part of his day than performance tuning the website infrastructure. When your job covers a large variety and volume of relatively low-end problems, you would of course develop that reflex.
- JoachimSchipper 16y ago
  I think you could have these solutions when dealing with lots of data, but I'm not an expert in either: MySQL: replicate the database to one or more slaves, and either run mysqldump on a live slave (which should have sufficient capacity, since it's only keeping up with the INSERTs on the master and not handling queries) or take the slave offline, make a backup (EDIT: somehow - I don't really know MySQL all that well) and then make it catch back up (which may not be easy). rsync: sensible people only create paths of the form f/s/myfile if they are expecting a ton of files. In this case, keeping track of file attributes may be extremely valuable (if UNIX ctime hasn't changed, rsync doesn't need to look at the file at all, which saves a lot of disk I/O.) (EDIT:) I just remembered that rsync tries to preserve hard links, too - and therefore remembers the inode of every file. I'm pretty sure that you can run a machine out of memory with enough small files.
wccrawford 16y ago
If these questions are typical of things the company is going to ask you, they're good interview questions. It's obvious they'd need someone that pays better attention to detail than they do. However, if the company has a proper structure in place and actually plans things, maybe those qualities aren't quite as important... And maybe the employees would like it there better. Companies forget that interviews go both ways. If you prove to me in an interview that your company is really messed up, I won't work there. If you take me on a 'lunch interview' and judge me on whether or not I salt my fries before tasting them, I won't work there. That's not a valid test of whether I do proper research or not. It just happens that there is -never- enough salt on fries, so I just add some. And if you make me 'ask for the job' by calling you back and inquiring, even though you stated you would call me, forget it. I don't play games, and I don't understand why you'd want to hire people who do. Since you've made sure to select an entire staff that plays games, I'm sure I don't want to work there. Having said, that if the position he was interviewing for really, really needed to do those 2 tasks on a regular basis, he should have known the best way to handle it and what questions to ask to figure out the proper solution.
- JoachimSchipper 16y ago
  I think part of being a good system administrator is knowing about how far your solutions can be pushed. It's Google; it's not surprising that they want to be sure that you don't reflexively do things that will break at scale.
  - thirdstation 16y ago
    It's unlikely the article's author has ever worked at a scale close to Google's. Without exposure to that world, and the problems you encounter, it would be difficult to give a satisfactory answer. After discovering rsync wouldn't work I would have just said "I don't know, I've never worked at that scale," and reframed the conversation from one where I'm trying to guess the right answer to a conversation with more give-and-take.
    - JoachimSchipper 16y ago
omh 16y ago
Of course the alternative would be a problem as well. If someone comes to me expecting a "90%" answer then they're going to get irritated if my first response is to ask more and more questions. (Unfortunately this is something I often find myself doing!) In an interview though I'd tend to always avoid 90% answers, or to qualify them carefully. I expect interviews to have "trick" questions or to lead on to interesting discussions, so any question with an answer as simple as "use mysqldump" would raise a red flag in my mind.
jellicle 16y ago
What I get from reading that post is that some interviewers are just looking for trouble. If you're going to ask probing questions, you have to probe correctly. Rsync is the correct answer, and mysqldump is the correct answer, for the problems as given. If you want those not to be the correct answer because you're fishing for something else, you have to be specific as to why not: "But suppose the patient has lupus, and that treatment will kill her, what would you do THEN?" These are interviewers that are blowing the setup for their joke and then expecting you to laugh at the punchline. If you're going to be a "smarter-than-thou" interviewer, you have to at least set your questions up properly so that "rsync" and "mysqldump" are not, in fact, the correct answers.
- trafficlight 16y ago
  It's never lupus.
thirdstation 16y ago
Would it be fair to say a 90% answer at a company like Google would be considered a 10% answer everywhere else?
- eitally 16y ago
  Not necessarily. You really need to probe a little bit to understand the context of the question.
mcantor 16y ago
This kind of makes me want to fight fire with fire and return any such question with an exhaustive (and exhausting) list of probes for edge conditions: "How big is the database? What OS are you running? Do you have shell access? How is the database encoded? Are you backing up to the local filesystem or to another database? If another database, is it local or remote? Do you have physical access to the machine? If not, is it a dedicated server or VPS? How close to Daylight Savings Time are you? What is the current phase of the moon? Is the machine currently on fire? Are you grass or rock type pokemon?"
Fluxx 16y ago
Giving the "90% answer" in an interview just shows familiarity with technology platforms/software. Need a web app? Rails. Want a database? MySQL. Need queuing software? AMQP. Version control? Git. And giving these answers in an interview is...alright - you don't want to hire people that aren't familiar with what's happening in technology, but you do want to show that you're somewhat of a critical thinker. Most good developers I know ask tons of questions and say very little. If you can model that thought process during an interview - web app, eh? Does it need to talk to a DB? Are the requests short or long-polling? How are you hosting it? How much view work is there? Will there be an API layer? - that shows you know how to research problems and solve them correctly. This isn't to say I wouldn't hire someone who answered my web app question with a simple, "Rails," but it immediately starts to raise red flags for me.
Timmy_C 16y ago
Where are people applying such that their interviews are riddled with trick questions? The last four job interviews I've landed really just wanted to know if I could do the job and as such, the questions were very straight forward and didn't test for anything that wasn't actually asked in the question. INTERVIEWER: What is your experience with source control systems? ME: I use Git for my personal projects and I have used Subversion and Perforce on professional projects in the past. It's not as if they are trying to tease out how active my Github account is. They just want to know if there is going to be additional ramp-up time if I were to be hired.
bluesnowmonkey 16y ago
> “Oh hey, by the way, what would you use to back up a MySQL database?” “Oh, mysqldump.” In the context of a normal conversation, that is the correct answer. If someone is ignorant enough to ask such a question, they probably have the sort of MySQL instance where mysqldump will perform adequately. If they don't, at least they'll figure it out soon enough. On the other end of the spectrum, you might spend an afternoon holding forth on the merits of various backup strategies only to find out they really just needed the name of the dump command. 90% solutions are good starting points in real life.

26 points by MPSimmons 16y ago

I'm curious now: what would be a more appropriate solution for each of the cases he gave (rsync, and mysqldump on a large database)?

cagenut 16y ago
The first one would be hard to do without writing code. Thats probably what the googler intended, but of course not how a sysadmin is going to approach the problem. The second one would be a mix of xtrabackup and/or lvm (or san) snapshots on a slave. I've read this particular guy's blog a bunch of times before (its thin pickings out in the sysadmin blogosphere). His rush to the 90% answer bias is almost certainly a byproduct of his work environment, a small shop where ordering laptops is more a part of his day than performance tuning the website infrastructure. When your job covers a large variety and volume of relatively low-end problems, you would of course develop that reflex.
JoachimSchipper 16y ago
I think you could have these solutions when dealing with lots of data, but I'm not an expert in either: MySQL: replicate the database to one or more slaves, and either run mysqldump on a live slave (which should have sufficient capacity, since it's only keeping up with the INSERTs on the master and not handling queries) or take the slave offline, make a backup (EDIT: somehow - I don't really know MySQL all that well) and then make it catch back up (which may not be easy). rsync: sensible people only create paths of the form f/s/myfile if they are expecting a ton of files. In this case, keeping track of file attributes may be extremely valuable (if UNIX ctime hasn't changed, rsync doesn't need to look at the file at all, which saves a lot of disk I/O.) (EDIT:) I just remembered that rsync tries to preserve hard links, too - and therefore remembers the inode of every file. I'm pretty sure that you can run a machine out of memory with enough small files.

wccrawford 16y ago

If these questions are typical of things the company is going to ask you, they're good interview questions. It's obvious they'd need someone that pays better attention to detail than they do. However, if the company has a proper structure in place and actually plans things, maybe those qualities aren't quite as important... And maybe the employees would like it there better. Companies forget that interviews go both ways. If you prove to me in an interview that your company is really messed up, I won't work there. If you take me on a 'lunch interview' and judge me on whether or not I salt my fries before tasting them, I won't work there. That's not a valid test of whether I do proper research or not. It just happens that there is -never- enough salt on fries, so I just add some. And if you make me 'ask for the job' by calling you back and inquiring, even though you stated you would call me, forget it. I don't play games, and I don't understand why you'd want to hire people who do. Since you've made sure to select an entire staff that plays games, I'm sure I don't want to work there. Having said, that if the position he was interviewing for really, really needed to do those 2 tasks on a regular basis, he should have known the best way to handle it and what questions to ask to figure out the proper solution.

JoachimSchipper 16y ago
I think part of being a good system administrator is knowing about how far your solutions can be pushed. It's Google; it's not surprising that they want to be sure that you don't reflexively do things that will break at scale.
- thirdstation 16y ago
  It's unlikely the article's author has ever worked at a scale close to Google's. Without exposure to that world, and the problems you encounter, it would be difficult to give a satisfactory answer. After discovering rsync wouldn't work I would have just said "I don't know, I've never worked at that scale," and reframed the conversation from one where I'm trying to guess the right answer to a conversation with more give-and-take.
  - JoachimSchipper 16y ago

omh 16y ago

Of course the alternative would be a problem as well. If someone comes to me expecting a "90%" answer then they're going to get irritated if my first response is to ask more and more questions. (Unfortunately this is something I often find myself doing!) In an interview though I'd tend to always avoid 90% answers, or to qualify them carefully. I expect interviews to have "trick" questions or to lead on to interesting discussions, so any question with an answer as simple as "use mysqldump" would raise a red flag in my mind.

jellicle 16y ago

What I get from reading that post is that some interviewers are just looking for trouble. If you're going to ask probing questions, you have to probe correctly. Rsync is the correct answer, and mysqldump is the correct answer, for the problems as given. If you want those not to be the correct answer because you're fishing for something else, you have to be specific as to why not: "But suppose the patient has lupus, and that treatment will kill her, what would you do THEN?" These are interviewers that are blowing the setup for their joke and then expecting you to laugh at the punchline. If you're going to be a "smarter-than-thou" interviewer, you have to at least set your questions up properly so that "rsync" and "mysqldump" are not, in fact, the correct answers.

trafficlight 16y ago
It's never lupus.

thirdstation 16y ago

Would it be fair to say a 90% answer at a company like Google would be considered a 10% answer everywhere else?

eitally 16y ago
Not necessarily. You really need to probe a little bit to understand the context of the question.

mcantor 16y ago

This kind of makes me want to fight fire with fire and return any such question with an exhaustive (and exhausting) list of probes for edge conditions: "How big is the database? What OS are you running? Do you have shell access? How is the database encoded? Are you backing up to the local filesystem or to another database? If another database, is it local or remote? Do you have physical access to the machine? If not, is it a dedicated server or VPS? How close to Daylight Savings Time are you? What is the current phase of the moon? Is the machine currently on fire? Are you grass or rock type pokemon?"

Fluxx 16y ago

Giving the "90% answer" in an interview just shows familiarity with technology platforms/software. Need a web app? Rails. Want a database? MySQL. Need queuing software? AMQP. Version control? Git. And giving these answers in an interview is...alright - you don't want to hire people that aren't familiar with what's happening in technology, but you do want to show that you're somewhat of a critical thinker. Most good developers I know ask tons of questions and say very little. If you can model that thought process during an interview - web app, eh? Does it need to talk to a DB? Are the requests short or long-polling? How are you hosting it? How much view work is there? Will there be an API layer? - that shows you know how to research problems and solve them correctly. This isn't to say I wouldn't hire someone who answered my web app question with a simple, "Rails," but it immediately starts to raise red flags for me.

Timmy_C 16y ago

Where are people applying such that their interviews are riddled with trick questions? The last four job interviews I've landed really just wanted to know if I could do the job and as such, the questions were very straight forward and didn't test for anything that wasn't actually asked in the question. INTERVIEWER: What is your experience with source control systems? ME: I use Git for my personal projects and I have used Subversion and Perforce on professional projects in the past. It's not as if they are trying to tease out how active my Github account is. They just want to know if there is going to be additional ramp-up time if I were to be hired.

bluesnowmonkey 16y ago

> “Oh hey, by the way, what would you use to back up a MySQL database?” “Oh, mysqldump.” In the context of a normal conversation, that is the correct answer. If someone is ignorant enough to ask such a question, they probably have the sort of MySQL instance where mysqldump will perform adequately. If they don't, at least they'll figure it out soon enough. On the other end of the spectrum, you might spend an afternoon holding forth on the merits of various backup strategies only to find out they really just needed the name of the dump command. 90% solutions are good starting points in real life.