Hacker News Reader

Comment by cperciva | Hacker News Reader

When I interviewed at Google in 2006, one of the interviewers asked me to write code for solving a particular problem. I replied along the lines of "ok I need to think about this, it's not obvious how to solve it" and started thinking. Time ticked away. Five minutes. Ten minutes. Fifteen minutes. The interviewer started reminding me that he needed me to write some code and if there wasn't anything for him to copy down into his interview notes I wasn't going to pass the interview. (Why interviewers were all transcribing the whiteboard rather than taking photos I have no clue.)

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.)

View on HN

I interviewed with Google once around the same time frame.

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.

so, what was the answer, from the lecture? what had you missed?

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".

Yep, seems more like a cattle vs. pets question as retold. That may have been a newer concept at the time, so no amount of Socratic reasoning would get you there.

Yes, exactly. If quick obvious troubleshooting isn't making progress immediately, then unrack it is the smart real-world answer, which is different from the fantasy interview-world answer.

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.

> so, what was the answer, from the lecture? what had you missed?

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.

Don't beat yourself up, interviewing is hard, for all parties - usually.

ex-hwops engineer here...

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).

I had a similar interview question at google for about a clients who’s ads didn’t show up or something and I had to troubleshoot.

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.

This story strikes me as pretty funny. As if he might say "damn, I was hoping you knew. We've been working on this one for weeks!"

  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.

https://en.wikipedia.org/wiki/George_Dantzig

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

There's a lesson there too about how solving problems is often easier once you know it can be solved.

> There's a lesson there too about how solving problems is often easier once you know it can be solved.

Or perhaps when you don't know it can't (yet) be solved.

Hah! This reminded me of a similar story:

"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."

https://en.wikipedia.org/wiki/Huffman_coding#History

I took Huffman's class at UCSC and he said he had actually thrown the solution in the garbage before realizing it worked and retrieving it.

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!

When I started reading my brain went straight to Von Neumann. Now I really want to read a fanfic about a story where John Von Neumann is invited to a Google interview.

Maybe not Von Neumann at google, but how about Feynman at Microsoft?

https://sellsbrothers.com/12395

> That statement is a tautology.

This is giving me vietnam-style university flashbacks.

> We are going to recommend you for immediate hiring into the marketing department.

I am reminded of this Feynman story:

https://longnow.org/essays/richard-feynman-connection-machin...

> The people authorized to open manhole covers could easily be trained to do it safely.

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.

  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.

Aha, I thought this sounded familiar...

Carlo Beenakker answered on MathOverflow (https://mathoverflow.net/a/298601):

> 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).

Thank you! Spent more time looking for that than I'm willing to admit

I interviewed for a security position where they asked me an interesting question (I don't exactly remember what it was). After thinking a bit I told them "you don't" — as in there isn't a solution to the problem they posed.

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.

I once walked into an interview where some code was already written on a whiteboard. It was presented to me as a "find the problem with the code" sort of puzzle, and I pointed out the one big logic problem with it's algorithm and wrote a quick fix.

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.

> I was offered the job that I was clearly qualified for, but I declined.

Out of curiosity, why?

Nothing to do with this event, I just had another offer from a company I interviewed at during the same period that was more interesting to me.

Not the OP, but for my money, a company that does that isn't a company to work for. I don't work for free and you shouldn't either.

Honest question: What difference does it make whether you work on a l33tcode question or a real problem in the interview? At least the real problem has a chance of being interesting.

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?

Because you're literally working for them for free.

Leetcode is fine. Once a dude asked me to write out merge sort. Like, I’m not from a CS bg (I suppose that wouldn’t matter). And I literally did look at merge and other sorts two days back. But that didn’t matter, the only way you can write merge sort is if you memorize it (or spend an inordinate amount of time writing sorting algos). I didn’t get that job, but I’ve been monitoring that company and they’re not doing that well anyway. Perhaps a coincidence?

> the only way you can write merge sort is if you memorize it (or spend an inordinate amount of time writing sorting algos)

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*

Are you using a absurdly broad definition of what counts as memorizing something or something?

> the only way you can write merge sort is if you memorize it

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...)

