The position I interviewed for was something along the lines of datacenter operations. I did my interview from a local Google sales office and interviewed with three other employees via video call. This was around the time that Skype was fairly new, but whatever software they were using was clearly internal to Google.
Anyway, I ended up talking with 3 engineers. The first one asked me about stuff on my resume, my Linux experience, some hardware, software, and network questions, etc. He seemed pretty nice and I thought that session went well.
The second guy was a different story. It started off well enough but then he asked me how I would go about repairing a server that wouldn't boot. I asked him a few preliminary questions (does it have power, did anyone touch it recently, does it POST, etc) and then talked about which components I would swap out and in what order and why. After every piece of hardware, he would say, "it still doesn't boot, what do you do next?" I ran out of hardware to think of swapping and he eventually got visibly annoyed and began to lecture me on the troubleshooting process. Now, I was young but I wasn't green and probably got flustered and defensive in response. I'm certain that cost me the job or at least my chances of advancing to the next round of interviews.
The next guy I talked to noticed my military record and only wanted to talk about airplanes and helicopters. I humored him while attempting to steer the conversation back to the position but he wasn't having it. I'm sure he knew the previous guy gave me a strike against and was just killing time.
A few days later I got an email from Google saying that they had passed on me. Which as it turns out was probably a good thing because A) Google turned into a much different company in the years following that, and B) they never actually built the datacenter that I would have worked in anyway.
The question server repair question served 2 purposes:
1) can you identify a minimum bootable state / repeatable failure case? Can you think of obscure corner cases like the metal tray that all the components sit on being the problem?
2) How quickly do you give up and ask for help from humans / other sources.
Both were core to the role. Changes in hardware and firmware often resulted in issues needing to be escalated back to manufacturers / internal platform team. The volume/scale of work also meant that being able to concisely convey what you had observed / tested and hypothesised helped the team identify trends / larger issues that were occuring. Datacenter automation and tooling was very much in its infancy.
Around that time, the org was growing rapidly (doubling in size yearly) so most people ended up doing interviews. Not everyone is cut out to interview so sorry if your experience was sucky.
Side note: I once spent most of an interview slot talking to a candidate about snowboarding. Turned out to be one of the best hires we made (thankfully the other interviewers actually asked some role related questions).
Realistically if i was in datacenter ops and a server wouldn't boot i'd unrack it and rack a new one and let the dev/ops whatever team reprovision. Heck, i did this when i was just a cloud engineer, unracked from a local (non-cloud) facility and brought back machines to the office, to be RMA'd, just to help out.
I get the idea that the interviewer had a very specific problem in memory and wanted that answer. After all, if there's some issue with the motherboard, it doesn't matter how many parts you swap out, and an issue with the motherboard could be in the infinite range from "tin whiskers" to "bad capacitor" to "cold solder joint".
A service outage can be a lot more expensive than new hardware costs. The team can troubleshoot the hardware later, offline, when they have time.
He never told me and I was too flustered at the time to ask. Which was agonizing because I replayed that damn interview in my head for weeks afterward wondering where I went wrong. (Aside from slightly losing my cool, obviously.)
I didn't get the sense that the answer he was looking for was, "find someone else who can help," or, "bin the whole server and rack a new one," because I remember it being either stated or strongly implied that the hypothetical server did have some problem that could be resolved by a tech at my level. But I could be mis-remembering things, it was a long time ago.
But like I said, in the end it turned out to be a good thing that I didn't get that particular job. At least the interview itself was a very valuable learning experience and I'm grateful for that.
The process just seemed to be “keep asking what else it could be indefinitely”
Didn’t get it. “Not a cultural fit”, or something. Kinda wished they’d told me more detailed what the problem was.
Near the beginning of a class, Professor Neyman wrote two problems on the blackboard. Dantzig arrived late and assumed that they were a homework assignment.
According to Dantzig, they "seemed to be a little harder than usual", but a few days later he handed in completed solutions for both problems, still believing that they were an assignment that was overdue.
Six weeks later, an excited Neyman eagerly told him that the "homework" problems he had solved were two of the most famous unsolved problems in statistics.
Reminds me of that :)
edit: Here's a slightly more colourful telling of the story: https://www.snopes.com/fact-check/the-unsolvable-math-proble...
Does anyone happen to know which two problems Dantzig solved? Don't seem to be having much luck on my searches
"In 1951, David A. Huffman and his MIT information theory classmates were given the choice of a term paper or a final exam. The professor, Robert M. Fano, assigned a term paper on the problem of finding the most efficient binary code. Huffman, unable to prove any codes were the most efficient, was about to give up and start studying for the final when he hit upon the idea of using a frequency-sorted binary tree and quickly proved this method the most efficient.[5]
In doing so, Huffman outdid Fano, who had worked with Claude Shannon to develop a similar code. Building the tree from the bottom up guaranteed optimality, unlike the top-down approach of Shannon–Fano coding."
When we started grad school, one of the professors introduced themself and said they thought it was interesting that adaptive optics was being used in astronomy and maybe the same idea could be used to improve microscopy and 7 years later a new phd was born doing exactly that!
Over time, some facts were altered, but the basic story persisted in the form of an urban legend and as an introductory scene in the movie Good Will Hunting.
Or perhaps when you don't know it can't (yet) be solved.
Funny as it is, I would like to think that someone famous for his role in the investigation of the Challenger disaster would never flippantly say that a dangerous situation doesn't matter because "people … could easily be trained to do it safely." The fact that people can be trained to do something properly doesn't mean that trained people won't still sometimes do it improperly.
This is giving me vietnam-style university flashbacks.
I am reminded of this Feynman story:
https://longnow.org/essays/richard-feynman-connection-machin...
> The two problems that Dantzig solved were eventually published in: On the Non-Existence of Tests of "Student's" Hypothesis Having Power Functions Independent of σ (1940) and in On the Fundamental Lemma of Neyman and Pearson (1951).
The interviewer responded with "hold on", and grabbed a colleague, pointed at the whiteboard, and the colleague said "yes! that'll fix it!" and ran off.
I was offered the job that I was clearly qualified for, but I declined. I often wondered how many candidates it took them to fix their bug.
You had to solve it on a blackboard, with chalk, and the intent (I later learned) was not necessarily that you got the right answer, but how you worked through it. Did you just lock up? Did you get frustrated? Did you ask the interviewer to clarify with more data? They wanted to see your thought process.
I was able to answer it (not everyone that got hired did), and when I was done, I looked at the interviewer and asked "Do you write code this way, here?". He laughed and said 'no, no no no'. I told him, I wasn't sure I would want to work there if they did. We both laughed. He ended up being my first supervisor at that company.
Hello Dan! (If you happen to read this...)
Out of curiosity, why?
Sometimes I do give candidates examples of real challenges we're facing. The purpose is not to get anything for free, but rather to see if they're good at coming up with new ideas.
It also gets boring asking the same questions that may or may not have leaked to the Internet over and over.
AITA?
It's a real shame in tech with its (past and present) history of open source work and contributions that can be interpreted as such, especially with many projects nowadays being maintained by billion dollar coporations that can certainly pay a candidate for contributions. But that's a huge beast to tackle.
follow up note: I'm not sure if this[0] comment is parody or unironic, but situations like this are exactly what gives the idea such a bad reputation.
Umm, what?
void merge(int* d,int const* a,size_t za,int const* b,size_t zb)
{
size_t zd = za+zb,ia=0,ib=0;
for(size_t i=0; i<zd ;i++)
{
if(ia < za && ib < zb)
{
if(a[ia] < b[ib]) d[i] = a[ia++];
else d[i] = b[ib++];
}
else if(ia < za) d[i] = a[ia++];
else if(ib < zb) d[i] = b[ib++];
else abort(); // should have i==zd now
}
}
void msort(int* d,size_t z,int const* s)
{
if(z==1) *d = *s;
if(z<=1) return;
size_t h = z - (z>>1); // round up
int* x = malloc(h * sizeof *x);
if(!x) abort(); // out of memory
msort(x,h,s+(z-h));
msort(d+h,z-h,s);
merge(d,d+h,z-h,x,h);
}
// not that this is any *good*, but it does *work*
Nah. You only have to remember the central idea (if you have two sorted "runs", you can merge them into a single sorted run). You draw a quick diagram to explain the idea, you go ahead and write code that does it.
Then you apply recursion, and write down the overall algorithm (subdivide into runs until you can use some other method to sort it, then merge recursively).
Bonus points if you can explain the circumstances when this is useful (when you want to sort data that is a lot larger than your main memory, but you can write it on disk or tape). Which is kind of obsolete today, unless you are again dealing with BIG data (everything old is new again...)
When I do come to having to decide on a sorting algorithm, I can refer to the code and algos and then decide. All I need to be able to do is understand the algorithm when I see it not memorize the differences between quick and merge sort. I’m actively working with multiple Olap and regular db solutions and my teams responsible for keeping 100 billion row tables in the most queryable format and it’s never been possible for me to make such a choice, only on whether I use spark or redshift or snowflake. So what exactly would you achieve by asking this question? The irony is I was rejected by 5 companies for not being technical, accepted by 1 where I’ve been thriving for years now at one of the most technical roles in the org.
These "new ideas" are things you should be paying them for.
Any code problems we present to the interview candidate are _clearly_ made-up examples. Though one of them was simplified from a real-world project we had years and years ago.
They shook their heads and admitted that as best as they could tell there wasn't a solution but they wanted to see if they missed anything. I got the job.
Nothing's more interesting than finding out what people are really up to.
Like is the story even true? How would anyone connect the real person to this post? Is anyone even reading this?
Genuinely curious about anyones thoughts here.
It makes it easier to reason about the code. It's the difference between typing out the answer from Stack Overflow, v.s. copy pasting it. At least for me, writing the code down at the speed the candidate does triggers the error checking part of my brain.
It's also easier to write your own notes down this way too.
(Admittedly this is all years before my time.)
Thanks to co-pilot, these are approaching being one and the same (:
But also, it's a basic interview technique to explain your thinking out loud.
As for giving talks that way, I would not say that qualifies as a high stakes environment. Your likely worst case scenario is that either your code or some bit of technology involved doesn't work right, so you laugh it off and explain what was supposed to happen.
The worst case scenario in a talk is that I say something stupid and get really dogmatic and defensive about it, leading the hundreds of people watching the talk to conclude that I'm an ignorant jerk, which, well, I can be, but I'd rather they didn't overestimate the frequency of that! I could lose face.
The worst case scenario in an interview is that the person interviewing me says something stupid and gets really dogmatic and defensive about it, and then they and their company lose face.
Oh, and they could decide not to offer me the job. But that's never been much of a problem, and it's certainly no big deal — if you're only interviewing for jobs you're almost sure to be offered, you should probably interview for more advanced positions. Not being offered a job is far from "losing out on a big opportunity", as you said in your other comment. A job gives you money enough to live on, but if you're a programmer jobs that pay a living wage are plentiful.
(But less plentiful if people go to your talks and decide you're a nincompoop or a scumbag.)
Oh, and if you look like a dogmatic jerk in front of an audience, there's nobody in the back row waiting to make a mark on your permanent record as a result, just so you know.
But, back, now to interviews. I've been in I don't know how many interviews (hundreds, easily, if we count both the ones where I was the interviewer and those where I was the candidate), and I can tell you for a fact that time pressure, performance anxiety, and every single other thing I've mentioned impacts people's interview performance, and does so in such a way that it wouldn't be relevant on the job. I could even cite research to that effect if you like.
For whatever reason, you're now so out of touch that it's absurd. I had a whole point by point refutation of every single thing you wrote here, because for the average individual, it's totally wrong, and it would cause them harm if they tried to incorporate what you wrote into their world view.
Maybe you truly don't feel the same type of anxiety in technical interviewers that most people do. Fine. The fact that you're (a robot, a Zen master, financially secure enough that having a job doesn't matter, a 99th percentile 10x programmer who crushes technical interviews with both hands behind your back and using the whiteboard marker in your teeth, or whatever it is that makes you feel this way makes you not qualified to give advice on the matter to typical, average people.
TL;DR: No. Just no. I can tell you're not going to convince me of anything, and I suspect I can't convince you of anything, either, but my conscience just won't let me let this go unanswered.
It's true that many people get anxious about programming job interviews. Except in rare cases, it isn't really rational. But people get even more anxious about giving public talks, which, as you point out, often isn't rational either.
It's true that people sometimes create artificial time-pressure deadlines. Those people are manipulative schmucks who deserve no quarter. In reality, time to market is a huge competitive advantage, and when a business's site is down it generally loses money every minute; getting it back up allows the business to start making money again. Similar, but worse, when customer systems are broken because your software broke them.
When you're giving a talk at a conference, you're forming part of a community. You have a reputation in that community. That reputation can be good or bad. Having a bad reputation hurts you in myriad ways, even without anyone in the back row making a mark on your permanent record.
You're confusing your limited experience of reality with reality itself, and consequently you come off as dogmatic and defensive, which could limit your learning. I think everyone would benefit from incorporating more aspects of reality into their worldview.
The St. Petersburg game has an infinite expected payout! But most people would only be willing to wager $20 or so, and it's hard to articulate exactly why.
You could ask: You have a 10^-30 chance of winning $10^40, otherwise you'll win $1.
Based on expected utility you should pay a huge sum to play, based on the real world you should pay $1. (Adjust the large numbers as needed if you have an issue that that much money doesn't exist.)
With 75% probability, you make at most 4 dollars. There’s almost a 94% chance you make less than 40 dollars.
As humans, we evaluate improvable events as not mattering so much.
Personally, I would play one time, bet an amount of money I wouldn't be unhappy to lose and continue flipping until I were into 5 digits. On a $10 bet, that would be 10 flips, and I'd have a 1/1024 chance of pulling it off.
Also like outright lying, given what happened next. Not exactly the best company culture.
If I may ask, why in that interview did you just sit there and not ask any questions? I've passed code interviews where I learned an entire new algorithm on the fly (funny how knowing there is an nlogn solution to an n**2 problem can produce workable solutions).
I wasn't silent for half an hour, just for the first couple minutes; but I didn't write any code (which is what the interviewer was pressing me to do).
(Speaking of entirely new algorithms though, there was an interview question which was a thinly disguised 3SUM, and they expected the very obvious N^2 solution; my interviewers were shocked when I pointed out that the way they had structured the problem, the density was high enough to use a convolution and solve it in N log N time.)
Having covered this only a year previously, my answer was that CAP theory stated that this was theoretically impossible. However, their particular actual problem was slightly more relaxed than requiring full consistency, atomicity, and partition-tolerance. The different servers could only perform limited kinds of status transition - there was no transition that could be performed on more than one server, and status transitions were mostly one-way - most of them couldn't be undone. Also, the field only had to be eventually-consistent, and updates didn't need to be ordered. So, I offered them a way to cheat by splitting the status field up into essentially a log of operations, which naturally resolved the conflicts.
I got the job.
The goal is not to see how many algorithms you know. Algorithms are easy to learn on the job.
The goal is to see how you think in a social setting. How you approach a vague, imperfectly stated problem. Do you ask questions to gather more requirements? State assumptions? Then, based on that, how you try to break it down into smaller pieces. Are there different ways to model the problem or lenses you can apply? Can you think of this as a graph? A tree? A database? Can you incorporate ideas from the interviewer on the fly?
The software engineering job is about taking vague problems and turning them into working code with a help of a team, and the interview process is trying emulate that as best as possible under the weird limitations of an interview.
You can pass an interview without getting any of the "answers" "right" and you can fail them even while blasting out perfect algorithms on the whiteboard.
This doesn't totally make sense, most people would have interpreted that to mean they should quit talking and make their best effort to actually write something. It's not at all the same as pretending something works when you know it doesn't in an actual job, it's more like writing what you can on a test and hoping to get some partial credit.
During an interview, the person goes over a problem related to graphs. Then asks me if I could come up with a solution. I told him I had trouble following the details and the interview wasn't long enough for me to both figure that out and solve the problem.
I still got the job. I still don't know why he asked it of me. Eventually I found out that it was an actual problem he was trying to solve for work, and it relied upon a lot of domain specific knowledge that I didn't have at the time.
Because they have to transcribe it anyways, and because it's hard to read blue on white, or green on white in a photo.
Also, if some part of your handwriting is illegible, or you've made some ambiguous errors, or whatever, the interviewer can ask you what you meant, instead of having to make an after-the-fact assumption, long after you've left.
And regardless it was an interview structured with a whiteboard, cameras (digital or not) had been things for a while, the company could gave provided one.
Then you might actually be driving a lambo now too ;)
I don't get why people are so upset at my comment or why that should warrant ad hominem attacks.
I merely mentioned that parent could've had a job at Google and benefited from it. He made it sound like it was a power move, it really wasn't. My argument is only that he took on even more risk by not taking advantage of Google's offer and growing stock prices to fund his passion. He doesn't seem like the type to get distracted by a day job either.
Wouldn't Google then own all the code he wrote, even on his own SaaS sideproject?
It doesn't warrant ad hominem attacks, but hardly anything does.
I don't know what "horizontal" RSUs are, but they were options back then, and every year, you got a bigger (more value) pile of them. My total comp doubled without me getting a promotion in roughly 5 years.
Today: $2500
With that money you could've funded any side project that generates recurring revenue.
I don't get why you should quit your job, take on tremendous amount of risk for a highly improbable outcome with heavy survivorship bias.
For someone like you? I'd say you shouldn't. The correct option for the vast majority of people is to stay at a stable, low risk high paying corporate job and live a comfortable upper-middle class life.
For other people...it's not that much risk if you're good at fundraising, hiring and executing. For those people, the sky is the limit.
Do you know each other or is this a judgement of character based off the few words in the above comments?
What they wrote sounds like good sense in general. A bit materialistic and generalizing perhaps, I wouldn't want a dino juice sapper and I have a lot of trouble doing pointless work let alone outright manipulative like adtech (but that's just me, evidently there's plenty on the other side), but that doesn't mean it wouldn't be generally smart to accept a 4-day work week offer for presumably a high salary in addition to starting something with a high failure chance. But we don't know about savings or aspirations or industry knowledge or investors cperciva might have had, hence it's a bit generalizing, even if it's generally sensible.
> The correct option for the vast majority of people is to stay at a stable, low risk high paying corporate job and live a comfortable upper-middle class life.
Building any size of a durable business is not for everyone. Well-resourced, intelligent, trained people fail for all kinds of reasons, and that's while working on it full-time.
Unless it's not important to you that it ultimately succeeds (and it's essentially a hobby production), eventually, your business will be subject to competition and market pressure -- to gain and retain market share.
What odds do you think you have of building and holding on to that if you're trying to squeeze it into your down time from your full-time job that presumably already requires your full mental energy 40 hours a week? Why put that energy into something that is going to fail in what is ultimately a competitive market? Why not just put those resources into an index fund or real estate?
Until you have significant experience bringing new products to market (and even then), achieving any kind of a durable go to market success with a new one is never trivial, whether you're building a niche product or a venture backed scaler.
It's pretty foolhardy to tell people to go out and gamble and brush off survivorship with vanity. Back to the original parent's comment, they could've easily taken that Google job and continue development of their side project which didn't raise any money and grew organically, anyways.
1) either do a side project purely in the spare time of one's bigco job and surviving
2) go full-time into a company whether one may fail (and ultimately starve) or not
Not everyone is (or should) become a professional social media influencer.
Not everyone is (or should) become a professional musician.
Not everyone is (or should) become a professional basketball player.
Not everyone is (or should) become a professional politician.
Not everyone is (or should) become a professional founder.
But plenty of people do.
What you're talking about as being "so risky" can really be as mundane as becoming a competent mid level manager at a large tech company. One do have to make certain moves in one's career to prepare for management, and there's a certain level of progressive, targeted professional maturation that has to take place before one can be put in charge of others in some kind of a management capacity and not mess the whole thing up completely. But it's ultimately something which can be (and commonly is) trained for. Moreover, it is something most people can accomplish in their lifetime with training -- not that it means it's something most people should do or would enjoy doing.
It can take 6-10 years of practicing how to find and get into the top 1-10% startups to get any good at it. Or to get the skills one would need to run one. Or to find the right colleagues to build a network of peers and mentors one likes.
But if someone puts the full time in and don't get even decent (never mind best in class) results, they probably need to be more patient, and/or they screwed something very specific up, which they could probably fix; it's not because they aren't capable of it.
So it may require a different much more personal playbook than one may be used to, and if one has not fully developed theirs yet, it may seem delusional or unattainable. But much of that, if that's in the case, would be in their head. It would be like saying "I can't be a manager." That's probably not the case. What is likely more the case is "I like being an IC more than a manager" and "I prefer the working environment of established big companies over small startups."
People tend to prefer what they're good at, and they tend to be good at what they prefer. I don't see anything wrong with that.
Eventually I ran out of time, having written no code on the whiteboard. I asked my interviewer "ok so what is the algorithm for solving this" and he admitted that he had no idea.
At the time, I thought he just meant that he had no idea what the solution was; but in hindsight I wonder if the real test was to see if I would crumble under pressure and write code I knew didn't work.
(I got a job offer, but turned it down to start Tarsnap instead.)