Hacker News new | past | comments | ask | show | jobs | submit login
The dystopian world of software engineering interviews (jarednelsen.dev)
1027 points by asangha on Feb 15, 2020 | hide | past | favorite | 811 comments



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.


Hah! Reminds me of https://twitter.com/mxcl/status/608682016205344768.

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.

Leave. The grass is greener.


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


> the real estate market dictates you must earn that income to stick around the bay.

Well, there's your problem right there.

There are plenty of smaller tech hubs around the world.


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!


Hah, same! Love working from in ATX


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.


> I work on the Advertising part of Giant Search and Advertising [...] on interesting problems

Genuine question - what do you consider to be interesting problems in advertising?


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.


"targeting and how to improve it is extremely intellectually stimulating"

I thought the answer to that was a rather bland "by gobbling up even more information about everyone"?


Not all data points are useful. Different pools have different profitability advertised in different ways.

Some highly useful data is hard to get directly or requires significant and/or stealthy spend.


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.


> smooth things over

You mean buying dishonest opinions? Is this supposed to wash "big" advertising innocent? Is this "helping people"?

> The best performing adverts today are ones where you don't even realize you've been marketed to.

And isn't this justifiably what everybody's scared of (and what we should oppose)?


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.


I work on infrastructure. Security, privacy, speed, reliability—all of these are complex challenges, especially at our scale.

And it's a reasonable question. Thanks for asking.


The only interesting problem in advertising - How to part people from their money :P


Move? You got in without preparing. You can make it anywhere. Nothing is more precious than your enthusiasm.


Similar experience and similar feelings here :/


You joined a giant megacorp. They’re all like that. There’s very little difference between Google and Oracle in this regard.


From what I've read, Google is a much more humane and pleasant environment to develop software in.


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)


Yeah, I agree we should be cautious. But it does comport with what I've heard recently from actual Google employees, or (more often) ex-Googlers.


HN doesn't remotely begin to matter enough for companies to waste money on propaganda efforts.


Why do you think that?

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.


That is probably not true, but it's also probably not worth worrying about unless you are an HN mod.


Much higher pay has a tendency to color the everything better


That was a decade ago.


I don’t think there’s any intention to it at all.

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.


> Unearned privilege?

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.


I don't know. It was bizzare to hear it.

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


I took that part out. I don’t really know what is in other people’s minds.


Steve Jobs had a theory about why this type of stuff becomes prevalent in the lifecycle of companies: https://www.businessinsider.com/steve-jobs-on-why-innovation...

Sounds a lot like google here.

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,


> Cynical answer though

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.

I would like that sweet compensation, though.


Don’t forget a lot of entrepreneurs fail until they don’t.


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


Indeed! This cultural / historical angle of looking at the issue hits the nail on the head.


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


How many interviews involve asking the prospective hire if they know how to gather and define requirements?


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.


AKA "rush to keyboard" syndrome.


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


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

You’re clearly not working on their military-contract Terminator-drone program…

…Unless “better” means “stone cold dead”.


Working at Google. My opinion is my own, etc etc

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.

There is space and need for everyone.


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.


And it reminds me of this one too: https://twitter.com/brianacton/status/3109544383

Brian Acton, rejected by Facebook in 2009. Then in 2014 FB acquired his company for $19B...


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.


It is actually pretty well known that the second way into FAANGs is through acquisition.


I've heard of at least some of the FAANGs do the typical interview process for acquisitions.


I can confirm this from personal experience (at least it was the case 10 years ago).


That sounds terrible, can you elaborate?


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

Edit: this was discussed in a similar thread on HN just last year: https://news.ycombinator.com/item?id=18943500


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.


Perhaps. Most places in the US an employment contract can be terminated at will for almost any reason or without any specific reason.


Can also confirm from my own experience 3 years ago


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.


False; Google wants everyone like them to keep them away from the competition.

Edit: it's unfair to single Google out. It's unfortunately the correct game theory and impossible to regulate.


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.

Understand?


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.


https://www.quora.com/What-is-it-like-to-work-at-Google-What...

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 got data to prove that? More than likely you pulled that statement out of your ass.

Some of the smartest people work at google for half a million in TC.


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.


It's just one data point, but I'm well into the 99.9% level and I'm zero for three.


Curious. Did you study LC or algorithms for the interviews? If so how long? Also how was your IQ measured?


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

[0] http://www.algorist.com/

[1] https://www3.cs.stonybrook.edu/~algorith/video-lectures/


>I've come to appreciate the benefits of being the big fish in a tiny pond

Yeah it's like going to an elite university and competing with geniuses. I get it, I think I'm right at that cusp too.


Well..at least you've tried thrice...I still got to go for 1.


Maybe? I'm guessing googlers are more in the 97-98 percentiles.


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


Hi EpicEng,

just out of curiosity to learn more about your project: Where could I contact you?

Cheers!


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 got a job at a FAANG and still think the interviewing is absurd, and Im forced to work with worse people because of it.

No need to imply the OP doesn’t get it just because they’re on the outside of it.


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

http://paulgraham.com/lesson.html


I love these anecdotes, thank you!

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)


> assessing whether someone will be a good employee for the next few years based on a few short meetings is really hard

Predicting the future is very difficult, and therefore probably not what interviews are designed to optimise for.

Interviews probably optimise for something like: The candidate seemed like a reasonable choice at the time / cover-your-arse scenario.


Predicting the future is what you're trying to do when hiring, for which interviews are a specific tool.