That’s a great question. Thanks for continuing to ask these so I can avoid those orgs.

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.

Giving actual problems during an interview is fine, and I'd actually prefer getting an interview problem that the company is really working on. I think people are just pattern-matching this to the kind of scam where the company farms out their work as multi-hour take-home problems with no intention of actually hiring the candidate afterwards.

I prefer to use real problems with the work that have already been solved. It shows what the day-to-day is like, you know there's at least one solution to the problem, and you aren't asking someone to work for free.

I wouldn't say you are, but some people have been burned by the concept of spec work that employed tricks like this to basically get free brainstorming. In other industries like art it's especially egregious.

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.

[0] https://news.ycombinator.com/item?id=31265554#31266239

> The purpose is not to get anything for free, but rather to see if they're good at coming up with new ideas.

These "new ideas" are things you should be paying them for.

They are so understaffed they need to use interviewees to do their work! Bad news!

Asking an interview candidate to solve an actual problem the business is currently facing is shitty, and I wouldn't want to work for them either.

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.

I had an interview question that dealt with knowing some crazy shit about C data structure layout and pointers and casting. (Embedded development position)

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...)

I once interviewed a guy who was going to work on a different team than mine who, 20 minutes in, I knew he was going to pass everyone's interview. I then proceeded to give him a "take home test" which was actually my project for the sprint, but framed in a generic manner. He was a much better and faster programmer than I, and he completed it beyond my expectations. I made the modifications to make it work with my project and I even received a commendation at the end of the sprint on how clean "my work" was.

You, sir or madam, are an absolutely asshole. I admire your out-of-the-box thinking and your honesty, but I do not admire your natural proclivity towards exploitation.

I'm surprised you'd admit that kind of dishonesty on a public forum.

I wish more people would admit stuff. A lot of accounts are anonymous, and a lot of people have done mildly unethical things at companies.

Nothing's more interesting than finding out what people are really up to.

Lol, as if this would happen: "Hey aren't you that bloodyplonker who told a story about doing something dishonest on a public forum?" "No way I'd hire you!"

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.

This is funny. What was the tst about?

I mean, when you know you're interviewing a Putnam winner, you could try and sneak in some "unsolved problems" ;)

For context:

https://news.ycombinator.com/item?id=35079

> Why interviewers were all transcribing the whiteboard rather than taking photos I have no clue.

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 just because the interviewing tool you have to put your notes into at Google takes text and not pictures :-). The hiring committee will actually look at this, and this is a different person from the interviewer.

Ok, but they were transcribing from the whiteboard onto paper. So everything I wrote must have been transcribed twice before it reached the hiring committee.

2006 was... early. I don't remember when HCs were formed, but there's no way the internal ATS had any level of sophistication, if it even existed then.

(Admittedly this is all years before my time.)

From what the recruiter told me, there was a hiring committee but their recommendations had to be approved by the founders before an offer could go out.

