AWS rejected me since I failed to write prefect code to traverse a tree in level order. Google did not even give me an interview since I told the campus recruiter I have not prepared for the coding questions.
Then I ended up with an internship at CoreOS and created etcd. I am glad that they did not hire me back then.
Today, I am sure I still cannot pass the coding interview at "Giant Search and Advertising Company", but they run a lot of my code in production :P.
Cynical answer though — Google does not want people like you. They don't want to hire entrepreneurs or inventors. They want people who can churn out code when given specific instructions, and that is what their interview process optimizes for.
Before joining, I had endless enthusiasm for computer science and programming. Now I feel so unenthusiastic that I question my future in this industry.
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.
Well, there's your problem right there.
There are plenty of smaller tech hubs around the world.
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.
Genuine question - what do you consider to be interesting problems in advertising?
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.
I thought the answer to that was a rather bland "by gobbling up even more information about everyone"?
Some highly useful data is hard to get directly or requires significant and/or stealthy spend.
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.
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.
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.
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)?
That has no relationship to the paid shitstorm of ads on Google.
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.
And it's a reasonable question. Thanks for asking.
(but the comment did seem legit and it is obvious for posting that anonymous)
There is lots of IT folks around posting or just lurking and it would be very cheap to do some postings on Agenda XY here and there. I doubt it does not get tried.
Unless one takes extraordinary steps to examine what brings truly brings value, most people interview for clones of themselves. Or worse: their idealized self-image.
Google started off with very mathy people, and highly competitive people, and interviewing this way has always worked for them, so why change?
Some people have done internal studies showing how wildly counterproductive their interview process is, and yet it does not change.
I suspect psychological factors are the main reason why this process persists.
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.
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.
No one is interested in your peak performance, all it matters is consistency, predictability, stability, those robustness metrics. Say interview questions kinda sucks, but you show some competency still, means predictable most of what they have to throw at you will at least partially stick, minimizing factors.
You could argue that a workplace that prefers a trait like that doesn't sound like a place for artists' dream place we all desire, but more towards a "software manufacturing factory" envisioned by electric companies like Hitachi in the '80s, if you do I think maybe it is and maybe they were right to a certain extent.
I agree that the interview process looks for self clones. I've been in interviews where interviewer was like "why you used Dictionary to do this? Nobody uses dict in prod code"
But unearned privilege seems a little harsh doesn't it?
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
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.
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.
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.
When most people stop returning Google’s phone calls, so that positions go infilled, then they’ll start talking about change. Right now there’s still enough supply that they don’t have to do anything,
Honestly I don't think it's that cynical - it just makes sense. There are the people who can and will do that stuff - and do it happily - and they would presumably be the easiest to hire as junior devs. Google views it as a stepping stone towards their next product launch, and the programmers see it as a stepping stone to a more enjoyable job.
And then the inventors and entrepreneurs create their own projects, and typically both produce and earn more than they would've at the company.
It kind of works out in everyone's best interest (although I'm sure the Google hiring managers sometimes regret missing out on the guy who invented New Cool Thing, and the guy that invented New Cool Thing is probably still a bit miffed that he couldn't land or get through an interview for a job he/she was clearly qualified for).
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.
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.
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.
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.
You’re clearly not working on their military-contract Terminator-drone program…
…Unless “better” means “stone cold dead”.
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.
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.
Brian Acton, rejected by Facebook in 2009. Then in 2014 FB acquired his company for $19B...
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
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.
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).
Edit: it's unfair to single Google out. It's unfortunately the correct game theory and impossible to regulate.
She said that this is because Google optimizes their interviews for IQ. Not just raw knowledge.
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.
> 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?
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.
whoosh. Re-read what I said to understand how I didn’t compare anyone to Trump. You never ask someone who is responsible for creating a whole process/team/product for honestly critical info about it. Unless they are willfully malicious (which I doubt Gayle is), they are certainly convinced they’ve been doing the right thing (otherwise they wouldn’t be doing it).
> working outside of a google-like company is like dealing with people at a community college...
Sorry, but whoever you talked to took you for a ride. Most Google engineers are writing glue code and glorified ETL processes. I used to work there, I left because it got way to big an deteriorated quickly and now work at a startup with several employees I personally know took 50% pay cuts by turning town Google offers.
> The google interview process is absolutely stellar at creating teams of raw intellectual power
Not from what I saw from 2012 going forward. It was filled with mediocre devs that wrote lots of bad code, including ones that would slip in quadratic runtime behavior. The only thing Google had going for it is that early on it did attract some brilliant people that believed in the mission and created the stellar infrastructure supporting the masses today.
Do you have any reasonable way to convince me and everyone reading your responses that your opinions are more valid than other people who offer contrary opinions?
Why would someone take a 50% pay cut and turn down a google offer? There has to be a bigger reason than the one you mentioned.
>whoosh. Re-read what I said to understand how I didn’t compare anyone to Trump.
I assumed your analogy was used to state that people at google are incompetent and that those who are incompetent can't recognize their own incompetence. The later part may be true in the context of google but I disagreed with the former. Your reply indicates to me that you in fact don't think much of google engineers and that your comparison of incompetence is apt.
As far as I know Gayle didn't work to create the interview process, she was just part of the board and now she actively works to help people pass it. Saying that there exists many people who can't pass the google interview will harm sales of her book. I believe it is against her incentive to say it and that she only said it because she believe it's the truth. There is no active lying going on here.
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.
Some of the smartest people work at google for half a million in TC.
>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.
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).
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.
Bit of a tangent, but, for anyone who's interested, I'm guessing the book was Steven Skiena's The Algorithm Design Manual , 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 .
(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).
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.
It’s far from universal, but the incentives between managers, workers, and shareholders never really align that well.
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.
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?).
just out of curiosity to learn more about your project: Where could I contact you?
No need to imply the OP doesn’t get it just because they’re on the outside of it.
Granted, if the money were not there, I would not find it worthwhile. I would probably just focus on founding my own company.
"If tests truly were tests of learning, things wouldn't be so bad. Getting good grades and learning would converge, just a little late. The problem is that nearly all tests given to students are terribly hackable. Most people who've gotten good grades know this, and know it so well they've ceased even to question it. You'll see when you realize how naive it sounds to act otherwise."
The greatest programmer I've had the privilege of working closely with could easily pass most technical screens, but he's an odd fellow, and I don't think could handle the stress and anxiety of these crazy interviews. Lots of diamonds in the rough out there, but I suppose large companies understand that and just consider it acceptable loss.
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.
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.
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.
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.
As an active interviewer at Google, I think that person shouldn't be allowed to conduct any more interviews without proper training. That's inexcusable.
What even happened next, did you just end the interview right there? Stare at each other awkwardly till time ran out? How did they expect to learn more about your skills if you weren't doing any coding or talking?
If what you're saying all checks out, someone straight out of college (2 years is young) unless he has been working on those kind of things all the time, its an edge case at best.
The fact that he said : "No, you should know this" - Even if he knew it, it shows how they would be work with. Probably dodged a bullet there.
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.
You'd assume a competent enough interviewer wouldn't be so rigid and at least hint that you shouldn't overthink it...
Unless you are hiring someone that is supposed to understand some maths, that is.
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.
This is no fault of those recruiters, just that sometimes they are given very strict guidelines which can hamper creativity within an interview.
This wasn't my experience at any point with Google, Microsoft or AWS
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.
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.
Maybe he accidentally let it slip that he thought the South should have won and Robert E. Lee had some good ideas.
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.
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 want to work for myself however in the long run and I think the skills are more important for that
We run your code in production too! Thanks!
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".
It follows that regurgitating answers to already solved problems is good engineering :)
You did the project you wanted.
AWS and Google got the code they wanted.
Your friends for the jobs 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.
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.
etcd was inspired by a hash-map more so than Chubby.
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?
How about making the questions broad enough for every candidate to have some input and evaluate them on what they choose to focus on? Something like, “How would you design an ATM?”
There should never be a right answer to an interview question, just a candidate that solves problems in a way that fills a gap in your company.
1) 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.
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.
There are plenty of people who do both. They work on their projects, and when needed, they prepare for coding interviews.
The google interview process was not made to filter you out. It was made to guarantee that they will not make a mistake on hiring you. People with the capability to do those interview problems have a high chance of being good programmers. There are many people like you who can't do those problems but are still very good programmers. Google doesn't need to hire you, the whole interview process is optimized for preventing a bad hire rather than finding people like you who are good hires but can't interview.
Second, traversing a tree in level order is a trivial problem from the interview question perspective. It is more than likely that this question will NOT be given by the interviewer because it is too easy. The interview questions FAANG tends to give are a bit more novel. In fact the method in which you use to solve this problem and the problem itself is often just taught directly in school depending on the class you're in, meaning you don't need to practice interview questions to solve it because it's a basic topic.
The solution is called tree traversal using BFS. If you didn't know this, despite working on and creating things like etcd you will appear stupid because the question is just too basic. When I interview I am 100% expecting questions way harder than this... even on phone interviews. Additionally when I'm the interviewer this type of question is the lowest bar, I will fail someone who can't answer this question.
This is not to comment on your abilities. Rather it is to give you a dose of truth. I truly believe that there are many people like you who can program an entire kernel but can't even solve fibonacci recursively on a white board. Despite this I can't stop judging you based off of the white board question nor do I know how to confirm that you can write a kernel despite lack of ability to solve very very basic programming questions.
I am major in computer science, and published paper in top conference. Tree traversal is trivial for me. So I guess I have decent CS background and knowledge?
Writing bug free and perfect code is not equal to simply solve the problem. If you have prepared coding interviews (especially for new grad and internship), you should understand it is less about knowledge but more about practicing and memorization for that specific purpose. The time spent on it is almost a waste in the future.
If the interview is knowledge based or problem solving oriented, I am all for it. Sadly, it is not today in many places. And that is exactly why website like Leetcode exists.
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.
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.
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 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.
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?
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.
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.
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.
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.
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."
A whiteboard interview is a "Political connection agnostic" interview.
Trust me, it happens for certain applicants.
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.
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.
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
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.
I'm mostly arguing that some form of quantitative metric is better than a conversation.
The place with the most leakage is architectural interviews.
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.
- 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.
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.
If management doesn't understand collaborative working environments, humility, and basic problem solving, I don't (and will not) work with them.
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.
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.
The only satisfaction we got from the whole situation was reading the furious reviews the candidates would write on glassdoor.
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.
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.
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.
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.
* 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'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.
> 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`.
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.
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.
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.
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.
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.
> 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.
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
But this is the irony---a job interview is a judgment. Why do you think feelings on this run so high?
How is this relevant? Now you're just taking cheap shots.
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.
"I wouldn't hire you with that attitude"
I'm getting more judgemental vibes from interviewer than interviewee.
there is some simple elegance and power to these old C tools
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.
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.
But maybe that’s more about separating sheep from shepherds.
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.
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.
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).
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.
> Generally speaking, people like this have never actually dealt with large data sets
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."
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.
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
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.
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.
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.
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.
% echo 'a,"b,c",d' | cut -f 1-3 -d ","
i.e. Be careful with your phrasing. That is a bias in itself.
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.
All tech interviews start with a need to legitimize and reinforce the interviewers as successful and talented ....
Even if we're basically all terrible
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.
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.
I didn't realize Linux Users counted as a race now :D
This is like complaining that you can't read the basics of a new programming language.
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."
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.
On a take-home test around that time, the question specifically said to use PostgreSQL just because the answer required a window function.
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.
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".
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.
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
This answer would make you fail the interview :-)
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?"
Hope I never pass your interview!
and it's literally called "merge sorted files" (page 175 of elements of programming interviews).
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
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.