There must be people who'd want to specialize in that, though, if it's possible. It sounds like a fun job.


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.

Problem solve. Don't worry.


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.


> “No, you should know this.”

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?


This sounds like bad company practice of hiring..

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.


> “No, you should know this.”

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


One needs a little domain knowledge for "inverse square" to be informative. It is a simple-minded interviewer that wouldn't just explain the concept.

Unless you are hiring someone that is supposed to understand some maths, that is.


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.


Well, yes - I agree.


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.


Which companies are you seeing this from?

This wasn't my experience at any point with Google, Microsoft or AWS


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.


Exactly ! See - https://leetcode.com/discuss/career/509258/Social-anxiety-in...

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.


You've got to admire this well lubricated machine, they are getting the milk and didn't have to pay for the cow.

They are happy. You are happy.

People are jumping higher and higher hoops with a smile.

Everything is for the best in the best of all possible worlds.

Hopefully as a wiser person you have your contingency ready for when the machine come to collect its blood tribute.


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


I'm sure that "Giant Search and Advertising Company" would never hire me. But they did buy patents with my name on them.


I spent my time learning instead of drilling too and don’t regret it. My bank balance does though :(

I want to work for myself however in the long run and I think the skills are more important for that


> but they run a lot of my code in production :P.

We run your code in production too! Thanks!


> Can you regurgitate the answer to this already solved problem?

No, but I can write a storage solution that works even when your dummy engineers are actively melting down servers.

Ah, the difference between "computer science" and "software engineering".


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


So everyone got what they wanted?

You did the project you wanted.

AWS and Google got the code they wanted.

Your friends for the jobs they wanted.


> AWS and Google got the code they wanted.

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.


Google had the equivalent of etcd a long, long time ago.


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.


Was it general and polished enough to get traction though? What’s its name?


Chubby. It was the product that inspired Zookeeper and all its various incarnations, including etcd.


Ah, the attempt to claim credit for something that likely wasn’t inspired by Chubby at all.

etcd was inspired by a hash-map more so than Chubby.


etcd didn’t work initially; I wouldn’t call it polished.

https://aphyr.com/posts/316-call-me-maybe-etcd-and-consul


It worked, it had a bug.


Two questions.

How long do you think it would’ve taken you to prepare and ace these kinds of coding interview questions? (I bet less than 100 hours.)

But I’m more interested in the following: what interview process do you think would have correctly (and reliably) evaluated someone with your profile?


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.


Personally I appreciate the questions that are

1) open ended design questions 2) here's some broken code, fix everything 3) probe depth of understanding of tools/language

I always feel the Algo whiteboard questions feel like a "did you take the same DS class I did" round.


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.


Also after the Redhat and then IBM acquisition I wonder if you came out in a better position in the end anyway.


> When my classmates preparing interview coding questions, I was working on a mini TCP implementation and a toy kernel.

There are plenty of people who do both. They work on their projects, and when needed, they prepare for coding interviews.


Two things.

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.


Thanks for educating me about BFS.

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?


> Google will be giving you problems that aren't on LC and they are actively testing for raw intelligence.

Where did this silly notion come from? If they were testing for “raw intelligence”, you wouldn’t have to have any CS knowledge to pass.


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


It also shows how unrigged the whole google interview process is.

A whiteboard interview is a "Political connection agnostic" interview.


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.


So I guess you’ve never seen someone being fed an answer during an interview.

Trust me, it happens for certain applicants.


You've seen this at Google or faang?


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.


True but, there's a pass or fail element to the whiteboard interview.

I'm mostly arguing that some form of quantitative metric is better than a conversation.

The place with the most leakage is architectural interviews.


Lol that’s amazing, you should write an article on this


A few months ago I interviewed with Major CDN Company for a front-end dev position. They sent me a take-home React/NextJS project stub with dependencies and such already defined, and instructions to finish building out the full app. "Perfect!", I thought. No stage pressure, plenty of opportunities for going an extra mile. They encouraged me to get creative and I did; it met all the requirements and then some. I proudly submitted it.

A few days later I got an email saying, "Sorry, we're going to pass. The feedback from the person who reviewed it said that, 'It crashed with res.flat() is not defined when we tried to run it'".