Isn't this a bit of revisionist thinking? I don't know that cameras of that quality were commonplace in 2006. It's not like you could just pull out your iPhone. And most digital cameras weren't much better (i.e. I wouldn't trust being able to read handwriting from their pictures). So then what, you supply each interviewer with a roll of film and a company darkroom?

It's also easier to write your own notes down this way too.

> between typing out the answer from Stack Overflow, v.s. copy pasting it

Thanks to co-pilot, these are approaching being one and the same (:

2006 is ancient history.

But also, it's a basic interview technique to explain your thinking out loud.

Yeah, in my experience this is really what it's all about. Thinking out loud helps them assess how you reason through trade-offs, potential ideas you run through, edge cases you catch, at what stage you catch them and how you go about addressing them etc.

Thinking out-loud also prevents candidates from going completely off the rails. Maybe they missed an important detail or are solving a different problem than what the interviewer intended. These things happen, better to catch them early in the interview.

Wouldn't that fail unless your thinking is as slow as speech?

Not if you can compress your thinking it into something short. Good code interviews test communication skills too.

No, they don't, generally. When was the last time you were required to compose code in a real world situation, in front of someone, while talking through your thought process, all under time pressure and in a high-stakes environment?

Every time I pair program. Also sometimes I've given talks that way. I like it, I guess not everybody does.

You pair program under time pressure similar to interview conditions? Really? I find that hard to believe.

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.

When I'm working on a product I'm under time pressure: we need to get this feature done so we can move on to the next, or we need to fix this bug — possibly the site is down, or the customer's system is compromised, until we get it done. In an interview there's a sort of "pressure" but it's like the pressure of playing a video game or taking a math test or lifting weights: I'm working hard to do my best, but nothing really depends on it. It's just a difficult challenge I'm completing, the only purpose being to see (and, well, show) how well I can complete it.

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.)

You're either missing or conveniently ignoring the fact that almost all deadlines are artificial, and the only thing that happens when they get missed is that someone's quarterly plan doesn't match up to reality. I had a whole bit about that written up in my editor that I decided not to include, but, needless to say, reality disagrees with you here. Software projects are notoriously late, and people generally don't get fired as a result. Your other scenarios of "site down" or "customer system compromised" aren't even examples of time pressure, so I have no idea what you were even getting at.

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.

Since you've interviewed candidates for programming jobs you know that being 99th percentile among them is pretty easy. Just being a programmer is enough. It's easy to exceed 10× zero.

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.

Any time you want to rubber duck because there's a hard problem you can't figure out and talking it through with someone else is useful.

I think you missed the "time pressure" and "high stakes environment" points. I've done plenty of rubber ducking on the job and elsewhere, and not one time have I ever had to solve the problem in 45 minutes, or else lose out on a big opportunity, similar to how an interview would work.

I had something like this too for a quant trading interview. It was one of those problems about flipping a coin, heads doubles your money and tails you lose everything, "how much would you pay to play the game?" If forget the nuance of the question but when I did the math on the whiteboard, the expected value was 1 i.e. the same amount one wagers. At that point I said, "Well, I guess I could pay for the entertainment value... how much do I owe you for this interview?"

That sounds almost like the St. Petersburg Paradox. (But in the paradoxical version, you keep whatever's in the pot; you don't lose everything at the end.)

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.

https://plato.stanford.edu/entries/paradox-stpetersburg/

I don’t think it’s hard to articulate why. The reason why is that expected value places too much emphasis on low probability edge cases.

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.

The math and discussion of infinity in the problem unnecessarily complicate it.

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.)

It's not hard to articulate why: Nearly all the large numbers are beyond what anyone can actually pay. If you assume that the bet pays out at most 4 billion dollars, and simply can't pay more than that, suddenly the expected value is $32, instead of "infinite".

I suspect they were looking for you to do some risk/reward analysis.

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.

Maybe it's just me, but the interviewer not knowing the solution is extremely off putting.

> and if there wasn't anything for him to copy down into his interview notes I wasn't going to pass the interview

Also like outright lying, given what happened next. Not exactly the best company culture.

That's really unprofessional. I've never talked to anybody at Google who administered a "I don't know the algorithm" interview like that. They would have been spanked badly by the interview committee, if repeating this behavior.

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 should have been clearer. After thinking for a bit I did start asking questions, but the interviewer didn't give me any useful information. IIRC I asked if I could assume the problem was small enough that I could just do a brute force search of possible solutions and the answer came back that no, they needed a solution which would work for any size; I know I asked other questions but I can't remember what they were.

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.)

What structure should there be for nlogn solution to be applicable?

The issue isn't structure but rather density. If you have N values ranging from -M to M, the "obvious" solution is O(N^2) and the convolution us O(M log M). So if you have lots of values within a narrow range the convolution wins.

My first job interview out of university, I was asked how to have separate independent database servers, each able to read/write to the same status field, synchronised between them over an unreliable network, with consistent and atomic updates being written by any of the servers.

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.

