Oollama.ai focuses on making it as easy as possible to run models locally. We aim to provide a seamless experience that feels the same whether you're developing locally or deploying remotely for production.
I've been using a remote ollama server with a local jupyter notebook. The langchain configuration allows me to specify the ollama host. So I can develop locally with remote models. I guess I still don't see the difference. Does lepton decouple the HTTP server from the model backend?
I think all these kinds of papers are very confusing. Comparing RSM (replicated state machine) to Paxos is just like comparing a car to an engine. It makes very little or no sense.
In the original Paxos paper (https://lamport.azurewebsites.net/pubs/paxos-simple.pdf), the part 3 (RSM) is not extensively explained. There are countless ways to use Paxos to implement RSM. Multipaxos/Raft/Epaxos try to fill in that gap.
By any means, Paxos itself is 10x simpler than Raft or whatever. Every time I heard a "distributed system" engineer said Paxos is complicated, I know he/she does not have much experience in the field or at least has never implemented the core consensus part...
Indeed, in the paper they're comparing MultiPaxos to Raft.
EDIT: For others, here's a very comprehensive (as of ~2018) review of Paxos-related distributed consensus algorithms with an exposition for each one: https://vadosware.io/post/paxosmon-gotta-concensus-them-all/ That's 17 in all, excluding the original Paxos paper. IMO, it should be linked anywhere Paxos is discussed. The link has been posted twice before by others on HN, but unfortunately hasn't seen any discussion, perhaps because it speaks for itself.
1. You misunderstood Paxos, probably confused that with RSM. For example, Paxos is just the leader election part of Raft. Superficially, it seems different from Paxos, but it what it is under the surface.
2. You implemented RSM incorrectly, probably missed some important features or optimizations. For example, log compaction, membership reconfiguration, pipeline, back pressure on execution, etc.
It is VERY important to differentiate Paxos and RSM. There are tons of optimizations you can do with RSM. But on consensus, there is ONLY Paxos today. Or you do it wrong or you invite something truly new.
I am sure you know this: both are comparable as a shared log abstraction. Once you have that, the state machine part is trivial. For the replicated shared log abstraction, you need to do the same kind of things in both the Paxos and Raft worlds. The latter is simpler to implement because the paper is written close to an engineer's understanding. i have written several versions of both, in production.
I can't edit my earlier response, but on second thought, we are both right. Is that consensus? :)
I think the difference in our stances arises from the two ways in which the term 'Paxos' is used. In the part-time-parliament paper, the single-decree paxos is the fundamental building block. I'm assuming this is what you think of as Paxos, and you are right in your assertion. It is defined as the fundamental act of consensus.
However, I have always viewed the single-decree protocol as a pedagogical device; a single write-once distributed register is useless in practice, so the multi-decree protocol is where it becomes useful, and to me is the point of the paper. I say this for a few reasons: a) state machine replication has been Lamport's focus since his early papers, including the 'time clocks and ordering' paper. (b) in engineering-oriented papers such as 'paxos made live', 'chubby' and so on, the term is used as a proxy for a replicated log. The reason for the many variants of Paxos is due to the underlying impulse that basic paxos is not sufficient in and of itself. You need some variant of shared log or equivalently, atomic broadcast.
So, we are both right in our ways. We can have consensus, as long as we sacrifice consistency of the definition of 'Paxos' :)
When my classmates were preparing interview coding questions, I was working on a mini TCP implementation and a toy kernel.
AWS rejected me since I failed to write prefect code to traverse a tree in level order. Google did not even give me an interview since I told the campus recruiter I have not prepared for the coding questions.
Then I ended up with an internship at CoreOS and created etcd. I am glad that they did not hire me back then.
Today, I am sure I still cannot pass the coding interview at "Giant Search and Advertising Company", but they run a lot of my code in production :P.
Cynical answer though — Google does not want people like you. They don't want to hire entrepreneurs or inventors. They want people who can churn out code when given specific instructions, and that is what their interview process optimizes for.
This is absolutely true. I work at Giant Search and Advertising Company, and joining was a huge mistake. I thought I would be working interesting technical problems with a high degree of autonomy — instead the work is extremely boring, and you get ahead by playing political games rather than by innovating. I’m one of the rare few here who managed to get through the interview without really preparing.
Before joining, I had endless enthusiasm for computer science and programming. Now I feel so unenthusiastic that I question my future in this industry.
I worked there in the early 2000s. It was fun. Then it wasn't any more. I was much earlier in my career and when I left, having it on my resume meant a lot. Now I've done more and more interesting things. I told the FAANGs, in no unclear terms, I'm not interested. They seem to have gotten the message eventually. I like small companies. You work harder and have a lot more impact. The compensation is good too.
> I like small companies. You work harder and have a lot more impact. The compensation is good too. Leave. The grass is greener.
What small company is regularly paying over $300k+/yr for senior software engineers and paying over $500k/yr for staff+?
The only people I see leaving the big companies are those who already got their riches and/or bought real estate earlier. The rest of us are either tied to them or trying to get in because the real estate market dictates you must earn that income to stick around the bay.
Big +1. Leave the Bay Area. Heck, you could even get a Bay Area job that allows remote and then leave the Bay Area. I worked remote from ATX for 2 years for an SF startup and it was great!
Many of them don't feel particularly smaller, either. I've had literally no desire to move to San Francisco; senior+ jobs here in Boston pay more than enough to comfortably pay a mortgage somewhere nice.
That sucks that you've had that experience, I'm sorry. I hope it's the exception and not the rule. I work on the Advertising part of Giant Search and Advertising, and my experience has been pretty great—indeed, working on interesting problems with a high degree of autonomy. I do need to persuade others of my ideas sometimes, or let them persuade me against them, but this seems like a good thing, and doesn't feel political. Throughout my team and the other teams we work closely with, I find my co-workers and superiors to be thoughtful, smart, open-minded, and really nice to work with.
Some years ago I was unsatisfied with my pay and I accepted the interview of a Giant Search corp, getting to the on-site interview. The lunch with random employees was perhaps the best part of the experience for me, as it became abundantly clear that a good chunk of devs that I had some conversation with outlined in very generic terms the same basic stuff everybody else needs to do in software: maintenance, basic infrastructure, scripts, and so on. Which is, you know, totally expected.
I'm pretty sure that everything is at scale and so on, but I couldn't shake the feeling that up to that point the stuff I would be working on was not on the table and I could be switching from a place where I like what I'm doing [biotech] to just a highly paid but plainly boring SE job.
This curbed my enthusiasm instantly. Up to that point in my career I always considered available positions based on the actual function I would be doing in the company, never vice-versa.
The afternoon sessions didn't work as well, and although I could still have some extra interviews through phone calls I cancelled them a few days afterwards.
I cannot say for sure what did I miss, but I am certainly totally disillusioned for Big Search as a company today due to it's consumer attitude that I no longer wish for a position there.
Having worked on the spend side of things and at high stakes (9 figure budgets), targeting and how to improve it is extremely intellectually stimulating. More than anything else I've done in my career, even. This is especially true when you have constraints, like being in a regulated industry such as legal marketing.
The only problem is that it's hard to command a salary commensurate with how good you are at it unless you're in business for yourself AND the one spending the money.
you try to make people click on ads, selling that as "extremely intellectually stimulating" sounds fancy but all you do is manipulate people and you're nothing more than a marketing guy with fancy tools. Do you really want to spend your career working on that? Why not use your power in some way that it actually helps people, even if that means that you earn a bit less.
I thought that I made it clear that I don't work on this anymore.
Advertising isn't an inherent evil. You find your mechanic, doctor, lawyer, etc because they advertise.
I advertised for one specific company. I worked in an industry that was pretty grey. Some parts of the business were vaguely predatory and others served a great public social need. More importantly, you had to have an actual reason to fill out our forms and follow through with us. We weren't just desperately trying to get any eyeballs. The work that I did very much did help people.
Also you're not going to get much mileage shaming people for what they do for a living. You being reductive doesn't really reflect reality either. I was much more than some marketer and yes, the problems were extremely intellectually stimulating, otherwise I wouldn't have been there.
That's better than I can say for most of the quants I worked with -- they were almost all just in it for the money.
> You find your mechanic, doctor, lawyer, etc because they advertise.
It’s funny you say that, because I found all three literally by looking at reviews and not advertisements. Those 3 categories are perfect examples of industries where referrals are far more reliable than choosing which one had the best ad budget.
A lot of reviews are just forms of advertisements.
Companies pay third parties lots of money to curate their reviews and put them in contact with the reviewer to smooth things over.
I know that because that's the business I work in now.
Companies still have a problem of getting their reviews surfaced to the top of your search. They also have a need to give people the lowest-friction way possible to leave them a positive score when it's the best time in the interaction to do so. There are many large enterprises competing in this space specifically.
The best performing adverts today are ones where you don't even realize you've been marketed to.
If having to reach out to real customers and fix their fuckups until they are happy enough to leave a good review, then I’m completely fine with that level of advertising. That’s just fixing your fuckups until your customers refer you, which is the best thing that you can hope for.
That has no relationship to the paid shitstorm of ads on Google.
Somewhat. A lot of review systems are designed to contact you asking for a review at the exact time you're most likely to leave a good review. The companies then optimize the whole customer interaction around that experience. To actually go back and edit that review when things change isn't always easy.
The overwhelming majority of all other reviews are either the Amazon variety (so a paid endorsement, usually) or from total cranks. People don't really often leave unsolicited reviews.
That's what I hear, but then I see comments from folks like User5283 above. I have the impression it may be changing into something much more similar to a typical corporation after years of avoiding that fate.
Beware though, that he or she used a throwaway. Comments can be made by anyone, also a marketing company contracted by oracle who still want talent and have to shame competitors with better image.
(but the comment did seem legit and it is obvious for posting that anonymous)
There is lots of IT folks around posting or just lurking and it would be very cheap to do some postings on Agenda XY here and there. I doubt it does not get tried.
Unless one takes extraordinary steps to examine what brings truly brings value, most people interview for clones of themselves. Or worse: their idealized self-image.
Google started off with very mathy people, and highly competitive people, and interviewing this way has always worked for them, so why change?
Some people have done internal studies showing how wildly counterproductive their interview process is, and yet it does not change.
I suspect psychological factors are the main reason why this process persists.
Google gets so many applicants it's irrelevant how counterproductive the interview process is. It selects for people similar to the interviewers, but that matters little, since they can afford to say No to 99% of candidates because thousands will still apply.
What boggles my mind is to see the same type of "skill testing" whiteboard coding interviews at smaller companies and startups that pay far less and don't have golden handcuffs to offer.
I've been at Google for 8 years. If I went to one of these smaller companies to interview and they asked me to whiteboard a data structure or algorithm problem I'd just walk out. I'm not the best programmer in the world or particularly shit-hot, but I'm sure there are many that are that would do the same.
Companies copying this process are doing themselves a disservice.
>Google gets so many applicants it's irrelevant how counterproductive the interview process is.
It still may be relevant when you are looking for a specific domain knowledge instead of a generic "programmer". A great example is Amazon Game Studios. They employ the general Amazon hiring process from what I understand yet, as a game studio, it's a complete and utter failure. There are just few thousand experienced game programmers in the whole world and only a fraction of them wants to apply at Amazon at all for different reasons. You cull 99% of them and you are left with inexperienced people who will not be able to learn anything since there is nobody to learn from. Even if few experienced people got through or went around hiring process (e.g. celebrity programmers hired without whiteboarding) they will be in a minority and unable to mentor the rest of the studio. Google and Facebook are spinning up their own game studios and I expect the same result from them.
One thing I wasn't aware as a nerdy teenager was how everything is valued IRL in its guaranteed minimum performance, not conditional maxima.
No one is interested in your peak performance, all it matters is consistency, predictability, stability, those robustness metrics. Say interview questions kinda sucks, but you show some competency still, means predictable most of what they have to throw at you will at least partially stick, minimizing factors.
You could argue that a workplace that prefers a trait like that doesn't sound like a place for artists' dream place we all desire, but more towards a "software manufacturing factory" envisioned by electric companies like Hitachi in the '80s, if you do I think maybe it is and maybe they were right to a certain extent.
I agree that the interview process looks for self clones. I've been in interviews where interviewer was like "why you used Dictionary to do this? Nobody uses dict in prod code"
But unearned privilege seems a little harsh doesn't it?
Now I’m curious why they didn’t use dicts, I love dicts. I’ve been writing Python for a living for almost 15 years now and dictionaries and (reasonable) list comprehensions still attract me like they did the first day I “met” them.
To be honest the lady taking the interview didn't understand my code, at least that's what I got. The guy with her definitely didn't understand a line I had written.
Maybe that was her way of protecting herself or something else
But I've never come across any real reason to not use dicts
Frankly though, I think there's something more fundamental about large organization as to why this sort of stuff happens (not just at companies). Perhaps it's the iron law of oligarchy, but corruption seems inevitable at scale. Very few innovative people seem able to reap or retain the most value of their work.
> Very few innovative people seem able to reap or retain the most value of their work.
Once a company pays you, it's not your work, it's their work. They paid you fair and square.
IMHO a developer need to produce about 10x what's his paid as to cover for the company costs and profits. If one thinks that they can cover those 9 tenths in marketing, office space, infrastructure, admin and legal costs in a more efficient manner, they should quit and start their own company.
They don't own your innovation outright unless that's in your work contract and you haven't negotiated a fairer deal.
And I have no idea where you get your 10X figure from. In fact it's very hard to estimate the specific business value of specific dev work in very large companies, over any time period.
From a high enough level the job becomes "Pay devs to keep the engines running." Unless you're innovating new products/services at a senior level, it's hard to break it down further.
Which is partly why the interview process has become homogenised. Realistically most developers are engine components, not engine designers - although it's easy to be fooled when your component value is process optimisation - and FAANGs have optimised the funnel to select good components.
You need to be senior++ and/or in startup land to be an engine designer - which differs from being a component because it allows independent agency for strategic goal setting, instead of optimisation of tactical implementation.
most groups don’t change until it is obvious to most of them that what is going on is not working.
When most people stop returning Google’s phone calls, so that positions go infilled, then they’ll start talking about change. Right now there’s still enough supply that they don’t have to do anything,
Honestly I don't think it's that cynical - it just makes sense. There are the people who can and will do that stuff - and do it happily - and they would presumably be the easiest to hire as junior devs. Google views it as a stepping stone towards their next product launch, and the programmers see it as a stepping stone to a more enjoyable job.
And then the inventors and entrepreneurs create their own projects, and typically both produce and earn more than they would've at the company.
It kind of works out in everyone's best interest (although I'm sure the Google hiring managers sometimes regret missing out on the guy who invented New Cool Thing, and the guy that invented New Cool Thing is probably still a bit miffed that he couldn't land or get through an interview for a job he/she was clearly qualified for).
> and typically both produce and earn more than they would've at the company.
Eh, there's a lot of us who haven't done great financially but who have written a lot of open source code being run at bigcos. Being an entrepreneur requires another skill set altogether. One that I seem to lack, although I finally have come up with a solid idea in the last year that might get me somewhere whenever I'm ready to make the move.
I'm sure if I spent significant time preparing, I could do well at Google's interview process, and other FAANG companies have tried multiple times to get me to interview (oddly, never Google), but I'm not convinced it's a good idea for me. I've been much happier working for smaller companies. The one time I worked for a large corporation years ago, I was miserable. People say Google is different, but I'm not convinced.
> They want people who can churn out code when given specific instructions, and that is what their interview process optimizes for.
I think the reason is a bit different.
Google is a search engine. It's a company whose success was due to one (or several) but very good algorithm.
That explains everything: why they are so obsessed with algorithms, why they hire so much olympics winners, why they don't care about anything else.
Their code is pretty bad most of the time, they've took beautiful Webkit and turned it into Blink mess. They are all about algorithms, they don't care about code.
And that's a pity that people are copying Google's methodology without understanding why Google is doing so. If you are developing an OS, you'd be better copying Microsoft, which had much of a different approach, nearly without any algorithm questions.
>> They want people who can churn out code when given specific instructions, and that is what their interview process optimizes for.
Somehow I doubt that. Can anyone who actually works at google comment on what it's like? Do people come to you with specific requirement and expect you to crank out code like the interview problems?
I've never worked somewhere where the software folks were actually just coding machines.
Gathering and defining requirements is very much a part of the job. It is entirely unsustainable to rely on others to tell you what to implement in Google.
This is implicit in a coding interview, though. I, the interviewer, take a couple of sentences to describe a problem. What next? Way too often, rather than ask more questions - gather and define requirements - a candidate will launch straight into solving a problem different from the one I am describing.
Requirements gathering in reality can often require more soft skills or political skills, which doesn’t seem to be the primary focus of these interviews. Which isn’t to say the skills you mention aren’t important.
Most engineers at Google never talk to non-engineers, the requirements gathering comes instead from looking at code, reading design docs and talking to other engineers.
>> Gathering and defining requirements is very much a part of the job. It is entirely unsustainable to rely on others to tell you what to implement in Google.
It's like that everywhere. Nobody comes to you with complete requirements. People/customers come with problems they need solved. Sometimes an outline of a specific solution is specified, but there's always a lot of detail missing.
Not at all. I've been at Google for a bit over two years, and my experience has been at the far other end of the spectrum: a lot of autonomy, gathering requirements, designing & implementing. Also I have a fair amount of agency to see something that would make people's lives better and pitch it as a thing I'd like to work on. If it's less than a day or two of work I can generally just go do it.
How much of interview-style coding is involved in your work? More broadly, would you agree to the OP that interviewing for software developers is broken?
What you get told is What needs to be accomplished, but not How, if that makes sense.
E.G. IF you choose to accept this challenge, this platform is running at XX% availability and we need to run it at YY% availability. HOW you get to do that, it's up to you.
Some folks don't accept these challenges and they go and find and fix their own interesting problems. But that's harder because you have to get buy-in from managers in order to get resources for that.
Google's big enough that no one person could possibly speak confidently for all of engineering in this regard.
For what it's worth, this doesn't match my experience at all. In the area I work in (SRE in technical infrastructure, but the same seems to be true for our dev partners), I see a lot of expectation for bottom up ownership. I could totally understand if somebody with a different mindset and perspective (I'm a manager, so I can see pretty clearly what's valued at evaluation time) arrived at a different conclusion.
Right. Coding tests are designed to find people who are happy in a job where their only responsibility is: "Here's your coding assignment. Go do it." Technology companies are overfull of engineers who want more responsibility than that. They don't need any more.
Agree, they want smart workers (well you have to be smart at some degree to do software). And they don't care if they will miss some genius, they just let other companies help the selection process, and if you turn out to be gold, they will pay a big money to get you.
I've read from blog posts and even from conversations that companies require acquihires, particularly non-founder employees, to go through an interview process. It may be shortened, but they still often have to do the typical algorithmic interviews.
I'll see if I can find one of the blog posts I've read about the process.
Note: to be clear, I'm describing the process for acquihires, not founders just wanting to sell their company and walk away with some cash (which actually seems to be somewhat unusual).
Is that a uniquely American thing? I'm 100% certain that even if the company I work for was acquired, my current contract would still apply. So I would need to be given at least 3 months notice, and couldn't be discharged without a good reason - failing some internal interview wouldn't be such a reason.
You could have saved a lot of space just saying button pressers. This is most large companies and why I am burnt out on writing software professionally.
The reasoning for this is the commoditization of software hiring. The idea is to target the median of the bell curve, to lower risks and costs associated with hiring. This targets the greatest quantity of developers in a moment, but it also means the people who play it safe, follow popular trends, and don’t take any risks on product improvements.
To think about it another way the idea is to create mediocre software with mediocre developers because the software is thought to cost less than finding, hiring, and retaining top quality people.
Now connect the dots with: How much customers are willing to pay for software developer work?
They don't want to pay anything. They don't deserve best software written by best developers. Take for example GIT, which is extraordinary piece of software, saves a lot of problems and time. If it was not free, most software shops would just keep copies of folders with dates or whatever insane ways they had (SVN is for me insane way as well :) and big paid VCS were popular at big co's. not even one became close to "industry standard" as GIT).
Makes perfect sense. Thats when you know you need to short the stock in the LONG RUN. Because all they know is taking orders from someone and running it.
This is the same with all companies. If Mark Zuckerberg steps down from Facebook, you can pretty much know, it's going to go down.
That’s a lie they tell employees to make them feel good about themselves. If they actually cared about keeping competent engineers away from competitors, their interview process would be tuned to look for engineering skills, not leetcode.
Straight from the horses mouth I once asked Gayle Lackman on quora: does their exist engineers who no matter how hard they study can NEVER make it through the google interview process? She said yes.
She said that this is because Google optimizes their interviews for IQ. Not just raw knowledge.
That’s incorrect. An interview process with true negatives doesn’t mean it isn’t loaded with tons of other false positives. Being good at leetcode has no relation to engineering skills, despite it being a skill in itself.
Where in my comment do I talk about leetcode or false positives?
Not only are you incorrect, but you are completely off topic.
I am saying Gayle Lackman, the author of Cracking the coding interview and, in the past, one of the board members who decide on candidates in the google interview literally told me word for word that the interview optimizes for IQ. Meaning that there are tons of engineers who can spend a life time studying and never get into google because they are genetically not intelligent enough.
I’m telling you that Gayle is full of shit. They have deluded themselves into thinking they are measuring IQ when they aren’t.
> who can spend a life time studying and never get into google because they are genetically not intelligent enough.
Cool story, but a test that has some true negatives says nothing about its false positive and false negative rate.
Gayle has to convince you that an entire life’s work impacting hundreds of thousands of people’s careers isn’t deeply flawed (because that would reflect pretty poorly on Gayle).
Gayle is the last person you would want to ask if the Google interview process is good. Understand?
Would you ask Donald Trump if his presidential administration is doing well?
>Would you ask Donald Trump if his presidential administration is doing well?
You're absolutely insane if you compare google engineers with the trump administration. Nobody thinks of google engineers like this. Check yourself. Being a google engineer is like getting into stanford or berkeley the prestige is high and I've even asked engineers who've worked in both scrappy startups and google.
The difference to them is night and day; working outside of a google-like company is like dealing with people at a community college... the level of intelligence, work and projects are on a whole different level.
The google interview process is absolutely stellar at creating teams of raw intellectual power. What it is not stellar at is catching all the people who are incredible programmers but bad at whiteboard interviewing... that's it.
> You're absolutely insane if you compare google engineers with the trump administration. Nobody thinks of google engineers like this.
whoosh. Re-read what I said to understand how I didn’t compare anyone to Trump. You never ask someone who is responsible for creating a whole process/team/product for honestly critical info about it. Unless they are willfully malicious (which I doubt Gayle is), they are certainly convinced they’ve been doing the right thing (otherwise they wouldn’t be doing it).
> working outside of a google-like company is like dealing with people at a community college...
Sorry, but whoever you talked to took you for a ride. Most Google engineers are writing glue code and glorified ETL processes. I used to work there, I left because it got way to big an deteriorated quickly and now work at a startup with several employees I personally know took 50% pay cuts by turning town Google offers.
> The google interview process is absolutely stellar at creating teams of raw intellectual power
Not from what I saw from 2012 going forward. It was filled with mediocre devs that wrote lots of bad code, including ones that would slip in quadratic runtime behavior. The only thing Google had going for it is that early on it did attract some brilliant people that believed in the mission and created the stellar infrastructure supporting the masses today.
Do you have any reasonable way to convince me and everyone reading your responses that your opinions are more valid than other people who offer contrary opinions?
Why would someone take a 50% pay cut and turn down a google offer? There has to be a bigger reason than the one you mentioned.
>whoosh. Re-read what I said to understand how I didn’t compare anyone to Trump.
I assumed your analogy was used to state that people at google are incompetent and that those who are incompetent can't recognize their own incompetence. The later part may be true in the context of google but I disagreed with the former. Your reply indicates to me that you in fact don't think much of google engineers and that your comparison of incompetence is apt.
As far as I know Gayle didn't work to create the interview process, she was just part of the board and now she actively works to help people pass it. Saying that there exists many people who can't pass the google interview will harm sales of her book. I believe it is against her incentive to say it and that she only said it because she believe it's the truth. There is no active lying going on here.
Know a few ex coworkers and friends of friend who after multiple failures eventually got accepted.
Their strategy is the same across the board: practice makes perfect (a.k.a leetcode). Don't give up, keep trying.
You are well aware that there's a big industry around interview preps for Hi-Tech BigCos and Gayle herself is one of the implicit founding of this industry right?
Pre-Leetcode/HackerRank the kind of people who got accepted to Google are mostly their kind: ACM/TopCoder and most folks who grew up/go to school in Bay Area because well duh... It's what they do everyday: practicing leetcode style problem solving. The Stanford/UC Berkeley folks got in because well... Interview questions are shared among interns because there's no database like today's LeetCode.
Ironically, the people who are truly of the highest intelligence and skill level would never choose to work at a place like that. So it's fair to say that what they are actually selecting for are people who are smart, but not too smart. Just like cops, really.
You don't have to be mean. Claiming that algorithmic interviews is a proxy for IQ is also probably something that the powers that be at Google "pulled out of their ass". I don't see any data that says it's correlated with standard IQ test scores. I'm skeptical that it is a good proxy since you can specifically study for these interviews. The IQ tests, at least in theory, should be attempted without preparation so as to reflect your "raw ability". Leetcode grind for 3 months is not exactly raw ability.
Not trying to be mean but the fact he made that up out of thin air is not only something that isn't backed with data but something that is intuitively not true. With the reputation and amount of comp google offers there is no reason why intelligent people or less intelligent people would just avoid google. You're assuming only less intelligent people want higher salaries while intelligent people don't which isn't true at all.
>I don't see any data that says it's correlated with standard IQ test scores.
While there's no Data that correlates IQ with algorithm problems. Intuitively the more intelligent you are the better you would be at these algorithm problems.
If IQ measures intelligence and if intelligence determines your ability to perform well on algorithm problems than your performance on these problems correlates with IQ.
To deny the above logic would be to say intelligence has no correlation with IQ and/or algorithms therefore algorithms don't correlate with IQ.
Not every axiom needs to be measured with data. Common sense and intuition also fill the gap where no data exists. Google saying Intelligence correlates with your problem solving abilities and abilities to solve computer science problems is something that absolutely makes sense even if no data to back it exists.
>Leetcode grind for 3 months is not exactly raw ability.
Doesn't matter how long you spend on leetcode. Google will present you with a problem you haven't seen before and there are a huge amount of people who have done leetcode for years and can't pass the interview questions.
If you're a guy who just grinds for 3 months and can suddenly pass the google interview with flying colors than you're the guy that google wants because there are many people who can't do this.
> Doesn't matter how long you spend on leetcode. Google will present you with a problem you haven't seen before and there are a huge amount of people who have done leetcode for years and can't pass the interview questions.
It matters how long you spent time on leetcode/other practices from popular algorithm books (comen, skiena, sedgewick). Source : friends, ex co-workers, and personal experience. Sometimes they just change the "story" questions but the algo and tricks are the same, sometime they took it verbatim from leetcode (or the other way around: someone leaked them to leetcode).
Real Talk tho: Whats the range?
Im ~low 90 percentile and I wonder if I bang my head against the LeetCode wall for a few months, then I too, can get $200K+ and free lunch 4 lyfe.
I largely brushed up on algorithms, though I'd seen most in grad school (which was a while ago). There's a recommended book on algorithms which is very nice (red cover, but can't recall title). Man pages are good, too--one Googler was quite unhappy that I didn't know the 'ps -o' flags off the top of my head.
I actually passed the on-site and hiring committee on my third try, but was (apparently) nixed by some executive, for reasons I can only guess at.
I'm estimating prevalence based on my SAT and GRE scores. As supporting evidence, even colleagues with PhDs often seem not to do as well when mathy sorts of puzzles come up in real life. As often noted, however, that and a dime will get you a cup of coffee.
It might be sour grapes, but lately I've come to appreciate the benefits of being the big fish in a tiny pond, rather than the tiny fish in an ocean I'd be at a FAANG. Money's nice, of course, but in the end you do pay for it, one way or another.
There's a recommended book on algorithms which is very nice (red cover, but can't recall title).
Bit of a tangent, but, for anyone who's interested, I'm guessing the book was Steven Skiena's The Algorithm Design Manual [0], as it is well-regarded and has a red cover.
Also, even more tangentially, there are videos of the author's Algorithms course lectures online from 2012 which I went through once and they were pretty good [1].
(There were one or two that had audio issues or issues seeing what he projected on the screen, but there are multiple years' worth of videos, so you can choose an alternate from an earlier year if necessary and the slides are available there too, so you can follow along with them, if need be; audio-only files are are also available if you want them).
Reading posts like that make the process seem stupid, but it has utility for the interviewers. All of this silliness is creating an artificial talent shortage which drives up salaries at FANG companies.
It’s far from universal, but the incentives between managers, workers, and shareholders never really align that well.
Wow. I don't have as prolific a tale as that, but I'm in the looking stage right now and the idea of cramming for a test I haven't taken in 12 years annoys the hell out of me.
I've done some pretty interesting things in biotech in my career, things that required learning about motion control, digital imaging, signal processing, and biology... but if I want a job as a web dev I apparently need to memorize how to implement every sorting algorithm... on a whiteboard... in ten minutes. The fact that I know which to use when is irrelevant. Bleh.
This is part of the reason why I've only consulted into big companies, and only briefly. It's not just that I am not that sort of person, it's that I don't like being around that sort of person.
Software engineering is also another field where there's no effective upper limit on difficulty. In other words, no matter how good you are you (should) always feel that you're barely capable of understanding what you're supposed to be doing, let alone doing it.
That's right from "make a single static web page" to "submit binary fix to close-source compiler" or whatever the high end of your particular field is (Win a technical argument with the C++ standards committee? Shave 0.001% off the load time of the google homepage? Discover a new way to monetise users?).
Having worked at cutting edge biotech,startups and FAANG I wholeheartedly defend the interview process, and believe you would too if you ever switched over for a while
I think there's a certain breed of people who will pony up the time and resources to levelup for the interview, and the compliment. Ignoring the privilege of resource availability, i think its totally doable and worthwhile. I come from a blue collar family and I think my old man would love to hear I can pull off miraculous study habits for a month to take home the kind of paychecks offered for hitting a keyboard.
Granted, if the money were not there, I would not find it worthwhile. I would probably just focus on founding my own company.
If learning is the naive approach to getting good grades then programming fun projects is the naive approach to passing technical interviews.
"If tests truly were tests of learning, things wouldn't be so bad. Getting good grades and learning would converge, just a little late. The problem is that nearly all tests given to students are terribly hackable. Most people who've gotten good grades know this, and know it so well they've ceased even to question it. You'll see when you realize how naive it sounds to act otherwise."
The greatest programmer I've had the privilege of working closely with could easily pass most technical screens, but he's an odd fellow, and I don't think could handle the stress and anxiety of these crazy interviews. Lots of diamonds in the rough out there, but I suppose large companies understand that and just consider it acceptable loss.
That's what every bitter HN comment on the topic forgets. If Larry Page could sit down and talk to each candidate, I'm sure he'd be able to properly assess these kinds of corner cases. The challenge isn't being able to do that at an individual level; it's being able to do it in a way that's somewhat consistent and scalable across tens of thousands of interviewers and millions of candidates. Any large system is going to have false positives and negatives, and hiring is broken to begin with at most companies (assessing whether someone will be a good employee for the next few years based on a few short meetings is really hard)
That's still waving away the difficulty of taking an entity's goal and losslessly/consistently distributing it into thousands of individuals. It's just not a possible task.
One thing to note about coding interviews, they're very simular to somone looking over your shoulder while you're working.
Nobody can perform well like that.. One great colleague who I wish I was in the interview for, simple started thinking out loud.
Everything he was thinking, he said out loud, and of course, the team loved it. Because thats all it's about.
If its not over a video chat/submission, comment your code your thoughts, remember, they want to know you chain of though, not your knowledge of a framework/algorithm (unless its very specific)
> Today, I am sure I still cannot pass the coding interview
If you know how to figure out the problem, forget the technical side and explain how you would go and figure it out.
So I had an interview that was like that, but I wasn’t given enough information. I was asked to implement the “inverse square law in code” ... and I explained to the interviewer who was two years out of college (I looked up all of the interviewers on linkedin, so I had a good idea of their experience and areas of expertise) that my first step as someone who hadn’t been in an academic environment or exposed to this kind of requirement for over a decade would be to research the requirement and asked if I could consult a Wikipedia article. “No, you can’t consult outside sources.” “Ok, can you explain to me the inverse square law?” “No, you should know this.”
I didn’t know that. Also, I didn’t have enough information to ask good questions, because I was pretty sure that this was an incomplete specification and I needed to ask informed questions to reach a particular implementation.
As a result, the company’s evaluation was that I didn’t know how to code.
> and I explained to the interviewer who was two years out of college
Yeah, that one's easy. Young coder sees a competent, experienced dev and tries to sabotage your interview out of fear you'll show up and make a fool of him. It's possible he was just that arrogant, but it sounds suspicious.
Based on my experience, devs who are 2 years out of college, regardless of how well they understand algos and data structures, are mediocre software engineers. The only exception to that are those devs who have been coding since they were 10 or 12, and who grew up working on actual open source projects (one of my main open source collaborators was like this, and was an excellent dev by age 20). Just growing up coding isn't enough, since you won't have exposure to the actual engineering practices needed for professional developers. And just 4 years of college isn't nearly enough, since you again don't get much exposure to the actual engineering practices needed for professional developers.
Naw, I just shadowed a new young interviewer and he asked a similar question that was unreasonable. As a recent grad he legitimately didn't recognize that the interviewee wouldn't necessarily know this one specific thing. We discussed it and he's going to try again next time with a more reasonable question.
As an active interviewer at Google, I think that person shouldn't be allowed to conduct any more interviews without proper training. That's inexcusable.
What even happened next, did you just end the interview right there? Stare at each other awkwardly till time ran out? How did they expect to learn more about your skills if you weren't doing any coding or talking?
If what you're saying all checks out, someone straight out of college (2 years is young) unless he has been working on those kind of things all the time, its an edge case at best.
The fact that he said : "No, you should know this" - Even if he knew it, it shows how they would be work with. Probably dodged a bullet there.
In years past something like this in an interview would've rattled me. But now that I've been in this biz for 30+ years I think I'd just stand up, look the guy in the eye in a really squinty way and say, "Well, then I think we're done here kid" and walked out. You get to a point where you just won't put up with this kind of bullshit after a while.
I'd ask: if I get a job at your company, will I be not allowed to consult outside sources too? I mean, about half of programmer's work on real projects is googling stuff.
I had a recruiter reach out to me recently about a VP role - when I looked her up on linked in seemed legit. But then in the “people also searched for” section there were all sorts of recruiters that appeared fake. I can’t explain it but just seemed like they weren’t real. In any case this one recruiter told me before they’d talk to me I needed to take a “cognitive” test at a third party site. I get testing... but the whole encounter felt like they were just feeding profiles into a machine.
No interview process is invulnerable to bad faith interviewers. Refusing to help you past roadblocks just makes for a worse interview signal. Maybe the candidate doesn’t know X but has extraordinary depth on Y, and so on. Bad interview training or negligence!
Though what's a bit silly here is that all the information you need is right there in the two words "inverse square", it's only the word "law" tacked on that made you (presumably) assume there had to be more to the concept.
You'd assume a competent enough interviewer wouldn't be so rigid and at least hint that you shouldn't overthink it...
What does it mean to implement it in code though? What kind of data should it consume - n-dimensional coordinates, distance matrices, some sort of power level to calculate falloff? If it’s as described, it’s way too vague. Inverse square laws show up all over.
I did that for an interview for what is now my employer. It was via Skype with a shared code editor. The interviewer asked me to implement a data structure that I had not used (directly—I'm sure plenty of libraries I use utilize it) since college, and I said as much. I told him I was quickly looking it up on Wikipedia, skimmed the article (mumbling to myself, I'm sure), and then proceeded to implement it. My candor and ability to quickly synthesize information on the fly must have reflected well on me, because I ended up getting an offer.
This wasn't at a big name tech company, though. From the sounds of it, most of those places don't give interviewers nearly as much leeway as mine had.
It's certainly true that larger tech companies will not allow much of the 'workflow' into the interview, but this is usually down to the interviewers not being technically sound on the project(s) and most of the time just given a script with certain criterea, who are usually contracted to do so.
This is no fault of those recruiters, just that sometimes they are given very strict guidelines which can hamper creativity within an interview.
My problem I can do this when I'm alone or when it's a real pair coding. During an interview when stress and adrenaline kick in. I'll make a silly mistake and after that, because I'm judged by the other person my brain locks up. I'm feeling like a total fraud.
But the issue is that they're not just judging you by the approach, they are also judging you by your results.
Some people, especially those with social anxiety (not some fancy psychological term, just someone who feels uncomfortable when someone is watching over their shoulder), can only achieve results if they are not judged during the journey.
> AWS rejected me since I failed to write prefect code to traverse a tree in level order.
I hate to break it to you, but Amazon doesn't reject a candidate because he bombed his coding challenge. I know people who received a job offer from Amazon for a developer position although they somewhat bombed their hard skills component. If you were rejected after passing the coding challenge and phone screening interview then odds are you actually bombed their personality and/or soft skills aspect of their interview process.
[Thinking to themselves:] "Is this serf really the right kind of drone, the type who will fit neatly--much like an unthinking cog--into our organizational machinery?"
Maybe he accidentally let it slip that he thought the South should have won and Robert E. Lee had some good ideas.
Yeah, they do weed out racists and misogynists and people who in general have a problem with minorities even if they can traverse a graph like a champ, but as far as I know the main reason why someone is rejected after passing the online test and phone screening is having serious problems with their personality and soft skills that, as a whole, render the candidate unable to improve to an acceptable level and thus are unsalvageable.
I hope the message that people take away from this anecdote is that "even the best people don't always pass an interview at AWS first time". But if someone is interested in the benefits AWS has to offer, try again. I interviewed three times before getting hired there, and I am the happiest I have ever been. I work with great people, on high-stakes, challenging problems that match my strengths, and we work 40 hour weeks, including time for beer. I have enough time outside work to learn new things (this year some basic FPGA programming). And skiing is 90 minutes away.
Getting good signal-to-noise ratio from ANY interview, forget the big cos, is really difficult. I've seen great programmers passed over because they were _not_ given a chance to whiteboard and show their technical skill. At the end of the day, there is a bit of randomness to the process of sizing anyone up in an hour, and people will make bad calls.
That said, I'm skeptical about your particular story. As a process rule, AWS doesn't provide interview feedback, so I'm pretty sure you don't _actually_ know why you were rejected, you can only guess. Perhaps if you were rejected in phone screen(s) it can be obvious, but if you made it to an on-site, I can guarantee (based on experience being in the room during hiring decisions at AWS) that they don't almost someone because of one bad whiteboarding result; there are multiple people collecting and reporting on results and only one person, the bar raiser, has veto power, and I've never seen it used for something as banal as not writing perfect code.
I also don't know what happened in your interview, but consider it's also possible that you completely bombed it: failed to ask questions, failed to communicate properly, or made more mistakes than you even realize.
It's certainly great that you went on to do great things, but maybe at the time you interviewed you weren't yet doing those great things...
To quote Hamming:
"""In science if you know what you are doing you should not be doing it.
In engineering if you do not know what you are doing you should not be doing it."""
It follows that regurgitating answers to already solved problems is good engineering :)
Depends, if he was still working in Big Tech Co, they could have potentially not open sourced it, they could have used his secret sauce to get better system performance compared to competitors.
Google does not want bright, creative people anymore. Google only wants drones now. It's a shift that coincided with its change from a technology company to an advertising company.
True, but its a very technically sound product. Authoring it as an intern cannot be anything but a sign of prodigious skill.
As an amusing anecdote, I didn't drill for internship interviews either and I ended up at a successful startup by sheer luck. I did well there, but I never achieved the level of technical brilliance that OP did.
I feel like there were far more opportunities like this 8 years ago when I was doing that, though.
A company that cannot come up with a better more interesting process isn’t somewhere I want to work.
How about making the questions broad enough for every candidate to have some input and evaluate them on what they choose to focus on? Something like, “How would you design an ATM?”
There should never be a right answer to an interview question, just a candidate that solves problems in a way that fills a gap in your company.
1 is included in at least Google interviews. 3 requires that you hire for a specific tool/language use, most programmers are able to learn new tools and languages in the time time periods that are hired for.
I'd like to do more of 2, understanding, debugging, fixing and refactoring code is, in my experience, more of the day to day work than writing entirely new code. I don't know why this is not typically part of interviewing, maybe there's some reason it doesn't work? It would be interesting to see a more comprehensive evaluation of this approach.
The google interview process was not made to filter you out. It was made to guarantee that they will not make a mistake on hiring you. People with the capability to do those interview problems have a high chance of being good programmers. There are many people like you who can't do those problems but are still very good programmers. Google doesn't need to hire you, the whole interview process is optimized for preventing a bad hire rather than finding people like you who are good hires but can't interview.
Second, traversing a tree in level order is a trivial problem from the interview question perspective. It is more than likely that this question will NOT be given by the interviewer because it is too easy. The interview questions FAANG tends to give are a bit more novel. In fact the method in which you use to solve this problem and the problem itself is often just taught directly in school depending on the class you're in, meaning you don't need to practice interview questions to solve it because it's a basic topic.
The solution is called tree traversal using BFS. If you didn't know this, despite working on and creating things like etcd you will appear stupid because the question is just too basic. When I interview I am 100% expecting questions way harder than this... even on phone interviews. Additionally when I'm the interviewer this type of question is the lowest bar, I will fail someone who can't answer this question.
This is not to comment on your abilities. Rather it is to give you a dose of truth. I truly believe that there are many people like you who can program an entire kernel but can't even solve fibonacci recursively on a white board. Despite this I can't stop judging you based off of the white board question nor do I know how to confirm that you can write a kernel despite lack of ability to solve very very basic programming questions.
I am major in computer science, and published paper in top conference. Tree traversal is trivial for me. So I guess I have decent CS background and knowledge?
Writing bug free and perfect code is not equal to simply solve the problem. If you have prepared coding interviews (especially for new grad and internship), you should understand it is less about knowledge but more about practicing and memorization for that specific purpose. The time spent on it is almost a waste in the future.
If the interview is knowledge based or problem solving oriented, I am all for it. Sadly, it is not today in many places. And that is exactly why website like Leetcode exists.
A published paper in a top conference only happens through political connections in undergrad it is not a marker for your IQ which is what a company like google tests for.
The interview is not just about writing bug free code it is 100% about solving a problem you haven't seen before. Google specifically tells their interviewers to avoid "canned" problems that are already all over the internet.
>If the interview is knowledge based or problem solving oriented, I am all for it. Sadly, it is not today in many places. And that is exactly why website like Leetcode exists.
The interview is about both. You are given a problem that they expect you have not seen before and you are expected to solve that problem using raw knowledge and problem solving skills.
Leetcode isn't about memorization. Leetcode is training data used to optimize your neural net to solve problems it hasn't seen before.
> Google specifically tells their interviewers to avoid "canned" problems that are already all over the internet.
They did a pretty poor job on this already. And it adds one more requirements, the ability to pretend that you have never practiced a similar question before :P.
> Leetcode isn't about memorization. Leetcode is training data used to optimize your neural net to solve problems it hasn't seen before.
Oh. Thanks. Glad that Human brain does not need that much data like today's neural net.
And there are millions of ways to improve problem solving than repeating BSF/DFS/DP templates on Leetcode questions.
>They did a pretty poor job on this already. And it adds one more requirements, the ability to pretend that you have never practiced a similar question before :P.
This is solved by throwing multiple interview questions at the person that are all novel and not derived from the internet. The probability of ALL questions being seened before is very low.
>And there are millions of ways to improve problem solving than repeating BSF/DFS/DP templates on Leetcode questions.
So? Doesn't change the effectiveness of leetcode in passing an interview and displaying your ability to learn and solve novel problems. If you have other ways of passing those interviews outside of leetcode, that's great. Use it.
> This is solved by throwing multiple interview questions at the person that are all novel and not derived from the internet. The probability of ALL questions being seened before is very low.
This is solved by adding more questions into Leetcode. 1000+ and counting.
> So? Doesn't change the effectiveness of leetcode in passing an interview and displaying your ability to learn and solve novel problems. If you have other ways of passing those interviews outside of leetcode, that's great. Use it.
You missed the point entirely. My argument is that many interviews are not designed for problem solving but practicing and memorization. And this is exactly why Leetcode ensures you to repeat these template 100 times effectively.
I do not plan to pass this kinds of interview, before, now or the future. So why do I bother?
Good luck on your job search anyway. I have no intention on discouraging you to do the practice. I cannot fix anything here.
>This is solved by adding more questions into Leetcode. 1000+ and counting.
I know people who did 500 LC problems and couldn't get in google and people who did 20 and got in. The problem set on LC is too large for memorization to work. Google will be giving you problems that aren't on LC and they are actively testing for raw intelligence.
>You missed the point entirely. My argument is that many interviews are not designed for problem solving but practicing and memorization. And this is exactly why Leetcode ensures you to repeat these template 100 times effectively.
No you missed my point. I've talked to those google interviewers, they are not testing your memorization skills that is not their intent. The amount of algorithm problems available in the universe far exceeds that which is available on Leetcode. When you interview at google the questions are designed so that you've never seen any of them before. Get it?
From Gayle Lackman. The test to my knowledge involves both raw intelligence and computer science knowledge.
A lot of startups that forego the whiteboard problem with just a conversational interview or take home problem are putting significant less emphasis on raw intelligence.
Gayle Lackman is lying though. Well that’s a strong word but there really isn’t any other way to put it.
Their interview process does not test intelligence. It may require some intelligence to pass (meeting Gayle’s stupid criteria that “some people are not intelligent enough to pass”), but having a high IQ is not sufficient, nor necessary.
I’ve seen in your other comments that you’ve let them convince you that you are too stupid to hire you. You need to disabuse yourself of that notion because their interview process does not test intelligence, it’s just a heavy algorithms/ds process that allows thousands of mediocre engineers every year into Google’s payroll and rejects an order of magnitude more highly competent engineers that did not have the time and/or motivation to prep leetcode bullshit.
> lot of startups that forego the whiteboard problem with just a conversational interview or take home problem are putting significant less emphasis on raw intelligence.
sigh. I don’t really want to try to spell this out anymore, but a take-home assignment provides you significantly more material to examine someone’s intelligence. The reason Google doesn’t bother is because it takes more time to administer and poor saps are willing to throw themselves at the machine to see if they can slip through. If Google didn’t receive 100x the job applications they required, they would certainly fix their fucked process super quickly.
>I’ve seen in your other comments that you’ve let them convince you that you are too stupid to hire you.
Nobody convinced me. There is a reality here I have to face and more importantly YOU have to face. A lot of people can pass that interview, I can't. The conclusion is unescapable. There are tons of engineers who HAVE practiced leetcode problems who Can't get in. The practice process is not a huge deal, three months of leetcode grind for half a million in TC is worth it, yet this isn't enough to pass for many, many people. No doubt there are tons of people like you who think they are good but can't pass so they blame the google interview process.
>Gayle Lackman is lying though.
Highly, highly unlikely. You have to look at the incentive to lie. For Gayle Lackman, to lie is acting against her incentives. She is no longer employed by FAANG but now promotes her website and book for cracking the interview.
If she says that there are engineers who can never get into google no matter how much they study then her book is useless to a lot of people. Why would she resort to a lie that will decrease sales of her book? She won't. She is not lying, she says something that may decrease sales of her book because she believes it's the truth. You may not agree with what she says but it is highly, highly unlikely that she is lying.
>sigh. I don’t really want to try to spell this out anymore, but a take-home assignment provides you significantly more material to examine someone’s intelligence.
A take home assignment is a highly inaccurate test if raw intelligence is the factor that needs to be measured. First off each interviewee will now have access to unlimited resources and almost an unlimited amount of time. The thing that can't be measured is what resource was used and how much time was used to complete the assignment? Some interviewees used no resources and less time and invented the solution out of thin air, others looked up a way to architect a solution and spent a huge amount of time getting it working. This variability cannot be measured and therefore is a bad measurement.
Even if knowledge and skill is the thing being tested for here, the take home test hides this. Someone may already have the knowledge required to do the take-home test others may not. If both people don't have the knowledge to pass the assignment than you are simply testing their internet search skills.
> 'A published paper in a top conference only happens through political connections in undergrad'
Which fact in and of itself ought to show just how rigged the whole system is--when people can get papers published in prestigious journals merely on the strength of "whom they know."
When interviewing for places like Google and Amazon, your political connections and things like publications/degrees still matter a lot. Good performance on the interviews can be impactful but it's not the only factor. The incredibly biased committees review a lot more than that at google.
Maybe a better way to put it is, the whiteboard problem itself is a pass or fail question and therefore that aspect of the interview by itself is unbiased.
At google some candidates who failed all their interviews were hired because they had connections to upper management.
Here at Amazon, if the candidate knows the hiring manager and interviewers they can be fed all the answers. Not being able to code fizzbuzz doesn't block people from getting 350K+ offers. It's insane. Amazon tried to fix this problem with "bar raisers" but it doesn't work since humans naturally follow the crowd, even if the crowd is corrupt.
> 'I can't stop judging you based off of the white board question nor do I know how to confirm that you can write a kernel despite lack of ability to solve very very basic programming questions.'
You phrased this as two parts, but in reality these two things are intricately linked. It's because you don't know how to judge person on their true ability--i.e. that you lack this skill--that you resort to useless trivialities like this whiteboard bullshit.
Combine survivorship bias (you were subjected to it and made it, so that validates the process) with heavy hive mind group think (We're All Real Smart People, Much Smarter Than Them Masses(TM))--both of which are always in abundance in intelligence-owned front 'companies' like Google, and of course you end up in your present mindset: arrogantly and naively selecting for people exactly like yourself; people who think just enough into things to think you possess a clue, while in reality, being totally oblivious to larger thoughts and concepts.
There are many in this world who just can't stop judging you based on your shortcomings and limitations. For example: your owners.
>Combine survivorship bias (you were subjected to it and made it, so that validates the process)
Let me spell it out for you so that we are on the same page and my Bias is utterly clear:
I Do not have the intellectual ability to make it through the google interview process. I consider myself to be a an excellent coder but I cannot pass their process. I also believe that the majority of programmers at google are smarter than me.
There. This is the ultimate form of unbiased judgement, a judgement that marks yourself as inferior. Google creates interviews I cannot pass, do I use bias to disparage the interview process or do I take a neutral viewpoint even when the neutral viewpoint says something about my own abilities?
If you can't score 200 points on an IQ test, is there something wrong with the IQ test or is it you? Which form of judgement are you taking here and which form of judgment am I taking and who is MORE biased?
If anyone is biased here, it is You.
>You phrased this as two parts, but in reality these two things are intricately linked. It's because you don't know how to judge person on their true ability--i.e. that you lack this skill--that you resort to useless trivialities like this whiteboard bullshit.
You assume that if you wrote what I wrote it would be a form of survivorship bias. This is a common mistake. How you interpret other people is a reflection of your own qualities, weaknesses and biases. You would suffer from survivorship bias if you were in my (perceived) situation and you chose to project that quality onto me even though I am possibly one of the least biased people you could meet.
To be unbiased is to have the ability to swallow uncomfortable truths. You'll know if you're such a person because you'll generally be unhappy. Such an ability is rare. I believe I have it, but make no mistake. It is a curse. The world is a dog eat dog shitty place and most people get through it happily by painting illusions around themselves. To see the world in raw untouched form is to wade through a lake of shit everyday. Better to say the google interview process is dumb than to admit to yourself that you just aren't google material.
You inject many assumptions into what I am saying. What you don't realize that I am in complete agreement with your above statement. Nothing was said to the contrary.
I Don't know how to judge a person's true ability because I lack that skill. I admitted this in the original statement but your blindness completely masked this meaning from you. You aren't hearing what I am really saying:
I am saying that No one has the ability to perfectly judge another persons interview ability. We must use unbiased statistics, metrics and methods of measurement to arrive at a good outcome. There are tons of good programmers out there that can program that can't do whiteboards, but there are much much much much less programmers that can do whiteboards but can't program. Thus if you pass an unbiased coding test that means you have a much much higher chance of being a good coder and possessing genetics that make you more intelligent than the person who couldn't pass it.
This makes the whiteboard interview the Best most unbiased process we have to judge other people. Note that when I say "best" I just mean that it is the best we have despite the fact that it's just not a very accurate way of judging people. Whiteboard interviews aren't that great, it's just better than any other method we have.
Using a conversation or a Design discussion to pass a person in an interview is not a measurable metric. It is subject to all kinds of biases. For example, this very conversational thread you assume that I am a survivor of the google interview process. The conversational format and your biases made you blind. Guess what, if you gave me a whiteboard coding interview, you'd know for sure but you made an assumption and instead wrote a response that demonstrated how completely off base and biased such interview processes without whiteboarding can be.
The most unbiased measurable way to detect if someone can program is to do a whiteboard interview. Most other data in an interview gleaned via conversation is subject to bias
"This makes the whiteboard interview the Best most unbiased process we have to judge other people."
Nonsense. You can just give an SAT style IQ style test loaded with algorithms questions. Far more fair and objective than the biased human interviews we have right now. From my experience on the interviewer side, a lot of good people are rejected due to bad interviewers and the arbitrariness of the process, and many incompetent people are accepted due to the biases of the interviewers. The average Googler isn't as smart as you think. Of course a written IQ test still wouldn't be perfect, but nothing is.
Thanks! never heard of the learner member feature until now. I was asking for an app where most of the nodes are exerting watch operations while only a few other nodes do PUTs due to human intervention. This means that I have a very low write/read ratio. Also I assume that the number of nodes is usually stable so it's not like a very dynamic system where nodes join and leave very frequently. Does this make it easier to have a cluster of 50-100 nodes in different datacenters without breaking etcd down?
The original go-raft is one of the first raft implementations. At that time, the raft paper was not even officially published. Many other attempts around that time were not very successful, including go-raft.
Making a production ready consensus algorithm is not easy: https://www.cs.utexas.edu/users/lorenzo/corsi/cs380d/papers/.... Things like pipelining, batching, flow control, asynchronous snapshot were not extensively explored in the context of raft. And not much effort has been put into testing due to the immaturity of the applications of raft at the time.
We realized the problem a few months after etcd alpha was initially released and became popular. However, I went back to CMU to continue my master degree for 1yr, which slowed down the progress.
After I came back from school, together with Blake, Yicheng from CoreOS and later on Ben from Cockroach Labs, we built a solid raft impl as our first priority. Once we put etcd/raft inside etcd2, the stability of etcd greatly improved. That is about 1.5 yr after the initial release. Now etcd/raft powers many production level distributed systems: tikv, cockroachdb, dgraph and many others.
Over the last couples of years, the focus of etcd/raft is always stability and nothing else (although people are blaming us for usability :P).
If you never work on Unix, then you should insist on saying so. Holding integrity is much more important than getting an internship from FB. And, as an engineer working in the infrastructure space, I do not believe FB is looking for someone has UNIX experience for the internship.
The recruiter is not knowledgeable. If he/she is hiring for production engineering, he/she needs to understand the basic of the keywords they search for. No reason for you to apologize.
declaimer: work at Lepton AI.