"That's weird", I thought. I assumed they were running it in a different browser that lacked Array.flat(). Annoying, but maybe browser compatibility was part of the test (it hadn't been stated as such). So I did some digging just to be sure; I asked what version of NodeJS they were using. Version 10. Turns out that version of Node is somewhat old and doesn't have flat(). Huh. Dug some more.

.flat() wasn't even called in my code.

The stack trace went down into NextJS itself. They had given me a project with a particular dependency declared and then run it in an environment which was incompatible with that dependency, and then immediately punted it without any further debugging. I tried to engage my contact via email, presenting the proof that it wasn't my fault. I got an icy "Thanks for your feedback, we'll forward it to our hiring team", followed by silence.


It's hilarious, but I think you dodged a bullet. Imagine for a minute actually working there.


My (somewhat charitable) interpretation was that either:

- The position had already been filled and they didn't want to bother fully informing me

- Both my contact and the person who "reviewed" my submission just really didn't care at all about the process and/or felt their time was better spent writing code than doing hiring (both people were technical)

For what it's worth, this was actually the second time I'd interviewed at this company, and the first time - while I didn't get the job - I went all the way through to the final interview and everyone I met was perfectly reasonable and nice.

Just reinforces the point from the article: an enormous factor in these processes is what kind of person you happen to be randomly assigned to on the other side. So don't take the results too seriously.


You need to be considered for sainthood, with how charitable you’re being here. It’s also possible for interviewers to just be wrong and incapable of seeing it, like the one who misjudged the runtime of code that I wrote and didn’t even have the toolbox to resolve such a disagreement.

https://www.reddit.com/r/cscareerquestions/comments/1ilh7o/w...


Technically, your code runs in O(n^2), as O(n) is a part of O(n^2). Still, he should have accepted the more precise answer O(n).


> (both people were technical)

Well, they might have claimed that but based on your account I'm having my doubts.

On a more serious note, I do find the attitude towards hiring in many companies perverse. I realise it can be time-consuming, frustrating, and draining, but at the same time it's hugely important.

Of all my responsibilities, Literally the most important is building a strong team: hiring is a critical component of that. We're always looking for ways to improve the experience for candidates, and I'm still involved in interviewing fairly regularly. I feel like it's important for me to set that example.

As with many things, if you're hiring and want to enjoy the results of making great hires, you have to learn to love the process somewhat.


Thank you for this follow up comment.


To be honest I never understood this logic. Clearly a firm's skill at interviewing might diverge from their ability to mentor, innovate, have a great engineering culture and so on? Sure - perhaps it's slightly less likely, but it's not at all obvious that interviewing skill and company excellence are 100% convergent.


Well, from this example, management side was unwilling to even invest time in exploring or acknowledging the idea that they might be wrong. I don't know about you but I don't want to work with people who you can't have a reasonable conversation with to get to the bottom of a problem and figure out the issues together. Everyone makes mistakes, sorting them out together and achieving mutual goals is what makes this sort of work bearable.

If management doesn't understand collaborative working environments, humility, and basic problem solving, I don't (and will not) work with them.


They might not even have reached the management team... who knows if the recruiter passed this on or not.


If you have ever been in a situation where things were done to a standard of excellence, this type of excuse is simply unacceptable. People who have first-hand experience with environments that pursue excellence in earnest have little patience for such nonsense.

Kind of like the movie line "Failure is not an option." The line involves a bit of creative license, but was based on the movie people interviewing someone from NASA.

https://www.youtube.com/watch?v=Tid44iy6Rjs

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


I wasn’t implying that it was ok... just that it might not be the hiring managers doing the ignoring.


Sounds like poor internal communication structure to me then.

If the recruiter is from a third party it's a bit more forgivable (though I have gripes about this approach in general). I'd contact the company directly if I was working through a third party that stonewalled me. It's usually pretty easy to find recruiters public facing profiles to figure out how closely (if at all) they're connected to a given business.


This was definitely true at a past job which happened to be a fantastic place to work. The HR recruiting team was well-liked by the executives and run by a founding member of the company (so had a lot of power and autonomy). But they absolutely tormented us with things like not telling us a candidate had canceled until right before the scheduled time (we could find their emails in the recruiting software from hours or days earlier), scheduling individuals for multiple interviews simultaneously because they didn't care about our time so put it on us to find someone else to help, and occasionally forgetting to book a conference room forcing us to scramble and generally look bad.

The only satisfaction we got from the whole situation was reading the furious reviews the candidates would write on glassdoor.


I once worked at a company where hr would go for months saying there are zero candidates for x position. I finally escalated and got access to the database and there were loads of candidates. The issue was they were purposefully holding my req because they were sorting out a budget issue in another department. Even after that got resolved I literally had to go into the database, read them all, and then say this person, that person, etc..completely useless.


No, but their skill at being inconsiderate assholes almost certainly transcends the interview process as well as their engineering process. It likely permeates their whole organization. That's what I think the interviewee is looking at in this case and that's what was found. Unfortunately, fixing inconsiderate asshole syndrome is close to impossible. I wouldn't want to work at a place filled with them as described by this interviewee's experience above.


My opinion is based more on the final sentence than on the borked exercise.

Everyone makes mistakes. Character is revealed in how one handles it when the mistake is pointed out in good faith by a party who has a perfectly legitimate reason to do so.


If someone giving you an interview problem isn’t mortified that the entire premise of their result is invalid because they didn’t even bother testing the code, I would not want to work with them.


Yes, its a blessing in disguise to fail the interview at such a company, but it is kafqaesque, infuriating and leaves a bad taste. But I agree that’s the best way to think about it.


To look at another way, you would immediately be the domain expert and go-to person!


That's not how toxic environments work. They typically want your head on a platter for outshining the people already in power.


I remember once interviewing for a startup my friend was working at because I wanted to work with said friend. It was mainly a PHP/Laravel job, but I didn't care. I had a high opinion of said friend and stacks are just tools to me -- you can do good work in just about anything.

Go in for the in-person interview which goes extremely well, but talking to their two most senior engineers it seemed like they had just recently learned what OOP is and "drunk the Kool Aid". I found this extremely odd given that this was well into the 2010s already.

They gave me a take-home exercise which was basically to implement some feature with Laravel using established best practices. I turn in something that's clean, documented, with tests, using the documented best practices (like literally from the Laravel docs), and extremely performant (would scale to a high volume of requests). Functional style though, broken out into 1-3 line functions that only do one thing -- similar to what you'd expect from a Rubyist.

Rejected and they told my friend that I don't know how to code. My friend knew better and got a new job himself a month later and I went on to much better things.


" Functional style though, broken out into 1-3 line functions that only do one thing -- similar to what you'd expect from a Rubyist."

I'm pretty laid back generally and I'm willing to overlook many things, but I think this is one of those where I'd vote against hiring, since I'd never want to maintain such code. Following the logic of algorithms would be for instance really hard because of having to jump around all the time.


That's not how that works out in practice though. When each function does one thing, the cognitive load is low and you name things appropriately that make understanding each function on its own easy. You can scan an area of code quickly and find problems without having to build the whole house again in your brain.

It's much clearer when you hit some unintended edge case then having to maintain a mental model of a huge function doing a lot of things.

If your way of grading someone's code is to make sure you can build the whole house in your head, rather than have an exhaustive set of test cases to validate your specification and a simple "each function is appropriately named and does exactly what's intended in the correct manner", then the grading method is the problem, not the code.


You're talking about something different now though: initially you were mentioning functions that are 1-3 lines in size, but now you're describing functions which do one thing, without talking about the size at all. I was very specifically criticizing tiny functions. There are two big issues with such functions:

* the overhead in LoC of declaring and defining the function is between 30-100% of the function body!

* like I previously said following even simple logic becomes an exercise in jumping around the code. Never mind the whole house, even a simple loop barely fits into a 1-3 lines function.


I had literally said "that do only one thing" in the section that you'd quoted.

I've always been talking about that.

LoC aren't a metric. We're not getting paid per line and we're not playing code golf either. It works, it passes tests and most importantly, it's easy to change.

As for the comment about loops, both the languages I mentioned have powerful map functions. The goal of keeping the functions small is to avoid nesting loops and heavy amounts of indentation.


You said you broke your code in functions of 1-3 lines, I offered an explanation why that may have not been well received in your interview. I understand that you don't agree with that and that's fine with me.


Yes, spaghetti-code is much better! /s

> Following the logic

That's what names are for. I prefer to find _afterLeft_ spread all over the place rather than `x2<=x1` even if it actually increases code size by 50%. I can validate it only once, and if I stumble upon _aboveBottom_ I don't even need to validate it to infer what it means (left as an exercise for the reader).

This spaghetti line: `x2<=x1&&x1+w1<=x2+w2&&y2<=y1&&y1+h1<=y2+h2`, in my opinion, is much harder than `inside`.


x2 <= x1 is actually a one liner which could arguably be transformed into a one line function. OP was talking about splitting an entire program into 1-3 line functions, or at least that's how their sentence reads to me.


I, too, would rather maintain spaghetti code contained in thousands of huge classes all over the code base.


Speak for yourself most esteemed master of fish. Plenty of code bases are thankfully neither spaghetti nor ravioli.


Haha, this mirrors my experience - once I was asked to write some embedded hardware driver, which required to run it under the RTOS in emulator, which they failed to run. They failed to run a simple qemu! I even provided them a shellscript to copy and run the required stuff. Surprisingly, I was hired nevertheless, because code "made sense", but still. I can imagine it's ubiquitous nowadays. Too many incompetent people decide on how to choose among competent people.


This sounds like a PM was hiring a dev to implement a feature the PM was responsible for.


My company does a takehome project, but are completely understanding if dependencies don't work on different systems.

Basically, if the code looks right and you can show it working on your system, we're pretty understanding. The goal of a takehome isn't perfection - it's to demonstrate underlying abilities.


I failed a hiring code assignment because I didn’t provide a unit test. They didn’t ask for unit tests. I did provide various data samples to provide various end-to-end tests with documentation.

Now I abandon any interview that requires a code assignment. I have better things to do than mind reading or dicking around with subjective code style nonsense. If they are taking this seriously they will provide their grading criteria along with the assignment text.


unlucky! The buddha said we are promised two certain things in life: suffering and death. Everything else is a bonus.


Ben Franklin paraphrased: “the only things that are certain are death and taxes”.


I bet hes rolling in his grave at what Amazon pays in taxes


They definitely did you a favor.

You have demonstrated solid debugging skills and stated your case. That's usually harder to find than someone who can churn out code based on simple and well-defined specs. Because that's the easy part.


They probably assumed someone else did the debugging. People assume the worst in these situations because they haven’t bothered to learn about the person.


Why would they assume that?


I’m guess that’s the reason they never got back to him.


Right, you said that, but why would they assume some random third person tracked down the dependency?


Good grief man... I’m saying they assumed the candidate phoned a friend for the answer and then fed it back as his own to save his application. I honestly have no idea what happened, no one does... but generally there are no do overs and that kind of sucks given he figured out why they weren’t able to run his code.


What are you basing that on? It seems like you made it up out of nowhere.


I think the situation was unwinnable. You've exposed their incompetence. Rightly or wrongly, most people can't stand being criticized. If there's a solution to that one it's a diplomatic one, not a technical one.

Be similarly wary to point out bugs in code reviewer's code. Unless you have a healthy professional atmosphere and multiple reviewers, your best course is to manipulate the reviewer into "coming up" with the idea for the bugfix from your ticket.


[flagged]


Life is not superhero movie and you have to deal with assholes on a daily basis. You can get away with what you're proposing if you already have an escape plan (another workplace). If they're your coworkers, following your first gut instict is bad.


Grr! That's how you should be interviewed, but then they fscked it up at the end. How frustrating.


That's hilarious


Are you still looking for a FE role in the CDN industry?


Nice work, I learned just from your post.


In my personal experience, having interviewed dozens of candidates (data science), I believe that asking "easy" and "simple" questions is the most effective way to probe the problem-solving skills of a candidate. Fun and interesting solutions to easy questions are hallmarks of great individuals.

The question would go like this:

Suppose I have a column-oriented file and I want to print out a column in a reverse-sorted order. How could I go about it?

This question is among the most effective ever. First it filters out the FizzBuzz failures right away, let's you see immediately how people think (does the candidate want to code it up or understands that they could do: cut | sort| head)? It lets you explore the various aspects of sorting numerical, alphabetical, different locales, in numerical you can have generic numerical sort etc. Then what if the file is really large, now a much better approach could be to split sort then merge sort back into one file.

everyone with real work experience has a story about sorting.

but then you can move on, let's do it in your favorite programming language, then explore of what if the data is "infinite" long, a stream ... and so on

it is a topic that can produce very interesting solutions, nobody is stressed out, and people that "fail" do understand why.

Edit: I will also say I feel that I can learn more about a person based on how they respond to easy questions. Are they cocky, are they showing off, are they rattled etc.


I feel the need to nitpick your example.

> does the candidate want to code it up or understands that they could do: cut | sort| head

Piping together commands is undoubtedly programming, just in ancient shell script. So in a sense you're really testing for bash expertise. Which is maybe really relevant to you but I wouldn't say you're really "avoiding" coding by knowing to use those commands together, you just decided to code it with obscure shell commands. I might fail your test by choosing to write that sort of thing in python, because I could write it much more reliably in 10 minutes than deal with all the incredibly weird things that can happen in bash. I mean the final product in bash might be slightly more elegant, but your terminal history is probably littered with "man cut" and various attempts at it.

But for your example, my answer might be: if you're querying this file once, you may be querying it again, it's probably just way simpler to load the thing into sqlite instead of trying to imitate sql with some janky unix commands.

> everyone with real work experience has a story about sorting.

I am 34 and an experienced coder and I literally have no stories about sorting, and I've never once wanted to sort a CSV file on the terminal.


sqlite answer - excellent, that is exactly what I am looking for, things people did, potential solutions let me understand the candidate's real background - not the buzzwords

what is not well received is the judgmental tone, passing judgment about me for things you cannot possibly know, no need for that either, simple questions also irritate some, very important to weed those people out too,

I expect you would fail the test because of the attitude, even though if this were a real job interview you'd do your best to suppress it, it would come out


Dear God, I hope you don't do interviews. Talking about the "attitude" of someone you don't know, taking criticism personally, thinking that you are weeding people out by trying to "irritate some", suggesting they are trying to suppress it, and (of course) that you will be detect it. Every thread on hiring about HN has these weird passive-aggressive interviewers...interviewing is hard, it is really something that people should be trained to do (and some people really won't ever be able to do it).


>what is not well received is the judgmental tone, passing judgment about me for things you cannot possibly know

But this is the irony---a job interview is a judgment. Why do you think feelings on this run so high?


I expect you would fail the test because of the attitude

How is this relevant? Now you're just taking cheap shots.


I don't get it, honestly.

I would not recommend a candidate, who, when asked if they could do this with cut|sort|head would reply something like:

heh, what a pathetic question, I bet your history is full of "man cut"

it is not the right answer, it is needlessly obnoxious and indicates a person that can barely bottle up their emotions and quickly gives in under pressure. Usually not a good match to any team - unless they also bring in something massively beneficial.


Culture fit. Is the candidate likely to reject/scoff at certain tasks because they think it's below them?


"it appears you're implicitly looking for bash knowledge, which is unfair".

"I wouldn't hire you with that attitude"

I'm getting more judgemental vibes from interviewer than interviewee.


I do believe overgard was just making a point and not expecting a job offer from you. I find these "I'd never hire you" comments so obnoxious... At least you could tell us where you work and your name so we could ask for another interviewer if we ever apply there :-)


Whew, My first thought was import the thing to database, use database engine to sort.


I was with you until you called unix tools janky.. how dare you! semi joking :]