I think you're operating under a misunderstanding of how these interviews work.

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.

> 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.

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.

Something similar happened in my first job out of college.

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.

> (Why interviewers were all transcribing the whiteboard rather than taking photos I have no clue.)

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.

To be fair, engineers didn't all have smartphones that could take great photos in 2006.

I did a Google interview around then, and the interviewer photographed my code with an ordinary digital camera.

Did anyone have a smartphone that could take great photos in 2006?

Depends what you mean by great, but there were a number of phones with 2-3mp cameras, more than sufficient for a whiteboard.

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.

Nokia 7650 was released in 2002 it had camera, though picture quality is not great.

My Sony Ericsson K750 took pretty nice 1.3 MP photos for the time (launched 2005), it was better than my 1.3 MP Olympus Camedia C-860L from ca five years prior and was my main camera until DSLRs got cheap enough.

Cameras existed before 2006.

Did you talk to the interviewer at all during this? I could see them wanting to know your thought process to solving an unsolveable problem but otherwise this seems a little far fetched. Probably they just really liked you?

I don't think I would have the self confidence to sit there quietly thinking.

The interview with Google is a pretty harrowing test.

What was the problem?

The two aren't mutually exclusive, you could've easily started out with salary + stock options that would've put you in a better position to start a side gig.

Then you might actually be driving a lambo now too ;)

Speaking from experience or from the ass? In my experience a startup is all consuming.

tarsnap is a one man show and he's not building a startup. he could've easily worked at Google, take advantage of the rising stock prices AND continue work on his SaaS. Lot of us do exactly that because it doesn't make sense to leave a good paying job at a large company to take on tremendous risk at as you said, consuming endeavour with small probability of success (+90% failure rate).

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.

Your comment was critical without being in any way helpful, and you tried to defuse it with a smiley.

It doesn't warrant ad hominem attacks, but hardly anything does.

> he could've easily worked at Google, take advantage of the rising stock prices AND continue work on his SaaS.

Wouldn't Google then own all the code he wrote, even on his own SaaS sideproject?

By '06 Google was already public so you weren't going to make life changing, never work again in your life money from stock awards/options. At best you'd be sitting on a decent nest egg that maybe bought you some property or better investments if you were smart (and a $250k supercar is not a smart investment).

if you owned stock options and invested it in Google with portion of your salary going to it, you absolutely would be looking at extreme returns. The power of compounded returns is still not clear to some I see.

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.

> 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.

> For someone like you?

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.

I actually touched on this in my comment. I didn't disagree with you.

> 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.

the small percentage of survivors will lay it out like there's specific sequence of steps but its 1) very tough to find market product fit 2) even if you do, theres no guarantee you will be chosen 3) your immediate circle, your economic class, education, race impact your perceived social credit 4) luck (even all three are met but some still do not "make it"

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.

I think that there is a much deeper track to entrepreneurship than the false, oversimplified binary of

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.

That's definitely not true. Even post-IPO, the stock has had tremendous growth and RSUs are evergreen.

Sure, but it's not the days of coming in as the chef, getting early options and cashing them out after IPO for 26 million dollars: https://searchengineland.com/google-employee-53-charlie-ayer...

This was before Facebook broke the SV no-poaching ring, so the offer probably wasn’t that spectacular. Also, in 2006-2010 any RSU’s would be rather horizontal.

I don't know why people think that the SV no-poaching thing really had a large effect on people hired at Google when it was active. It didn't.

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.

The stock moved horizontally during that time.

yes, but you'd get more stock each year (a larger count). Also the stockw as definitely not "horizontal". Google outperformed the market in each of the tech bursts.

Google IPO: $85

Today: $2500

That has nothing to do with RSU compensation offered in 2006.

Did you start out with the Google salary + stock options, proceed to also start a side gig, and now drive a lambo?

sorta, yes, and yes ;)

Carry on. Congrats, and you've got the right to say that then :)

Reply on news.ycombinator.com