there is some simple elegance and power to these old C tools


> I am 34 and an experienced coder and I literally have no stories about sorting, and I've never once wanted to sort a CSV file on the terminal.

I'm a bit younger, but have done this dozens and dozens of times.

----

A lot of one off processes are way easier to handle with a bunch of terminal commands and pipes.


Only if you do them often enough that you don’t forget the flags each time.


Dude, do you even data science?

Not knowing Unix tools like cut and sort is a hard fail on a senior individual contributor in data science role, as is using sqlite which totally doesn't scale the way sort and cut does. Separates sheep from goats in data science land. You should really learn them if you're in the field and work with reasonably big data sets. Frankly you should learn them if you work with data at all, ever.

I've literally seen FAANGs recommendation engines powered with these tools running nightly on someone's desktop.


Well, they do work, but streaming processing in Python is not difficult and it’s much easier to have graceful failure processing and self-documenting code. Not to say of extending the logic if it would ever be needed.

But maybe that’s more about separating sheep from shepherds.


I’m not sure if I should be horrified or not. Both by the fact this happens, and by the fact that you seem proud of it.

Learning sort and cut takes literally takes all of 10 minutes, so if it makes you pass over an otherwise qualified candidate you have your priorities completely backwards.


Feel free to be horrified: a data scientist who doesn't understand where and why to use unix command line tools for data preparation and ETL is about as useful to me as one who doesn't understand the conditions where a t-test breaks down or what a ROC curve is.

Generally speaking, people like this have never actually dealt with large data sets, never dealt with issues involved with installing "unapproved software" on a machine (ridiculously common in The Real World), has probably never cleaned a dirty data set (what do you do when your giant csv is formatted in a way that Wes McKinney didn't think of?), and will in a senior role be a long term liability for a data science team that works on serious problems. Sure at one point I didn't know about them either: I wasn't a senior data scientist then. I submit that if you don't know about them and haven't actually used them, you aren't either.


I think that the people not being impressed by cut and sort are approaching this from the Linux end of things, where those tools are nothing special at all. I guess we kind of expected that the data science wizards would be using fancier tools.


Yeah, well, people who have enough self regard to think of themselves as "wizards" are super unlikely to be able to actually do the day to day grind of getting, cleaning and preparing data for feature generation, which is about 95% of the job.

Another good weeder for a person claiming to be senior: discuss how you would fix the performance of the default R naive Bayes implementation in e1071. It's numerically more or less correct, but written by deranged ape-men who don't understand how computers work (a problem in a lot of the R ecosystem; in the Python ecosystem, the problem is nobody has yet written algorithms for X, which ends up being a very similar problem: aka it's your job to code up sane algorithms).


So I think this is a perfect example of what happens in tech interviews.

OP is using knowledge of a specific technology as a heuristic for "has experience in role x"

But this always makes me wonder, couldn't you see that experience from a resume? If the candidate filled a data science role at somewhere reputable for 3 years, and you verify that they successfully filled that role, why rely on that heuristic?

As you say testing for the specific technology, when it can be learnt in 10 minutes, does not seem logical.


Don't worry, he responded with this very data-driven explanation:

> Generally speaking, people like this have never actually dealt with large data sets


Hmm, tell us more? Databases are generally known for their good performance (under locking conditions - this is the relevant factor I guess?), after all...


> Databases are generally known for their good performance

If the data is on a filesystem, then sed, grep and cut pipelines will likely be your fastest option (Yahoo! processed petabytes of logfiles for decades that way.)

If the data is already inside a database table and indexed well, that could be fast enough. But generally speaking, the ETL is often a bottleneck. And DBAs are $$$$ compared to "the UNIX way."

Source: DBA


A column orientated file? What format? Excel? CSV? What is cut, sort or head? Are you only accepting Linux candidates then, a tiny percentage of users?

This sort of utter nonsense question, heavily loaded to your "standard" experience, which is anything but, is even worse than the questions cited in the article.

All you're doing is filtering for people who are in your tribe, who followed the same path as you and think like you, use the same tools as you and the same OS as you.

Pretend all you want, but you're filtering not by "experience" but by trying to find people in your tribe, which is naturally heavily weighted.


Interesting how negative your reaction is. Also how far off target all that anger is.

I am not selecting for a tribe, I am selecting for a job. The questions are loaded, of course. Among the many duties, the jobs do require processing large files, sometimes with cut, Python or C. I want the candidate to use the most appropriate tool as needed. I'd rather not have people implement functionality that already exists in the 'comm' command.

Of course, I want the candidate to ask me what the column separator is. That's why the question is formulated that way.

The right answer will depend on the column separator. Proposing the UNIX cut if the file is CSV is not such a good answer, but for tab-separated files, it is just fine. If the file is CSV and they tell me about cut, my next question would be if that is a good universal solution for CSV files in general.

When someone that knows about the pitfalls of using cut when parsing CSV it shows me they have indeed had experience with that.

Do you see why this question is the best... the possibilities are endless, and the rabbit hole much deeper than it may seem


> The right answer will depend on the column separator. Proposing the UNIX cut if the file is CSV is not such a good answer, but for tab-separated files, it is just fine. If the file is CSV and they tell me about cut, my next question would be if that is a good universal solution for CSV files in general.

TSV and CSV have the same limitations. A tab-separated file could still have tabs inside a field depending on the quoting convention. Either separator could be used with cut. I can't believe you are so confident in your partially truthful answers.


The only true Unix column format is ascii delimited text.

Oddly no one has heard of that, the only reason why I found out about it is because I had to read in punched tapes with 7 character ascii from an experiment done in the 80s during my undergrad.

https://en.wikipedia.org/wiki/Delimiter#ASCII_delimited_text


Fascinating, thanks. In all of the large projects I've worked on, the CSV format variants and their inconsistencies have caused disasters. Who knew that Pandas and Spark handle CSV settings differently by default and spark has a hard time with newlines in its CSV output. CSVs inconsistencies result in a lot of data corruption, doubly so in large teams.

Replacing CSV with flat JSON or parquet depending on the use case has been a good move for avoiding these issues. The risks of CSV are usually just too high.


Quad-spaced facepalm.... How come these were dropped out of usage ?!?


Seems like you're completely missing the point of the interview question which is to see how someone would approach a problem, investigate its requirements, propose a solution, examine its drawbacks and how they would take feedback on that solution and its possible advantages and disadvantages.


I did not miss that. I was pointing out that glofish said he asked questions like these repeatedly to candidates, but he doesn't even understand the basics of the subject matter. That would not make for a good interview.


Bingo!


As someone with background in Mechanical Engineering, software interview questions as above seem so wild and absurd to me. Why would you care about someone knowing the intricacies of CSV or bash? I would expect a good engineer to provide best possible solution to your problem within an hour of googling / research. I really don’t see the point of asking such specific questions on interviews as it has no correlation with finding a good engineer. I wish software field would move closer to interview process of other engineering disciplines but it seems to be getting wilder each year.


Because it's used in the real world all the time?

The amount of times I've had to write my own sorting algorithm in my career: 0.

The amount of grep/sed/awk I've used? Countless.

Someone who is familiar with how powerful and flexible these tools are is likely to accomplish something that can benefit from them quicker than someone who isn't aware of them.

Also in my experience software devs that shy away from the command line because they don't like it rarely pan out.


Come on man ` cut -d "," ` I like the question and how you think about the rabbit hole, but you need to sharpen your knife A LOT before being able to ask such questions, you need to be prepared for all the kinds of answers, which might be right even if you don't have a clue about what the candidate is talking about...


But that is exactly why you can't use cut in general for parsing CSVs - the usual CSV syntax includes quoted fields, in which commas don't separate the values. But cut only examines the input charwise:

    % echo 'a,"b,c",d' | cut -f 1-3 -d ","
    a,"b,c"
I don't think there's a good solution to this using standard tools, but I'm sure there are various CSV packages available. (Which I've never used! - I'm just familiar with this problem from seeing people try to work with CSV data in code using exactly the char-by-char approach taken by cut.)


I think the interviewer-escape-hatch for that is to only have delimiter commas in the file (so cut will work in this situation), and withhold that information to see if the candidate asks about it. If they do ask, that's points in their favor.


I had to read a few times to figure out what “column-oriented” meant before figuring it out. May have not have been able to do it under pressure in an interview. If you’d said “ordered by column” I’d have understood much more quickly.

i.e. Be careful with your phrasing. That is a bias in itself.


I would assume column oriented would mean the data would be formatted something like:

    R1C1,R2C1,R3C1
    R1C2,R2C2,R3C2
So values that have the same column are clustered together. Whereas normally in a file values that have the same row are clustered together. This is what column-oriented usually means when you are referring to databases.

I guess this is not what the questioner meant because they referred to using cut | sort | head as a solution. Though, I don't understand why head would be at the end of either problems solution so maybe I'm missing something. head could be a useful way of peeling out the column you want in the column-oriented problem.


Me too, I thought a “column oriented” file was a file where the data for column #1 comes before #2; ie, structure of arrays rather than array of structures. “cut” doesn’t work with that afaik. I’m not sure I’d ask for clarification here (as to me, this is what “column oriented” means), and probably fail the interview.


I don't see anger or negativity. I see valid feedback for identifying bias with passion. To paint it in a negative light is to introduce bias.


Well the person was exposed as someone just validating themselves in interviews, so legitimate criticism works be painted as an attack.

All tech interviews start with a need to legitimize and reinforce the interviewers as successful and talented ....

Even if we're basically all terrible


Can I just use csvcut?


He didn't ask to use cut, you could use whatever windows function you have used as well. Unless, of course, you've never have had to unmangle a weird text file to get something out of it in your computing history. Then perhaps I don't want you at all?

OP asked a very open ended question, merely made a suggestion that it could also be done with some standard Unix programs (I grew up on windows and even I know about cut and awk because you spend enough time anywhere in tech you will know these). Why it triggered you, not sure, but perhaps the question it's doing its job after all.


Then perhaps I don't want you at all?

I've watched a number of new grad hires pick up bash, vim, and version control from scratch in a month or two and go on the be very successful. For better or worse some good schools don't cover those sorts of ancillary skills, and not every good candidate will tinker with Linux as a hobby.


> Pretend all you want, but you're filtering not by "experience" but by trying to find people in your tribe, which is naturally heavily weighted in chauvinism, racism and elitism.

I didn't realize Linux Users counted as a race now :D


We're a penguin-related species...


`cut`, `sort`, and `head` are basic Unix commands. Even in a Windows world, they're easily available (either running Ubuntu terminal or cygwin).

This is like complaining that you can't read the basics of a new programming language.


Around 1990 I had to do some interviewing and I used this kind of intentionally underspecified simple problem to weed people out. (It seemed radical at the time.) Did they realize the problem was underspecified? Did they try to elicit the underlying “why”? Did they collaborate with me to complete the spec? Were they able to restate the spec coherently? Could they articulate a workable implementation in some technology domain? Basic stuff. Interesting thing is that there were people who really didn't do very well, who we hired anyway, who went on to be reasonably productive and reliable developers. In retrospect I concluded the cognitive and social basis of their ability was incomprehensibly different from mine. But I'd still do those questions today.


Different people are good at different stuff. In my experience the best teams are those with a diverging skill set: Alice may be really good at asking these kind of "why" questions, whereas Bob is really good at quickly implementing things from a spec, and Chris may be very good at databases, etc.


As someone who has had bad data science interviews before getting my current data science job, the process is highly variable. I've had interviews where the interviewer is looking for a specific right answer, with the answer being a binary you-know-it-or-you-don't thing that can't be talked through or worked out in a dialogue with the interviewer.

An example was a whiteboard problem requiring the BETWEEN syntax for SQL window functions, which is very uncommon. After I asked for a hint, the interviewer replied "You don't know the BETWEEN syntax for window functions? Everyone knows that."


My favorite iteration of this is also when the interviewer has a suboptimal answer to this question, and expects you to parrot the wrong thing back to them.

I could tell I annoyed my interviewer when they told me I was wrong and I demurred, and politely asked them to look it up since there was some question about the facts. They did not look it up.


I had that from a Microsoft interviewer. Thought my code was O(n^2) because he was a C guy...whereas I was writing it in Java (something I had checked would be okay with both the recruiter and the interviewer). Querying the length of a string is an O(1) operation, not O(n), so while you could make the case it's suboptimal (since a function call per loop instead of just a variable lookup), it's not quadratic in behavior. And when he asked what I would do if a number overflowed and I said "...let the exception bubble up because based on the function you asked me to write there is nothing I can do cleanly within it" it was pretty clear the interview was over.

Good times.


TIL even sqlite has window functions.


MySQL and sqlite only got window functions very recently, years after the aforementioned interview.

On a take-home test around that time, the question specifically said to use PostgreSQL just because the answer required a window function.


Why would you do cut|sort|head? You should instead just ask the k-sorted merge question about external sorting.

As a FAANG data scientist, I've never once wanted to use cut|sort|head nor have I wanted to work with CSV's. Everything is already sharded and encoded as a schema-enforced binary encoding like protobuf or thrift. The file is so large its better to favor Apache Beam or equivalent to parallelize the aggregations of particular fields over very large amounts of data. But, hopefully you just use some SQL-like interface such as BigQuery that when pointed to sharded files, can easily do aggregations for you with SQL-like language (which, kicks of distributed computing jobs under the hood and is not truly relational). Unless you're streaming data, then that's another question.

Testing unix commands is narrow minded IMO. If you want to test divide and conquer plus streaming, then just ask a flavor of that Leetcode question.


the responses to this are breathtaking. I think I would decline to hire the majority of HN users because of their arrogance.

My partner is learning about data science now so I asked them if I could try this question on them in the context of a data science interview, first thing in the morning and without coffe. They looked at me and said "being asked data science interview questions by your spouse right after waking up is the worst thing in the world but I dunno I would load it into pandas and put it in a data frame". And like honestly that's not how I would do it (I would do awk | sort | head because I always forget the cut column options) but the whole point is that the answer prompts further discussion. Now I know to ask about python and pandas (the thing the candidate uses and knows), and not, I dunno, scala and cascading/scalding or whatever (the thing that I know or use). Good questions investigate what the candidate knows. Bad questions investigate whether or not the candidate knows the things you already know.

People on this site are way too concerned with "being correct".


How do you sort an infinite stream?


You could have a balanced data structure and keep inserting into it.


Sorry, you failed the interview! Your algorithm doesn't terminate, it's no better than an empty infinite loop.

If a list is sorted, then you'd be able to return the largest value. Since that is impossible the correct answer is that it's impossible.


by using an N element max/min heap and evicting the max/min when a new element comes in that's less than the max/greater than the min (note this is also a leetcode problem https://leetcode.com/problems/k-closest-points-to-origin/)


nothing wrong with knowing the answer or where to look it up, I don't get what your point is

the purpose of the interview is to filter out people that do not know the answer or have pre-learned something and don't fully understand its applications. When you are in a dialog it is a very different dynamic,

people that would not ask a question because it is already posted on leetcode are the problem the OP complains about


Since no one else got it, I'd start by allocating an infinite array to ingest the stream into.


O(∞)


It's actually O(n) where n is ∞


You know a O(n) sort algorithm?


O(n) sort algorithms do exist (Counting sort)


the post was getting too long to put in all the details, but basically, what I was getting at, imagine the data comes in batches and you have to retain the N largest seen so far


IMO, that's not an appropriate question for a data scientist. Maybe it's better for a data engineer or a SRE.


Basically you are saying that you cannot think of a way of doing this, other than the most inefficient way --> hiring a new person

This answer would make you fail the interview :-)


The question is ambiguous and misleading or just simply nonsensical.

This sort of thing is sadly common in interviews, where the interviewer some arbitrary answer in mind and expects you to read his mind, which is possible only some of the time.

By definition you can't sort an infinite list. You've conveniently turned the question, in your mind, into something like "how do you efficiently maintain an ordered list of incoming items?"


It's honestly pretty ridiculous seeing your tone in the comments and how you think that highly about your bad interview questions and your flawed conceptions about the solutions, including CSV and TSV confusion. This smile makes it embarrassing even.

Hope I never pass your interview!


Or pass the interview if it was a management role


lol but this is literally a leetcode style problem so what's your point?

https://leetcode.com/problems/merge-k-sorted-lists/

https://www.geeksforgeeks.org/external-sorting/

and it's literally called "merge sorted files" (page 175 of elements of programming interviews).


the point is to see how people think,

it is not so simple to regurgitate pre-learned answers when you alter a problem one small attribute at a time, in each case a different answer becomes optimal, thus you can see if the person understand what needs to be done or not


>the point is to see how people think

i feel very strongly this is a disingenuous claim. clinical psychologists go to school for a long time to learn how to assess people's abilities to think. why should i believe that you a random software engineer have any competency whatsoever. in reality this is exactly the reason standardized exams (or standardized interviews such as leetcode style problems) exist - because average person can't accurately make that call.


Upon completion of the interview the problem would indeed look like the result of the leetcode problem. However the take away from the op is in how the question has a narrative. It enables a dialogue over time. Each sub problem provides n ways of exploring a solution. Each problem providing a sounding board for the candidate to pronounce their thoughts. Such questions are effective at providing more signal(read as talking out loud) from candidates.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: