When my classmates were preparing interview coding questions, I was working on a mini TCP implementation and a toy kernel.
AWS rejected me since I failed to write prefect code to traverse a tree in level order. Google did not even give me an interview since I told the campus recruiter I have not prepared for the coding questions.
Then I ended up with an internship at CoreOS and created etcd. I am glad that they did not hire me back then.
Today, I am sure I still cannot pass the coding interview at "Giant Search and Advertising Company", but they run a lot of my code in production :P.
Cynical answer though — Google does not want people like you. They don't want to hire entrepreneurs or inventors. They want people who can churn out code when given specific instructions, and that is what their interview process optimizes for.
This is absolutely true. I work at Giant Search and Advertising Company, and joining was a huge mistake. I thought I would be working interesting technical problems with a high degree of autonomy — instead the work is extremely boring, and you get ahead by playing political games rather than by innovating. I’m one of the rare few here who managed to get through the interview without really preparing.
Before joining, I had endless enthusiasm for computer science and programming. Now I feel so unenthusiastic that I question my future in this industry.
I worked there in the early 2000s. It was fun. Then it wasn't any more. I was much earlier in my career and when I left, having it on my resume meant a lot. Now I've done more and more interesting things. I told the FAANGs, in no unclear terms, I'm not interested. They seem to have gotten the message eventually. I like small companies. You work harder and have a lot more impact. The compensation is good too.
> I like small companies. You work harder and have a lot more impact. The compensation is good too. Leave. The grass is greener.
What small company is regularly paying over $300k+/yr for senior software engineers and paying over $500k/yr for staff+?
The only people I see leaving the big companies are those who already got their riches and/or bought real estate earlier. The rest of us are either tied to them or trying to get in because the real estate market dictates you must earn that income to stick around the bay.
Big +1. Leave the Bay Area. Heck, you could even get a Bay Area job that allows remote and then leave the Bay Area. I worked remote from ATX for 2 years for an SF startup and it was great!
Many of them don't feel particularly smaller, either. I've had literally no desire to move to San Francisco; senior+ jobs here in Boston pay more than enough to comfortably pay a mortgage somewhere nice.
That sucks that you've had that experience, I'm sorry. I hope it's the exception and not the rule. I work on the Advertising part of Giant Search and Advertising, and my experience has been pretty great—indeed, working on interesting problems with a high degree of autonomy. I do need to persuade others of my ideas sometimes, or let them persuade me against them, but this seems like a good thing, and doesn't feel political. Throughout my team and the other teams we work closely with, I find my co-workers and superiors to be thoughtful, smart, open-minded, and really nice to work with.
Some years ago I was unsatisfied with my pay and I accepted the interview of a Giant Search corp, getting to the on-site interview. The lunch with random employees was perhaps the best part of the experience for me, as it became abundantly clear that a good chunk of devs that I had some conversation with outlined in very generic terms the same basic stuff everybody else needs to do in software: maintenance, basic infrastructure, scripts, and so on. Which is, you know, totally expected.
I'm pretty sure that everything is at scale and so on, but I couldn't shake the feeling that up to that point the stuff I would be working on was not on the table and I could be switching from a place where I like what I'm doing [biotech] to just a highly paid but plainly boring SE job.
This curbed my enthusiasm instantly. Up to that point in my career I always considered available positions based on the actual function I would be doing in the company, never vice-versa.
The afternoon sessions didn't work as well, and although I could still have some extra interviews through phone calls I cancelled them a few days afterwards.
I cannot say for sure what did I miss, but I am certainly totally disillusioned for Big Search as a company today due to it's consumer attitude that I no longer wish for a position there.
Having worked on the spend side of things and at high stakes (9 figure budgets), targeting and how to improve it is extremely intellectually stimulating. More than anything else I've done in my career, even. This is especially true when you have constraints, like being in a regulated industry such as legal marketing.
The only problem is that it's hard to command a salary commensurate with how good you are at it unless you're in business for yourself AND the one spending the money.
you try to make people click on ads, selling that as "extremely intellectually stimulating" sounds fancy but all you do is manipulate people and you're nothing more than a marketing guy with fancy tools. Do you really want to spend your career working on that? Why not use your power in some way that it actually helps people, even if that means that you earn a bit less.
I thought that I made it clear that I don't work on this anymore.
Advertising isn't an inherent evil. You find your mechanic, doctor, lawyer, etc because they advertise.
I advertised for one specific company. I worked in an industry that was pretty grey. Some parts of the business were vaguely predatory and others served a great public social need. More importantly, you had to have an actual reason to fill out our forms and follow through with us. We weren't just desperately trying to get any eyeballs. The work that I did very much did help people.
Also you're not going to get much mileage shaming people for what they do for a living. You being reductive doesn't really reflect reality either. I was much more than some marketer and yes, the problems were extremely intellectually stimulating, otherwise I wouldn't have been there.
That's better than I can say for most of the quants I worked with -- they were almost all just in it for the money.
> You find your mechanic, doctor, lawyer, etc because they advertise.
It’s funny you say that, because I found all three literally by looking at reviews and not advertisements. Those 3 categories are perfect examples of industries where referrals are far more reliable than choosing which one had the best ad budget.
A lot of reviews are just forms of advertisements.
Companies pay third parties lots of money to curate their reviews and put them in contact with the reviewer to smooth things over.
I know that because that's the business I work in now.
Companies still have a problem of getting their reviews surfaced to the top of your search. They also have a need to give people the lowest-friction way possible to leave them a positive score when it's the best time in the interaction to do so. There are many large enterprises competing in this space specifically.
The best performing adverts today are ones where you don't even realize you've been marketed to.
If having to reach out to real customers and fix their fuckups until they are happy enough to leave a good review, then I’m completely fine with that level of advertising. That’s just fixing your fuckups until your customers refer you, which is the best thing that you can hope for.
That has no relationship to the paid shitstorm of ads on Google.
Somewhat. A lot of review systems are designed to contact you asking for a review at the exact time you're most likely to leave a good review. The companies then optimize the whole customer interaction around that experience. To actually go back and edit that review when things change isn't always easy.
The overwhelming majority of all other reviews are either the Amazon variety (so a paid endorsement, usually) or from total cranks. People don't really often leave unsolicited reviews.
That's what I hear, but then I see comments from folks like User5283 above. I have the impression it may be changing into something much more similar to a typical corporation after years of avoiding that fate.
Beware though, that he or she used a throwaway. Comments can be made by anyone, also a marketing company contracted by oracle who still want talent and have to shame competitors with better image.
(but the comment did seem legit and it is obvious for posting that anonymous)
There is lots of IT folks around posting or just lurking and it would be very cheap to do some postings on Agenda XY here and there. I doubt it does not get tried.
Unless one takes extraordinary steps to examine what brings truly brings value, most people interview for clones of themselves. Or worse: their idealized self-image.
Google started off with very mathy people, and highly competitive people, and interviewing this way has always worked for them, so why change?
Some people have done internal studies showing how wildly counterproductive their interview process is, and yet it does not change.
I suspect psychological factors are the main reason why this process persists.
Google gets so many applicants it's irrelevant how counterproductive the interview process is. It selects for people similar to the interviewers, but that matters little, since they can afford to say No to 99% of candidates because thousands will still apply.
What boggles my mind is to see the same type of "skill testing" whiteboard coding interviews at smaller companies and startups that pay far less and don't have golden handcuffs to offer.
I've been at Google for 8 years. If I went to one of these smaller companies to interview and they asked me to whiteboard a data structure or algorithm problem I'd just walk out. I'm not the best programmer in the world or particularly shit-hot, but I'm sure there are many that are that would do the same.
Companies copying this process are doing themselves a disservice.
>Google gets so many applicants it's irrelevant how counterproductive the interview process is.
It still may be relevant when you are looking for a specific domain knowledge instead of a generic "programmer". A great example is Amazon Game Studios. They employ the general Amazon hiring process from what I understand yet, as a game studio, it's a complete and utter failure. There are just few thousand experienced game programmers in the whole world and only a fraction of them wants to apply at Amazon at all for different reasons. You cull 99% of them and you are left with inexperienced people who will not be able to learn anything since there is nobody to learn from. Even if few experienced people got through or went around hiring process (e.g. celebrity programmers hired without whiteboarding) they will be in a minority and unable to mentor the rest of the studio. Google and Facebook are spinning up their own game studios and I expect the same result from them.
One thing I wasn't aware as a nerdy teenager was how everything is valued IRL in its guaranteed minimum performance, not conditional maxima.
No one is interested in your peak performance, all it matters is consistency, predictability, stability, those robustness metrics. Say interview questions kinda sucks, but you show some competency still, means predictable most of what they have to throw at you will at least partially stick, minimizing factors.
You could argue that a workplace that prefers a trait like that doesn't sound like a place for artists' dream place we all desire, but more towards a "software manufacturing factory" envisioned by electric companies like Hitachi in the '80s, if you do I think maybe it is and maybe they were right to a certain extent.
I agree that the interview process looks for self clones. I've been in interviews where interviewer was like "why you used Dictionary to do this? Nobody uses dict in prod code"
But unearned privilege seems a little harsh doesn't it?
Now I’m curious why they didn’t use dicts, I love dicts. I’ve been writing Python for a living for almost 15 years now and dictionaries and (reasonable) list comprehensions still attract me like they did the first day I “met” them.
To be honest the lady taking the interview didn't understand my code, at least that's what I got. The guy with her definitely didn't understand a line I had written.
Maybe that was her way of protecting herself or something else
But I've never come across any real reason to not use dicts
Frankly though, I think there's something more fundamental about large organization as to why this sort of stuff happens (not just at companies). Perhaps it's the iron law of oligarchy, but corruption seems inevitable at scale. Very few innovative people seem able to reap or retain the most value of their work.
> Very few innovative people seem able to reap or retain the most value of their work.
Once a company pays you, it's not your work, it's their work. They paid you fair and square.
IMHO a developer need to produce about 10x what's his paid as to cover for the company costs and profits. If one thinks that they can cover those 9 tenths in marketing, office space, infrastructure, admin and legal costs in a more efficient manner, they should quit and start their own company.
They don't own your innovation outright unless that's in your work contract and you haven't negotiated a fairer deal.
And I have no idea where you get your 10X figure from. In fact it's very hard to estimate the specific business value of specific dev work in very large companies, over any time period.
From a high enough level the job becomes "Pay devs to keep the engines running." Unless you're innovating new products/services at a senior level, it's hard to break it down further.
Which is partly why the interview process has become homogenised. Realistically most developers are engine components, not engine designers - although it's easy to be fooled when your component value is process optimisation - and FAANGs have optimised the funnel to select good components.
You need to be senior++ and/or in startup land to be an engine designer - which differs from being a component because it allows independent agency for strategic goal setting, instead of optimisation of tactical implementation.
most groups don’t change until it is obvious to most of them that what is going on is not working.
When most people stop returning Google’s phone calls, so that positions go infilled, then they’ll start talking about change. Right now there’s still enough supply that they don’t have to do anything,
Honestly I don't think it's that cynical - it just makes sense. There are the people who can and will do that stuff - and do it happily - and they would presumably be the easiest to hire as junior devs. Google views it as a stepping stone towards their next product launch, and the programmers see it as a stepping stone to a more enjoyable job.
And then the inventors and entrepreneurs create their own projects, and typically both produce and earn more than they would've at the company.
It kind of works out in everyone's best interest (although I'm sure the Google hiring managers sometimes regret missing out on the guy who invented New Cool Thing, and the guy that invented New Cool Thing is probably still a bit miffed that he couldn't land or get through an interview for a job he/she was clearly qualified for).
> and typically both produce and earn more than they would've at the company.
Eh, there's a lot of us who haven't done great financially but who have written a lot of open source code being run at bigcos. Being an entrepreneur requires another skill set altogether. One that I seem to lack, although I finally have come up with a solid idea in the last year that might get me somewhere whenever I'm ready to make the move.
I'm sure if I spent significant time preparing, I could do well at Google's interview process, and other FAANG companies have tried multiple times to get me to interview (oddly, never Google), but I'm not convinced it's a good idea for me. I've been much happier working for smaller companies. The one time I worked for a large corporation years ago, I was miserable. People say Google is different, but I'm not convinced.
> They want people who can churn out code when given specific instructions, and that is what their interview process optimizes for.
I think the reason is a bit different.
Google is a search engine. It's a company whose success was due to one (or several) but very good algorithm.
That explains everything: why they are so obsessed with algorithms, why they hire so much olympics winners, why they don't care about anything else.
Their code is pretty bad most of the time, they've took beautiful Webkit and turned it into Blink mess. They are all about algorithms, they don't care about code.
And that's a pity that people are copying Google's methodology without understanding why Google is doing so. If you are developing an OS, you'd be better copying Microsoft, which had much of a different approach, nearly without any algorithm questions.
>> They want people who can churn out code when given specific instructions, and that is what their interview process optimizes for.
Somehow I doubt that. Can anyone who actually works at google comment on what it's like? Do people come to you with specific requirement and expect you to crank out code like the interview problems?
I've never worked somewhere where the software folks were actually just coding machines.
Gathering and defining requirements is very much a part of the job. It is entirely unsustainable to rely on others to tell you what to implement in Google.
This is implicit in a coding interview, though. I, the interviewer, take a couple of sentences to describe a problem. What next? Way too often, rather than ask more questions - gather and define requirements - a candidate will launch straight into solving a problem different from the one I am describing.
Requirements gathering in reality can often require more soft skills or political skills, which doesn’t seem to be the primary focus of these interviews. Which isn’t to say the skills you mention aren’t important.
Most engineers at Google never talk to non-engineers, the requirements gathering comes instead from looking at code, reading design docs and talking to other engineers.
>> Gathering and defining requirements is very much a part of the job. It is entirely unsustainable to rely on others to tell you what to implement in Google.
It's like that everywhere. Nobody comes to you with complete requirements. People/customers come with problems they need solved. Sometimes an outline of a specific solution is specified, but there's always a lot of detail missing.
Not at all. I've been at Google for a bit over two years, and my experience has been at the far other end of the spectrum: a lot of autonomy, gathering requirements, designing & implementing. Also I have a fair amount of agency to see something that would make people's lives better and pitch it as a thing I'd like to work on. If it's less than a day or two of work I can generally just go do it.
How much of interview-style coding is involved in your work? More broadly, would you agree to the OP that interviewing for software developers is broken?
What you get told is What needs to be accomplished, but not How, if that makes sense.
E.G. IF you choose to accept this challenge, this platform is running at XX% availability and we need to run it at YY% availability. HOW you get to do that, it's up to you.
Some folks don't accept these challenges and they go and find and fix their own interesting problems. But that's harder because you have to get buy-in from managers in order to get resources for that.
Google's big enough that no one person could possibly speak confidently for all of engineering in this regard.
For what it's worth, this doesn't match my experience at all. In the area I work in (SRE in technical infrastructure, but the same seems to be true for our dev partners), I see a lot of expectation for bottom up ownership. I could totally understand if somebody with a different mindset and perspective (I'm a manager, so I can see pretty clearly what's valued at evaluation time) arrived at a different conclusion.
Right. Coding tests are designed to find people who are happy in a job where their only responsibility is: "Here's your coding assignment. Go do it." Technology companies are overfull of engineers who want more responsibility than that. They don't need any more.
Agree, they want smart workers (well you have to be smart at some degree to do software). And they don't care if they will miss some genius, they just let other companies help the selection process, and if you turn out to be gold, they will pay a big money to get you.
I've read from blog posts and even from conversations that companies require acquihires, particularly non-founder employees, to go through an interview process. It may be shortened, but they still often have to do the typical algorithmic interviews.
I'll see if I can find one of the blog posts I've read about the process.
Note: to be clear, I'm describing the process for acquihires, not founders just wanting to sell their company and walk away with some cash (which actually seems to be somewhat unusual).
Is that a uniquely American thing? I'm 100% certain that even if the company I work for was acquired, my current contract would still apply. So I would need to be given at least 3 months notice, and couldn't be discharged without a good reason - failing some internal interview wouldn't be such a reason.
You could have saved a lot of space just saying button pressers. This is most large companies and why I am burnt out on writing software professionally.
The reasoning for this is the commoditization of software hiring. The idea is to target the median of the bell curve, to lower risks and costs associated with hiring. This targets the greatest quantity of developers in a moment, but it also means the people who play it safe, follow popular trends, and don’t take any risks on product improvements.
To think about it another way the idea is to create mediocre software with mediocre developers because the software is thought to cost less than finding, hiring, and retaining top quality people.
Now connect the dots with: How much customers are willing to pay for software developer work?
They don't want to pay anything. They don't deserve best software written by best developers. Take for example GIT, which is extraordinary piece of software, saves a lot of problems and time. If it was not free, most software shops would just keep copies of folders with dates or whatever insane ways they had (SVN is for me insane way as well :) and big paid VCS were popular at big co's. not even one became close to "industry standard" as GIT).
Makes perfect sense. Thats when you know you need to short the stock in the LONG RUN. Because all they know is taking orders from someone and running it.
This is the same with all companies. If Mark Zuckerberg steps down from Facebook, you can pretty much know, it's going to go down.
That’s a lie they tell employees to make them feel good about themselves. If they actually cared about keeping competent engineers away from competitors, their interview process would be tuned to look for engineering skills, not leetcode.
Straight from the horses mouth I once asked Gayle Lackman on quora: does their exist engineers who no matter how hard they study can NEVER make it through the google interview process? She said yes.
She said that this is because Google optimizes their interviews for IQ. Not just raw knowledge.
That’s incorrect. An interview process with true negatives doesn’t mean it isn’t loaded with tons of other false positives. Being good at leetcode has no relation to engineering skills, despite it being a skill in itself.
Where in my comment do I talk about leetcode or false positives?
Not only are you incorrect, but you are completely off topic.
I am saying Gayle Lackman, the author of Cracking the coding interview and, in the past, one of the board members who decide on candidates in the google interview literally told me word for word that the interview optimizes for IQ. Meaning that there are tons of engineers who can spend a life time studying and never get into google because they are genetically not intelligent enough.
I’m telling you that Gayle is full of shit. They have deluded themselves into thinking they are measuring IQ when they aren’t.
> who can spend a life time studying and never get into google because they are genetically not intelligent enough.
Cool story, but a test that has some true negatives says nothing about its false positive and false negative rate.
Gayle has to convince you that an entire life’s work impacting hundreds of thousands of people’s careers isn’t deeply flawed (because that would reflect pretty poorly on Gayle).
Gayle is the last person you would want to ask if the Google interview process is good. Understand?
Would you ask Donald Trump if his presidential administration is doing well?
>Would you ask Donald Trump if his presidential administration is doing well?
You're absolutely insane if you compare google engineers with the trump administration. Nobody thinks of google engineers like this. Check yourself. Being a google engineer is like getting into stanford or berkeley the prestige is high and I've even asked engineers who've worked in both scrappy startups and google.
The difference to them is night and day; working outside of a google-like company is like dealing with people at a community college... the level of intelligence, work and projects are on a whole different level.
The google interview process is absolutely stellar at creating teams of raw intellectual power. What it is not stellar at is catching all the people who are incredible programmers but bad at whiteboard interviewing... that's it.
> You're absolutely insane if you compare google engineers with the trump administration. Nobody thinks of google engineers like this.
whoosh. Re-read what I said to understand how I didn’t compare anyone to Trump. You never ask someone who is responsible for creating a whole process/team/product for honestly critical info about it. Unless they are willfully malicious (which I doubt Gayle is), they are certainly convinced they’ve been doing the right thing (otherwise they wouldn’t be doing it).
> working outside of a google-like company is like dealing with people at a community college...
Sorry, but whoever you talked to took you for a ride. Most Google engineers are writing glue code and glorified ETL processes. I used to work there, I left because it got way to big an deteriorated quickly and now work at a startup with several employees I personally know took 50% pay cuts by turning town Google offers.
> The google interview process is absolutely stellar at creating teams of raw intellectual power
Not from what I saw from 2012 going forward. It was filled with mediocre devs that wrote lots of bad code, including ones that would slip in quadratic runtime behavior. The only thing Google had going for it is that early on it did attract some brilliant people that believed in the mission and created the stellar infrastructure supporting the masses today.
Do you have any reasonable way to convince me and everyone reading your responses that your opinions are more valid than other people who offer contrary opinions?
Why would someone take a 50% pay cut and turn down a google offer? There has to be a bigger reason than the one you mentioned.
>whoosh. Re-read what I said to understand how I didn’t compare anyone to Trump.
I assumed your analogy was used to state that people at google are incompetent and that those who are incompetent can't recognize their own incompetence. The later part may be true in the context of google but I disagreed with the former. Your reply indicates to me that you in fact don't think much of google engineers and that your comparison of incompetence is apt.
As far as I know Gayle didn't work to create the interview process, she was just part of the board and now she actively works to help people pass it. Saying that there exists many people who can't pass the google interview will harm sales of her book. I believe it is against her incentive to say it and that she only said it because she believe it's the truth. There is no active lying going on here.
Know a few ex coworkers and friends of friend who after multiple failures eventually got accepted.
Their strategy is the same across the board: practice makes perfect (a.k.a leetcode). Don't give up, keep trying.
You are well aware that there's a big industry around interview preps for Hi-Tech BigCos and Gayle herself is one of the implicit founding of this industry right?
Pre-Leetcode/HackerRank the kind of people who got accepted to Google are mostly their kind: ACM/TopCoder and most folks who grew up/go to school in Bay Area because well duh... It's what they do everyday: practicing leetcode style problem solving. The Stanford/UC Berkeley folks got in because well... Interview questions are shared among interns because there's no database like today's LeetCode.
Ironically, the people who are truly of the highest intelligence and skill level would never choose to work at a place like that. So it's fair to say that what they are actually selecting for are people who are smart, but not too smart. Just like cops, really.
You don't have to be mean. Claiming that algorithmic interviews is a proxy for IQ is also probably something that the powers that be at Google "pulled out of their ass". I don't see any data that says it's correlated with standard IQ test scores. I'm skeptical that it is a good proxy since you can specifically study for these interviews. The IQ tests, at least in theory, should be attempted without preparation so as to reflect your "raw ability". Leetcode grind for 3 months is not exactly raw ability.
Not trying to be mean but the fact he made that up out of thin air is not only something that isn't backed with data but something that is intuitively not true. With the reputation and amount of comp google offers there is no reason why intelligent people or less intelligent people would just avoid google. You're assuming only less intelligent people want higher salaries while intelligent people don't which isn't true at all.
>I don't see any data that says it's correlated with standard IQ test scores.
While there's no Data that correlates IQ with algorithm problems. Intuitively the more intelligent you are the better you would be at these algorithm problems.
If IQ measures intelligence and if intelligence determines your ability to perform well on algorithm problems than your performance on these problems correlates with IQ.
To deny the above logic would be to say intelligence has no correlation with IQ and/or algorithms therefore algorithms don't correlate with IQ.
Not every axiom needs to be measured with data. Common sense and intuition also fill the gap where no data exists. Google saying Intelligence correlates with your problem solving abilities and abilities to solve computer science problems is something that absolutely makes sense even if no data to back it exists.
>Leetcode grind for 3 months is not exactly raw ability.
Doesn't matter how long you spend on leetcode. Google will present you with a problem you haven't seen before and there are a huge amount of people who have done leetcode for years and can't pass the interview questions.
If you're a guy who just grinds for 3 months and can suddenly pass the google interview with flying colors than you're the guy that google wants because there are many people who can't do this.
> Doesn't matter how long you spend on leetcode. Google will present you with a problem you haven't seen before and there are a huge amount of people who have done leetcode for years and can't pass the interview questions.
It matters how long you spent time on leetcode/other practices from popular algorithm books (comen, skiena, sedgewick). Source : friends, ex co-workers, and personal experience. Sometimes they just change the "story" questions but the algo and tricks are the same, sometime they took it verbatim from leetcode (or the other way around: someone leaked them to leetcode).
Real Talk tho: Whats the range?
Im ~low 90 percentile and I wonder if I bang my head against the LeetCode wall for a few months, then I too, can get $200K+ and free lunch 4 lyfe.
I largely brushed up on algorithms, though I'd seen most in grad school (which was a while ago). There's a recommended book on algorithms which is very nice (red cover, but can't recall title). Man pages are good, too--one Googler was quite unhappy that I didn't know the 'ps -o' flags off the top of my head.
I actually passed the on-site and hiring committee on my third try, but was (apparently) nixed by some executive, for reasons I can only guess at.
I'm estimating prevalence based on my SAT and GRE scores. As supporting evidence, even colleagues with PhDs often seem not to do as well when mathy sorts of puzzles come up in real life. As often noted, however, that and a dime will get you a cup of coffee.
It might be sour grapes, but lately I've come to appreciate the benefits of being the big fish in a tiny pond, rather than the tiny fish in an ocean I'd be at a FAANG. Money's nice, of course, but in the end you do pay for it, one way or another.
There's a recommended book on algorithms which is very nice (red cover, but can't recall title).
Bit of a tangent, but, for anyone who's interested, I'm guessing the book was Steven Skiena's The Algorithm Design Manual [0], as it is well-regarded and has a red cover.
Also, even more tangentially, there are videos of the author's Algorithms course lectures online from 2012 which I went through once and they were pretty good [1].
(There were one or two that had audio issues or issues seeing what he projected on the screen, but there are multiple years' worth of videos, so you can choose an alternate from an earlier year if necessary and the slides are available there too, so you can follow along with them, if need be; audio-only files are are also available if you want them).
Reading posts like that make the process seem stupid, but it has utility for the interviewers. All of this silliness is creating an artificial talent shortage which drives up salaries at FANG companies.
It’s far from universal, but the incentives between managers, workers, and shareholders never really align that well.
Wow. I don't have as prolific a tale as that, but I'm in the looking stage right now and the idea of cramming for a test I haven't taken in 12 years annoys the hell out of me.
I've done some pretty interesting things in biotech in my career, things that required learning about motion control, digital imaging, signal processing, and biology... but if I want a job as a web dev I apparently need to memorize how to implement every sorting algorithm... on a whiteboard... in ten minutes. The fact that I know which to use when is irrelevant. Bleh.
This is part of the reason why I've only consulted into big companies, and only briefly. It's not just that I am not that sort of person, it's that I don't like being around that sort of person.
Software engineering is also another field where there's no effective upper limit on difficulty. In other words, no matter how good you are you (should) always feel that you're barely capable of understanding what you're supposed to be doing, let alone doing it.
That's right from "make a single static web page" to "submit binary fix to close-source compiler" or whatever the high end of your particular field is (Win a technical argument with the C++ standards committee? Shave 0.001% off the load time of the google homepage? Discover a new way to monetise users?).
Having worked at cutting edge biotech,startups and FAANG I wholeheartedly defend the interview process, and believe you would too if you ever switched over for a while
I think there's a certain breed of people who will pony up the time and resources to levelup for the interview, and the compliment. Ignoring the privilege of resource availability, i think its totally doable and worthwhile. I come from a blue collar family and I think my old man would love to hear I can pull off miraculous study habits for a month to take home the kind of paychecks offered for hitting a keyboard.
Granted, if the money were not there, I would not find it worthwhile. I would probably just focus on founding my own company.
If learning is the naive approach to getting good grades then programming fun projects is the naive approach to passing technical interviews.
"If tests truly were tests of learning, things wouldn't be so bad. Getting good grades and learning would converge, just a little late. The problem is that nearly all tests given to students are terribly hackable. Most people who've gotten good grades know this, and know it so well they've ceased even to question it. You'll see when you realize how naive it sounds to act otherwise."
The greatest programmer I've had the privilege of working closely with could easily pass most technical screens, but he's an odd fellow, and I don't think could handle the stress and anxiety of these crazy interviews. Lots of diamonds in the rough out there, but I suppose large companies understand that and just consider it acceptable loss.
That's what every bitter HN comment on the topic forgets. If Larry Page could sit down and talk to each candidate, I'm sure he'd be able to properly assess these kinds of corner cases. The challenge isn't being able to do that at an individual level; it's being able to do it in a way that's somewhat consistent and scalable across tens of thousands of interviewers and millions of candidates. Any large system is going to have false positives and negatives, and hiring is broken to begin with at most companies (assessing whether someone will be a good employee for the next few years based on a few short meetings is really hard)
That's still waving away the difficulty of taking an entity's goal and losslessly/consistently distributing it into thousands of individuals. It's just not a possible task.
One thing to note about coding interviews, they're very simular to somone looking over your shoulder while you're working.
Nobody can perform well like that.. One great colleague who I wish I was in the interview for, simple started thinking out loud.
Everything he was thinking, he said out loud, and of course, the team loved it. Because thats all it's about.
If its not over a video chat/submission, comment your code your thoughts, remember, they want to know you chain of though, not your knowledge of a framework/algorithm (unless its very specific)
> Today, I am sure I still cannot pass the coding interview
If you know how to figure out the problem, forget the technical side and explain how you would go and figure it out.
So I had an interview that was like that, but I wasn’t given enough information. I was asked to implement the “inverse square law in code” ... and I explained to the interviewer who was two years out of college (I looked up all of the interviewers on linkedin, so I had a good idea of their experience and areas of expertise) that my first step as someone who hadn’t been in an academic environment or exposed to this kind of requirement for over a decade would be to research the requirement and asked if I could consult a Wikipedia article. “No, you can’t consult outside sources.” “Ok, can you explain to me the inverse square law?” “No, you should know this.”
I didn’t know that. Also, I didn’t have enough information to ask good questions, because I was pretty sure that this was an incomplete specification and I needed to ask informed questions to reach a particular implementation.
As a result, the company’s evaluation was that I didn’t know how to code.
> and I explained to the interviewer who was two years out of college
Yeah, that one's easy. Young coder sees a competent, experienced dev and tries to sabotage your interview out of fear you'll show up and make a fool of him. It's possible he was just that arrogant, but it sounds suspicious.
Based on my experience, devs who are 2 years out of college, regardless of how well they understand algos and data structures, are mediocre software engineers. The only exception to that are those devs who have been coding since they were 10 or 12, and who grew up working on actual open source projects (one of my main open source collaborators was like this, and was an excellent dev by age 20). Just growing up coding isn't enough, since you won't have exposure to the actual engineering practices needed for professional developers. And just 4 years of college isn't nearly enough, since you again don't get much exposure to the actual engineering practices needed for professional developers.
Naw, I just shadowed a new young interviewer and he asked a similar question that was unreasonable. As a recent grad he legitimately didn't recognize that the interviewee wouldn't necessarily know this one specific thing. We discussed it and he's going to try again next time with a more reasonable question.
As an active interviewer at Google, I think that person shouldn't be allowed to conduct any more interviews without proper training. That's inexcusable.
What even happened next, did you just end the interview right there? Stare at each other awkwardly till time ran out? How did they expect to learn more about your skills if you weren't doing any coding or talking?
If what you're saying all checks out, someone straight out of college (2 years is young) unless he has been working on those kind of things all the time, its an edge case at best.
The fact that he said : "No, you should know this" - Even if he knew it, it shows how they would be work with. Probably dodged a bullet there.
In years past something like this in an interview would've rattled me. But now that I've been in this biz for 30+ years I think I'd just stand up, look the guy in the eye in a really squinty way and say, "Well, then I think we're done here kid" and walked out. You get to a point where you just won't put up with this kind of bullshit after a while.
I'd ask: if I get a job at your company, will I be not allowed to consult outside sources too? I mean, about half of programmer's work on real projects is googling stuff.
I had a recruiter reach out to me recently about a VP role - when I looked her up on linked in seemed legit. But then in the “people also searched for” section there were all sorts of recruiters that appeared fake. I can’t explain it but just seemed like they weren’t real. In any case this one recruiter told me before they’d talk to me I needed to take a “cognitive” test at a third party site. I get testing... but the whole encounter felt like they were just feeding profiles into a machine.
No interview process is invulnerable to bad faith interviewers. Refusing to help you past roadblocks just makes for a worse interview signal. Maybe the candidate doesn’t know X but has extraordinary depth on Y, and so on. Bad interview training or negligence!
Though what's a bit silly here is that all the information you need is right there in the two words "inverse square", it's only the word "law" tacked on that made you (presumably) assume there had to be more to the concept.
You'd assume a competent enough interviewer wouldn't be so rigid and at least hint that you shouldn't overthink it...
What does it mean to implement it in code though? What kind of data should it consume - n-dimensional coordinates, distance matrices, some sort of power level to calculate falloff? If it’s as described, it’s way too vague. Inverse square laws show up all over.
I did that for an interview for what is now my employer. It was via Skype with a shared code editor. The interviewer asked me to implement a data structure that I had not used (directly—I'm sure plenty of libraries I use utilize it) since college, and I said as much. I told him I was quickly looking it up on Wikipedia, skimmed the article (mumbling to myself, I'm sure), and then proceeded to implement it. My candor and ability to quickly synthesize information on the fly must have reflected well on me, because I ended up getting an offer.
This wasn't at a big name tech company, though. From the sounds of it, most of those places don't give interviewers nearly as much leeway as mine had.
It's certainly true that larger tech companies will not allow much of the 'workflow' into the interview, but this is usually down to the interviewers not being technically sound on the project(s) and most of the time just given a script with certain criterea, who are usually contracted to do so.
This is no fault of those recruiters, just that sometimes they are given very strict guidelines which can hamper creativity within an interview.
My problem I can do this when I'm alone or when it's a real pair coding. During an interview when stress and adrenaline kick in. I'll make a silly mistake and after that, because I'm judged by the other person my brain locks up. I'm feeling like a total fraud.
But the issue is that they're not just judging you by the approach, they are also judging you by your results.
Some people, especially those with social anxiety (not some fancy psychological term, just someone who feels uncomfortable when someone is watching over their shoulder), can only achieve results if they are not judged during the journey.
> AWS rejected me since I failed to write prefect code to traverse a tree in level order.
I hate to break it to you, but Amazon doesn't reject a candidate because he bombed his coding challenge. I know people who received a job offer from Amazon for a developer position although they somewhat bombed their hard skills component. If you were rejected after passing the coding challenge and phone screening interview then odds are you actually bombed their personality and/or soft skills aspect of their interview process.
[Thinking to themselves:] "Is this serf really the right kind of drone, the type who will fit neatly--much like an unthinking cog--into our organizational machinery?"
Maybe he accidentally let it slip that he thought the South should have won and Robert E. Lee had some good ideas.
Yeah, they do weed out racists and misogynists and people who in general have a problem with minorities even if they can traverse a graph like a champ, but as far as I know the main reason why someone is rejected after passing the online test and phone screening is having serious problems with their personality and soft skills that, as a whole, render the candidate unable to improve to an acceptable level and thus are unsalvageable.
I hope the message that people take away from this anecdote is that "even the best people don't always pass an interview at AWS first time". But if someone is interested in the benefits AWS has to offer, try again. I interviewed three times before getting hired there, and I am the happiest I have ever been. I work with great people, on high-stakes, challenging problems that match my strengths, and we work 40 hour weeks, including time for beer. I have enough time outside work to learn new things (this year some basic FPGA programming). And skiing is 90 minutes away.
Getting good signal-to-noise ratio from ANY interview, forget the big cos, is really difficult. I've seen great programmers passed over because they were _not_ given a chance to whiteboard and show their technical skill. At the end of the day, there is a bit of randomness to the process of sizing anyone up in an hour, and people will make bad calls.
That said, I'm skeptical about your particular story. As a process rule, AWS doesn't provide interview feedback, so I'm pretty sure you don't _actually_ know why you were rejected, you can only guess. Perhaps if you were rejected in phone screen(s) it can be obvious, but if you made it to an on-site, I can guarantee (based on experience being in the room during hiring decisions at AWS) that they don't almost someone because of one bad whiteboarding result; there are multiple people collecting and reporting on results and only one person, the bar raiser, has veto power, and I've never seen it used for something as banal as not writing perfect code.
I also don't know what happened in your interview, but consider it's also possible that you completely bombed it: failed to ask questions, failed to communicate properly, or made more mistakes than you even realize.
It's certainly great that you went on to do great things, but maybe at the time you interviewed you weren't yet doing those great things...
To quote Hamming:
"""In science if you know what you are doing you should not be doing it.
In engineering if you do not know what you are doing you should not be doing it."""
It follows that regurgitating answers to already solved problems is good engineering :)
Depends, if he was still working in Big Tech Co, they could have potentially not open sourced it, they could have used his secret sauce to get better system performance compared to competitors.
Google does not want bright, creative people anymore. Google only wants drones now. It's a shift that coincided with its change from a technology company to an advertising company.
True, but its a very technically sound product. Authoring it as an intern cannot be anything but a sign of prodigious skill.
As an amusing anecdote, I didn't drill for internship interviews either and I ended up at a successful startup by sheer luck. I did well there, but I never achieved the level of technical brilliance that OP did.
I feel like there were far more opportunities like this 8 years ago when I was doing that, though.
A company that cannot come up with a better more interesting process isn’t somewhere I want to work.
How about making the questions broad enough for every candidate to have some input and evaluate them on what they choose to focus on? Something like, “How would you design an ATM?”
There should never be a right answer to an interview question, just a candidate that solves problems in a way that fills a gap in your company.
1 is included in at least Google interviews. 3 requires that you hire for a specific tool/language use, most programmers are able to learn new tools and languages in the time time periods that are hired for.
I'd like to do more of 2, understanding, debugging, fixing and refactoring code is, in my experience, more of the day to day work than writing entirely new code. I don't know why this is not typically part of interviewing, maybe there's some reason it doesn't work? It would be interesting to see a more comprehensive evaluation of this approach.
The google interview process was not made to filter you out. It was made to guarantee that they will not make a mistake on hiring you. People with the capability to do those interview problems have a high chance of being good programmers. There are many people like you who can't do those problems but are still very good programmers. Google doesn't need to hire you, the whole interview process is optimized for preventing a bad hire rather than finding people like you who are good hires but can't interview.
Second, traversing a tree in level order is a trivial problem from the interview question perspective. It is more than likely that this question will NOT be given by the interviewer because it is too easy. The interview questions FAANG tends to give are a bit more novel. In fact the method in which you use to solve this problem and the problem itself is often just taught directly in school depending on the class you're in, meaning you don't need to practice interview questions to solve it because it's a basic topic.
The solution is called tree traversal using BFS. If you didn't know this, despite working on and creating things like etcd you will appear stupid because the question is just too basic. When I interview I am 100% expecting questions way harder than this... even on phone interviews. Additionally when I'm the interviewer this type of question is the lowest bar, I will fail someone who can't answer this question.
This is not to comment on your abilities. Rather it is to give you a dose of truth. I truly believe that there are many people like you who can program an entire kernel but can't even solve fibonacci recursively on a white board. Despite this I can't stop judging you based off of the white board question nor do I know how to confirm that you can write a kernel despite lack of ability to solve very very basic programming questions.
I am major in computer science, and published paper in top conference. Tree traversal is trivial for me. So I guess I have decent CS background and knowledge?
Writing bug free and perfect code is not equal to simply solve the problem. If you have prepared coding interviews (especially for new grad and internship), you should understand it is less about knowledge but more about practicing and memorization for that specific purpose. The time spent on it is almost a waste in the future.
If the interview is knowledge based or problem solving oriented, I am all for it. Sadly, it is not today in many places. And that is exactly why website like Leetcode exists.
A published paper in a top conference only happens through political connections in undergrad it is not a marker for your IQ which is what a company like google tests for.
The interview is not just about writing bug free code it is 100% about solving a problem you haven't seen before. Google specifically tells their interviewers to avoid "canned" problems that are already all over the internet.
>If the interview is knowledge based or problem solving oriented, I am all for it. Sadly, it is not today in many places. And that is exactly why website like Leetcode exists.
The interview is about both. You are given a problem that they expect you have not seen before and you are expected to solve that problem using raw knowledge and problem solving skills.
Leetcode isn't about memorization. Leetcode is training data used to optimize your neural net to solve problems it hasn't seen before.
> Google specifically tells their interviewers to avoid "canned" problems that are already all over the internet.
They did a pretty poor job on this already. And it adds one more requirements, the ability to pretend that you have never practiced a similar question before :P.
> Leetcode isn't about memorization. Leetcode is training data used to optimize your neural net to solve problems it hasn't seen before.
Oh. Thanks. Glad that Human brain does not need that much data like today's neural net.
And there are millions of ways to improve problem solving than repeating BSF/DFS/DP templates on Leetcode questions.
>They did a pretty poor job on this already. And it adds one more requirements, the ability to pretend that you have never practiced a similar question before :P.
This is solved by throwing multiple interview questions at the person that are all novel and not derived from the internet. The probability of ALL questions being seened before is very low.
>And there are millions of ways to improve problem solving than repeating BSF/DFS/DP templates on Leetcode questions.
So? Doesn't change the effectiveness of leetcode in passing an interview and displaying your ability to learn and solve novel problems. If you have other ways of passing those interviews outside of leetcode, that's great. Use it.
> This is solved by throwing multiple interview questions at the person that are all novel and not derived from the internet. The probability of ALL questions being seened before is very low.
This is solved by adding more questions into Leetcode. 1000+ and counting.
> So? Doesn't change the effectiveness of leetcode in passing an interview and displaying your ability to learn and solve novel problems. If you have other ways of passing those interviews outside of leetcode, that's great. Use it.
You missed the point entirely. My argument is that many interviews are not designed for problem solving but practicing and memorization. And this is exactly why Leetcode ensures you to repeat these template 100 times effectively.
I do not plan to pass this kinds of interview, before, now or the future. So why do I bother?
Good luck on your job search anyway. I have no intention on discouraging you to do the practice. I cannot fix anything here.
>This is solved by adding more questions into Leetcode. 1000+ and counting.
I know people who did 500 LC problems and couldn't get in google and people who did 20 and got in. The problem set on LC is too large for memorization to work. Google will be giving you problems that aren't on LC and they are actively testing for raw intelligence.
>You missed the point entirely. My argument is that many interviews are not designed for problem solving but practicing and memorization. And this is exactly why Leetcode ensures you to repeat these template 100 times effectively.
No you missed my point. I've talked to those google interviewers, they are not testing your memorization skills that is not their intent. The amount of algorithm problems available in the universe far exceeds that which is available on Leetcode. When you interview at google the questions are designed so that you've never seen any of them before. Get it?
From Gayle Lackman. The test to my knowledge involves both raw intelligence and computer science knowledge.
A lot of startups that forego the whiteboard problem with just a conversational interview or take home problem are putting significant less emphasis on raw intelligence.
Gayle Lackman is lying though. Well that’s a strong word but there really isn’t any other way to put it.
Their interview process does not test intelligence. It may require some intelligence to pass (meeting Gayle’s stupid criteria that “some people are not intelligent enough to pass”), but having a high IQ is not sufficient, nor necessary.
I’ve seen in your other comments that you’ve let them convince you that you are too stupid to hire you. You need to disabuse yourself of that notion because their interview process does not test intelligence, it’s just a heavy algorithms/ds process that allows thousands of mediocre engineers every year into Google’s payroll and rejects an order of magnitude more highly competent engineers that did not have the time and/or motivation to prep leetcode bullshit.
> lot of startups that forego the whiteboard problem with just a conversational interview or take home problem are putting significant less emphasis on raw intelligence.
sigh. I don’t really want to try to spell this out anymore, but a take-home assignment provides you significantly more material to examine someone’s intelligence. The reason Google doesn’t bother is because it takes more time to administer and poor saps are willing to throw themselves at the machine to see if they can slip through. If Google didn’t receive 100x the job applications they required, they would certainly fix their fucked process super quickly.
>I’ve seen in your other comments that you’ve let them convince you that you are too stupid to hire you.
Nobody convinced me. There is a reality here I have to face and more importantly YOU have to face. A lot of people can pass that interview, I can't. The conclusion is unescapable. There are tons of engineers who HAVE practiced leetcode problems who Can't get in. The practice process is not a huge deal, three months of leetcode grind for half a million in TC is worth it, yet this isn't enough to pass for many, many people. No doubt there are tons of people like you who think they are good but can't pass so they blame the google interview process.
>Gayle Lackman is lying though.
Highly, highly unlikely. You have to look at the incentive to lie. For Gayle Lackman, to lie is acting against her incentives. She is no longer employed by FAANG but now promotes her website and book for cracking the interview.
If she says that there are engineers who can never get into google no matter how much they study then her book is useless to a lot of people. Why would she resort to a lie that will decrease sales of her book? She won't. She is not lying, she says something that may decrease sales of her book because she believes it's the truth. You may not agree with what she says but it is highly, highly unlikely that she is lying.
>sigh. I don’t really want to try to spell this out anymore, but a take-home assignment provides you significantly more material to examine someone’s intelligence.
A take home assignment is a highly inaccurate test if raw intelligence is the factor that needs to be measured. First off each interviewee will now have access to unlimited resources and almost an unlimited amount of time. The thing that can't be measured is what resource was used and how much time was used to complete the assignment? Some interviewees used no resources and less time and invented the solution out of thin air, others looked up a way to architect a solution and spent a huge amount of time getting it working. This variability cannot be measured and therefore is a bad measurement.
Even if knowledge and skill is the thing being tested for here, the take home test hides this. Someone may already have the knowledge required to do the take-home test others may not. If both people don't have the knowledge to pass the assignment than you are simply testing their internet search skills.
> 'A published paper in a top conference only happens through political connections in undergrad'
Which fact in and of itself ought to show just how rigged the whole system is--when people can get papers published in prestigious journals merely on the strength of "whom they know."
When interviewing for places like Google and Amazon, your political connections and things like publications/degrees still matter a lot. Good performance on the interviews can be impactful but it's not the only factor. The incredibly biased committees review a lot more than that at google.
Maybe a better way to put it is, the whiteboard problem itself is a pass or fail question and therefore that aspect of the interview by itself is unbiased.
At google some candidates who failed all their interviews were hired because they had connections to upper management.
Here at Amazon, if the candidate knows the hiring manager and interviewers they can be fed all the answers. Not being able to code fizzbuzz doesn't block people from getting 350K+ offers. It's insane. Amazon tried to fix this problem with "bar raisers" but it doesn't work since humans naturally follow the crowd, even if the crowd is corrupt.
> 'I can't stop judging you based off of the white board question nor do I know how to confirm that you can write a kernel despite lack of ability to solve very very basic programming questions.'
You phrased this as two parts, but in reality these two things are intricately linked. It's because you don't know how to judge person on their true ability--i.e. that you lack this skill--that you resort to useless trivialities like this whiteboard bullshit.
Combine survivorship bias (you were subjected to it and made it, so that validates the process) with heavy hive mind group think (We're All Real Smart People, Much Smarter Than Them Masses(TM))--both of which are always in abundance in intelligence-owned front 'companies' like Google, and of course you end up in your present mindset: arrogantly and naively selecting for people exactly like yourself; people who think just enough into things to think you possess a clue, while in reality, being totally oblivious to larger thoughts and concepts.
There are many in this world who just can't stop judging you based on your shortcomings and limitations. For example: your owners.
>Combine survivorship bias (you were subjected to it and made it, so that validates the process)
Let me spell it out for you so that we are on the same page and my Bias is utterly clear:
I Do not have the intellectual ability to make it through the google interview process. I consider myself to be a an excellent coder but I cannot pass their process. I also believe that the majority of programmers at google are smarter than me.
There. This is the ultimate form of unbiased judgement, a judgement that marks yourself as inferior. Google creates interviews I cannot pass, do I use bias to disparage the interview process or do I take a neutral viewpoint even when the neutral viewpoint says something about my own abilities?
If you can't score 200 points on an IQ test, is there something wrong with the IQ test or is it you? Which form of judgement are you taking here and which form of judgment am I taking and who is MORE biased?
If anyone is biased here, it is You.
>You phrased this as two parts, but in reality these two things are intricately linked. It's because you don't know how to judge person on their true ability--i.e. that you lack this skill--that you resort to useless trivialities like this whiteboard bullshit.
You assume that if you wrote what I wrote it would be a form of survivorship bias. This is a common mistake. How you interpret other people is a reflection of your own qualities, weaknesses and biases. You would suffer from survivorship bias if you were in my (perceived) situation and you chose to project that quality onto me even though I am possibly one of the least biased people you could meet.
To be unbiased is to have the ability to swallow uncomfortable truths. You'll know if you're such a person because you'll generally be unhappy. Such an ability is rare. I believe I have it, but make no mistake. It is a curse. The world is a dog eat dog shitty place and most people get through it happily by painting illusions around themselves. To see the world in raw untouched form is to wade through a lake of shit everyday. Better to say the google interview process is dumb than to admit to yourself that you just aren't google material.
You inject many assumptions into what I am saying. What you don't realize that I am in complete agreement with your above statement. Nothing was said to the contrary.
I Don't know how to judge a person's true ability because I lack that skill. I admitted this in the original statement but your blindness completely masked this meaning from you. You aren't hearing what I am really saying:
I am saying that No one has the ability to perfectly judge another persons interview ability. We must use unbiased statistics, metrics and methods of measurement to arrive at a good outcome. There are tons of good programmers out there that can program that can't do whiteboards, but there are much much much much less programmers that can do whiteboards but can't program. Thus if you pass an unbiased coding test that means you have a much much higher chance of being a good coder and possessing genetics that make you more intelligent than the person who couldn't pass it.
This makes the whiteboard interview the Best most unbiased process we have to judge other people. Note that when I say "best" I just mean that it is the best we have despite the fact that it's just not a very accurate way of judging people. Whiteboard interviews aren't that great, it's just better than any other method we have.
Using a conversation or a Design discussion to pass a person in an interview is not a measurable metric. It is subject to all kinds of biases. For example, this very conversational thread you assume that I am a survivor of the google interview process. The conversational format and your biases made you blind. Guess what, if you gave me a whiteboard coding interview, you'd know for sure but you made an assumption and instead wrote a response that demonstrated how completely off base and biased such interview processes without whiteboarding can be.
The most unbiased measurable way to detect if someone can program is to do a whiteboard interview. Most other data in an interview gleaned via conversation is subject to bias
"This makes the whiteboard interview the Best most unbiased process we have to judge other people."
Nonsense. You can just give an SAT style IQ style test loaded with algorithms questions. Far more fair and objective than the biased human interviews we have right now. From my experience on the interviewer side, a lot of good people are rejected due to bad interviewers and the arbitrariness of the process, and many incompetent people are accepted due to the biases of the interviewers. The average Googler isn't as smart as you think. Of course a written IQ test still wouldn't be perfect, but nothing is.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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
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 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 :-)
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).
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.
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."
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.
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.
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.
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.
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.
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.
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
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.
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".
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
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
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.
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.
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.
In addition to all of the very dystopian examples given in this post, there are other non-technical, super-dystopian things that have been popping up as "trends" in the tech industry.
Ever heard of top-grading? It's the most oppressive interview technique of all time. A series of grueling multi-person interviews. A retrospective of all work experiences since high school. You also have to get multiple prior employers as references. Apparently top-grading is used to weed out "liars". Imagine what kind of place optimizes to find liars; maybe one with a problem with a lot lying? I've heard Twitter uses this technique (or did last year when my friend interviewed with them).
My experience as both a 50+ hiring manager and as a candidate tells me that we are collectively living in an illusion of whacked up expectations.
Yes, it's super hard to hire good people, but most of the time it's because "good enough" isn't good enough anymore, and while we may think our company is a 9 and we deserve 9s, we are probably more of a 4 based on what people are actually working on.
Yes, interviews suck, but that's because we all want to get paid the big bucks so we can afford the prohibitively expensive COL and actually do better economically than our middle-class parents. My background and resume legitimately qualifies me as a 9 on the high end, but really I'm probably just a 4.
Cascading causal relationships thus expand both upwards into the capital markets and downwards into your grocery stores.
If we can all take a chill pill employers+employees and stop 49er'ing around so hard, then I think most everyone can be happily employed.
I don't see us getting there on our own though, since that next door neighbor ain't gonna stop and I'm sure as hell not getting left behind /s.
I hope we can find a bit more maturity in our industry, but I'm not holding my breath.
>we are collectively living in an illusion of whacked up expectations... it's super hard to hire good people, but most of the time it's because "good enough" isn't good enough anymore
So much this. When hiring in this field, people seem to expect candidates to know anything and everything software wise, yet reality is software is more complicated than it ever has been.
The problem isn't alone to this field however, it's fundamental to all fields and the progress of civilization. Discover or invent something new and suddenly everyone else is illiterate about it and must learn it. The build up of knowledge is so immense that we don't expect any one person to know all that there is to know in society, hence why people specialize in what they do. It's why doctors have areas of expertise (feet/skin/teeth/neurology etc), why engineers have areas of expertise (mechanical/electrical/nuclear), why doctors aren't expected to know what engineers know. Why physicists aren't expected to know everything that chemists know, etc...
The software field is just a rapid microcosm of this progressive knowledge problem as software is invented at rapid pace. Yet some reason people seem to expect potential candidates to know everything...
This will be a bit of a tangent, but I think that level of specialization in the medical field exists because their jobs are mission critical. You can kill someone if you don’t handle your part right. The advent of the fullstack developer as the norm is because most of us are not doing critical things.
Companies need to be honest about the reality of their product. You’re building a straight forward web app most of the time, you know? You might not need that Stanford CS grad. If companies feel the ‘need’ it, it’s just aggrandizement and a very bad trend for this industry.
> we are collectively living in an illusion of whacked up expectations. Yes, it's super hard to hire good people, but most of the time it's because "good enough" isn't good enough anymore, and while we may think our company is a 9 and we deserve 9s, we are probably more of a 4 based on what people are actually working on.
You're essentially implying that companies like FAANG can get by just fine, even if they hired "average" programmers, as opposed to "exceptional" ones. If this were the case, they wouldn't need to pay anyone 250-350k compensation either - they can just hire some average programmer for 70k and call it a day. Or better yet, hire someone in a country with much lower COL, pay them 30k, and everyone walks away happy.
I don't think this is true, for the simple reason that companies are far too greedy to pay people 200k a year, unless they really need to. Do you honestly think that a company like Amazon is going to spend hundreds of thousands of dollars on someone, if they can get someone else for a fraction of that? Maybe I'm wrong and one day, some startup will grow to be a unicorn while paying their developers sweatshop rates. I'll believe it when I see it.
I think FAANG has too much money, so they try to solve all problems with money, which could otherwise be solved with better planning, allocating more time, changing the mindset and/or better understanding the problem at hand. That might explain why they pay hire salaries than the rest of the industry.
I don't think that there is necessarily a causal relationship between the salaries and the competence, but that line of thinking is common in those companies.
You radically overestimate the difficulty of the work performed by the modal SWE at Google. A bright-but-not-exceptional high schooler can do the usual job: writing code and tests and the occasional design doc, and way too much proto to proto work.
It is absurd to think that any more than a small fraction of the 20+ thousand engineers at Google are "exceptional". When you get to those numbers you are just seeking warm bodies to push buttons.
If you could choose between solving hunger, curing cancer, colonizing other planets, or working for a rent seeking ad buisness, the latter would have to pay a lot more for you to work there.
Dear God, I wish companies were run like this. Everyone refers to these faceless "companies"...no, you are being hired by employees just like you who almost always overpay for staff. They overestimate their ability to assess talent, HR usually link their own salaries to the people they hire...it is a shitshow.
Look at CEO pay, most CEOs are clueless. They are way overpaid. Google is a perfect example, that business is a cash machine, it could be run by a ham sandwich, and they are paying people $100m+ to run it...lul. Jokes.
Btw, this also shouldn't matter. If your business relies on hiring these 1 in 1000, super-smart individuals (ignoring the fact that it is statistically impossible to actually do this if you are hiring thousands of programmers), you will fail. Every time. You get into a bidding war, and your budget depends on the intelligence of others to not overpay. If you can work out how to turn average employees into good ones, you will print money because no-one wants average employees...supply is infinite, you will never overpay (I know companies that have done this...they usually end up acquiring the companies that hire the "boffins" and fire everyone on day one).
In tech, the opportunities for this are basically limitless. It is pretty easy to teach someone how to code, the main challenge is really all the stuff you learn "on the job"...and guess what? You have a job to teach them. Why doesn't this happen? Try telling a coder he has to help a junior guy out one day a week and stop fucking about with Haskell/burning cash. Try telling HR that you want to hire unremarkable people. Try finding an executive who wants to work somewhere where they hit singles...he has an MBA you know, he swings for the fences every time. You are vastly overestimating, ironically, the intelligence of most people who work in companies (I worked in equity research for a while...Buffett's dictum of a company that could be run by a ham sandwich has much wisdom).
Having helped non-cs managers hire for technical roles, I feel your pain. Usually I start getting worn down around candidate 5-10 for in person interviews, and stop looking for colleague grade employees and more for "yeah, I could train them". Nowadays I've tried to tailor my interviewing style more in that vein; I ask for their approaches to problems I don't expect them to be able to solve alone, and then try to guide them towards a solution. I judge them based on where the conversation lands on the lecture - coworker spectrum.
What qualifies as a 'colleague grade' peer? Do they need to know your specific set of technology choices and be able to solve problems specific to your business during an interview that has essentially developed as a skill by those working with your group for a long period?
Technology is so diverse anymore and so dependent on specific sets of technologies a business chose mixed with internal work tailored around a specific business and its processes/problems that I think it's completely unreasonable to expect someone to walk in and solve the specific types of problems under the specific constraints any arbitrary group is faced with--especially in the span of an interview.
All these factors mix to make very unique problem spaces. Factor in that positions evolve by folks who formerly filled a role and that their specific set of skills are likely unique. You should be expecting to train people from the start to some reasonable degree unless the role is doing incredibly vanilla work (in which case I find it hard to believe there aren't qualified candidates).
Probably, I think 'colleague grade' peer refers to candidates that have worked on the same problems with the same technologies and arrived at the same solutions as the people working at the company.
I agree that there is definitely a bit/lot of tunnel-vision that happens within companies where they don't realize how much cumulative knowledge is just specific to the particular evolutionary path of their development team.
IMHO, so much of success is based on ability to learn that it would be better for candidates to be evaluated on their ability to acquire new skills or integrate new knowledge.
These days, we are surrounded by so much complexity that I'm getting quite often the experience of having to delve for a week into a subject so that I can start to appreciate which solutions are the most appropriate ones for the problem at hand.
(And then a few years later I realize that quite a lot of that was still wrong, but at least I picked among the best solutions rather than the worst - see also the "getting on the latest fad" kind of mistakes...)
A past employer of mine was developing their interview process and began introducing a hardish CS basics form to fill out. My answer was the same as yours "it feels like you're hiring for theoretical geniuses, but really most of the work is web dev/bugfixes/feature adding" i.e. you have to mold your interview process around the skills that are actually needed
Yet, the people who pass the grueling gauntlet will still be dumped on a fringe feature team with a first- or second-time engineering manager within 2 years of your age, and a PM that's fresh out of college (or worse, just finished MBA) who is spending 100% of their time learning how to use Jira instead of how to build product.
Oh this trend. I sit next to a recruiter at a large company that literally vets college grads all day for PM and scrum master positions. Like people with zero experience dealing with deadlines, requirements, resource management, time management, release cycle experience.
Oh, and I’ll just leave off ‘software development’ experience from that list too, since they also all come from non coding backgrounds.
What’s the rationale behind this one, anyone got anything? I’m stumped.
That’s what I don’t get - they spend so much time hiring for these narrow skill sets and then the guy next to you takes longer than five minutes to figure out Jira.
Not sure if they were using this exact method, but I did interview at a place that had a long, grueling process (series of interviews, coding challenge, etc). They also asked for every employer back to high school, as well as contact info for supervisor for all of those jobs, which of course was ridiculous. I did enjoy seeing them taken aback when I provided that information and, despite being in my early 30s, having 20+ jobs listed that included things like "fruit picker," "janitor" and "waiter at gay bar". I blew away the algorithmic coding challenge, mostly because it was a take-home test (I have flubbed some white-boarding ones pretty badly).
The company was almost entirely men, many with quite obvious and malignant ego issues. Their method for making technical decisions was to get all ~20 of them into a conference room and argue about how things should be done, with the loudest, most forceful arguments tending to win. The entire time I worked there, the socially dominant clique was primarily concerned with moving their stack into Kubernetes, despite having almost no traffic that I could discern. I wouldn't say I was impressed overall, people who didn't fit the mold had little chance of making career progress, and I personally felt I had more experience and could code circles around the majority of them.
Also other trends that, thankfully in my experience, have not yet made their way to tech. I suspect it is only a matter of time, though...
A lot of non-technical positions I have seen and heard about (including non entry-level positions) require a video of the candidate to describe themselves and why they would be a good fit for the position. That just sounds awful to me.
One company said I had to make a video of myself..and then the final interview would be singing a song of my choice in front of the entire company through video conferencing.
This was for a software engineer position. I didn't even bother going on the interview. I feel like the purpose was to see what they could get you to do.
You'd think this would be a massive liability seeing the candidate's race, sex, attractiveness, etc. Unless that was the intention so that they could optimize for specific demographics they want to hire for - even if it is illegal.
For some people maybe not. A video would be far more stressful for me. I'm sure my voice would be up an octave (along with my blood pressure) trying to get the recording just right. Speaking aloud is also not my forte.
One benefit of a cover letter is it is easier to re-use the base story and update the details as appropriate. Unless you want to spend time editing (which depending on your skill impacts the quality) you have to re-record the whole thing.
I find motivation letters to be stressful too and an emotional rape 99% of the time (I just want a job). Hence my question, a video would be just a tiny step lower in happiness compared to a letter.
well adding the visual element just introduces another source of bias.. and even if we set that aside, depending on the position it may be selecting for an irrelevant skill
cover letters are terrible anyway. the signal to noise ratio there must be comical.
What worked for me, after my boss just put up a stock ad and got hundreds of replies then decided that they couldn't cope and handed the problem to me. First spam all the applicants and say terribly sorry there's been a transition in the team and now I am in charge. Enclose copy of new ad, in email emphasise that I have tier CV and want ~100 words explaining what they understand about the job:
- ask for a very specific thing in the cover letter. In our case, which version of the specific IDE they were familiar with.
- specify that we care about relevant skills, and having the legal right to work here. nothing else.
Of the 50-odd responses who survived a 10 seconds each filter (ie, did you answer the question), I skimmed the CVs and picked 10 I liked and 10 more I thought would be ok. I did this via a 5-bucket sort - as I read each email I dragged it into a numbered folder. Then I created folder 1a,1b and put 10 in each. Sure, that's about an hours work but it's easier than doing an online test and trying to make it non-gameable.
Interviews were a five minute chat then we dumped them in front of a computer with our development setup on it, and a series of programming tasks. Starting from "this button. Make it so when the user clicks it a dialog pops up saying 'click'" and going up to "there is a memory leak in this ~100 line command line program. Find it and fix it". They were asked to talk me though what they were doing, and while most problems followed each other from the same based, they started with a "perfect" solution to the previous ones at each step so that we didn't deviate too far.
I was pleasantly surprised at how effective the "brown M&Ms" question was, and how predictive the series of programming tasks was.
I wish I had answers. I don't - I just know that cover letters aren't it.
I've been on both sides of hiring at this point. On the applicant side, I have never seen any indication that anyone has ever read my cover letters. Writing them is a chore. And though my sample size is very limited, I have never had success with bespoke cover letters/cold emails/etc.; the time has always been better spent on reaching more people.
On the hiring side, I've read a few cover letters. Nothing has ever stood out. I read it over once and that's that. Honestly I feel like it can only hurt you. What kind of powerful, moving statement could you possibly write that would persuade someone to give you a chance when you otherwise had none? I'm sure it's happened, but to force people to write these things at the cost of millions of man-hours, just to cover this absurdly rare and mythical case? And on the other side, there are so many things you could do in a cover letter that would give a _negative_ impression. Maybe the tone is inappropriate, or there are inadvertent grammatical errors, or it's written poorly, and on and on and on. Just more exposed surface area for the naturally critical interviewer's mind to attack.
I have a pretty long resume at this point (23 years now in the workforce)... I use the cover letter to try to summarize a few takeaways using very short sentences. It seems like if you don’t hit at least one positive talking point within the first 5 seconds of reading they will never bother reading the rest of the resume. I once actually did step into recruiting at a startup I worked at once. We had about 25,000 emails come in for 20 positions and the recruiting team was going insane trying to sort them. I wrote a few quick filters to draw out interesting resumes but I ended up reading nearly half the resumes... over a weekend. I get that reading resumes is tedious but I just have so little sympathy for these people who have so little attention to detail / ability to structure their work passing judgement on my ability to conjure some algo.
Often I think all these (cover letters are not the only artefact) are just postural items to see who's gonna make the effort no matter what use it has. A kind of faith leap.
I would do it for one or two companies. If you can be hired by the first company of your choice, you don't really need it.
What about providing a proper job description? Without it your company is a "maybe", till I talk to an engineer who can describe the job properly. Would it make sense to write a cover letter after that?!
Been through that one time, I should do more of those and just sing Merry Christmas for fun, ideal for wasting time and potentially lighten up the day of the other person who had to watch/listen to these nonsense.
I've had that exact thing happen to me once, and it was for a developer internship position no less. This type of stuff might be coming, at least where I am currently.
Great way to weed out older developers, since there's a good chance that some of the companies they've worked for have gone out of business or been acquired, and some of their references have died.
A few words on top grading. We are use a top grading like process, and are pretty flexible on the references part of it. It is just a long conversation. I think it is a structured and simple way to talk about a person and where they have been. Yes, it is comprehensive, but it works well. We hire almost all candidates that have made it to the top grading stage of our hiring process. We don’t use it to find liars and don’t think of it like that. What it really is good at is finding patterns of behavior in someone’s life and work history. It’s not full of campy dumb mental problem questions. You just talk about yourself and your work history and how you relate to previous colleagues and managers. And it’s done consistently to make it a little more comparable from one person to the next. The reference checks are one of the most useful and valuable parts of the whole process (we are flexible here, we are a small company). I can see how this process could get morphed into something less friendly, but at the end of the day it’s a huge time investment for us and the candidate so we don’t embark upon it lightly. I haven’t found a better interviewing technique that takes the pain out of it for the employee and the employer. Our team all appreciated the process and we take their feedback seriously. We don’t follow all of the steps in top grading religiously, but the interviewing process is really good. We also read a lot of other books on building a hiring process and settled on top grading as the most consistent and logical. The few people we didn’t hire threw up major red flags in their interview process in terms of how they would fit in at the company and the work we do. How else should a company hire people? For a small business we try to de-risk the hiring process as much as possible because mishiring is /extremely/ painful. We have grown from 3-20 people organically. Each hire we made was and is very important to our growth and stability.
Edit: just wanted to say I am a partner/founder at my company and we deeply give a shit about what we do and who we work with. Our turnover across 7 years is very, very low. We strive for a good work life harmony with everyone that works with us. You have to have some process to fit people into a company and that means you gotta talk to people and get to know them. The goal is to eliminate interviewer bias as much as humanly possible after the technical screening. So it goes. Not everyone can be pleased and I would defend our hiring practices as very reasonable and humanistic in an otherwise crazy tech interviewing system at the FAANGs of the world.
What you do sounds like a reasonable interpretation of top grading. It's also what I'm used to, largely.
Where it gets tricky is with people like who are older and have "done interesting things". I did short contracts for more then a decade and interspersed them with cycle touring. So my full work history is a thing of joy and beauty, but asking me to go through it and re-locate one person from each company, contact them, and get a reference... you've just asked me to do 100 hours work at the very least. Even leaving out the non-technical jobs only halves the number. When a major bank wanted a list of every place I've lived for the last ten years they eventually decided that "no fixed address" was acceptable.
But I expect that if I applied to you and said "here's the last ten" you would be happy with that. And FWIW I have a number of quite enthusiastic referees available on request.
We just want two references and a warm introduction to them. We pick what we think is the most relevant recent experience and negotiate from there, being sensitive to availability etc. Doing it for every job and asking the candidate to do it is kind of lazy in our opinion. It’s just a logistical chore to set up a meeting. All we need is the intro for context :)
So, do you actually ask the candidate to arrange calls with ex-managers and conduct these calls for all previous jobs? What does it mean that you are "flexible"?
We generally ask for two references and a warm introduction to each reference. We take it from there. We aim for more recent references. Doing it for all previous jobs is overkill and time consuming. The feedback is generally candid and useful. In some cases (limited work history) we only follow up on one reference. In others the best reference is also the current employer so that obviously can be tricky. The spirit of it is indeed to validate the interview process but also to gain a different perspective.
I think it's important to understand that you're asking candidates to burn "social capital" by arranging those introductions. I've worked for pretty high end people (successful founders, ceos...). I'm not going to call in any favors from them for a job interview. Most senior people feel the same way. Don't ask your candidates to expend their own personal or social capital.
It feels like even a fairly benign implementation of interviewing references wouldn't scale very well. It's something I might impose on a couple of people I knew well once for a special opportunity but expecting them to repeatedly do this for a bunch of companies using this process seems unreasonable.
And as others have said, while I could provide references going back quite a few years, it definitely wouldn't be every job since high school--even every professional job.
We tend to only ask for two references and it is negotiable. References from the distant past aren’t useful because our goal isn’t to “find liars” as some people suggested. It’s to get an unbiased perspective from someone other than the candidate. FAANG interview system takes way more man hours per candidate than our system.
I think this makes it overly difficult to fully vet candidates. Like I wrote before, we have had long discussions with our current team about our hiring system and the feedback is overwhelmingly positive. We try to take care in the whole process and honestly, if someone feels what we are asking is too much, they don’t have to complete the interview. We explain the steps up front before anyone commits any time or “social capital” to our process.
If only people who agree to it make it through, then I'm not surprised the feedback is positive. What you're missing is all of the senior people who would never do this (which is a lot of them).
I'll also add that it's not hard to vet candidates. I've hired dozens and dozens of great people and never ask for references. Interviewing is a skill all managers should develop and excel at.
What is your take on "bad hires"? bitexploder said those are very difficult to deal with, but I'm not sure it has to be. If someone lied significantly during the interview and it came up later that's pretty easy to fire that person later.
I find that I don't get very many "bad" hires. It's pretty easy to tell if someone is a good developer or not. In the rare case that someone bad slips through, it's easy enough to fire them. That's only happened to me a couple of times though. It's not something I'd optimize for.
We used their website/web app for a while but didn’t get enough value out of it. We had a hiring consultant / coach teach us about top grading after going through many other books.
https://www.goodreads.com/book/show/915182.Topgrading Is the best book on it. I would just say to use common sense when reading it and think about how you would feel in the interviewees shoes. There is also top grading for sales which has some good stuff in it too. We don’t collect detailed salary info (legal minefield anyway these days). We usually just do one interview and not multiple. There are decent videos in YouTube. They try to sell you on their website and branded materials, but it’s pretty simple for a small company to keep it light and in text documents or whatever you prefer.
No problem. Ultimately I think the hiring process and what it becomes at large companies will reflect their values, for better or worse. They often start off with good intentions, but unchecked hiring processes can become very cynical and, well, Dystopian, as the parent article points out.
Generally, yes. https://carvesystems.com/careers — we are an information security consultancy. Our tech interview is a take home test similar to a CTF. It can be somewhat time consuming for someone with minimal infosec experience. Just check that page out and shoot us an email (and mention you are from HN, and I can chat further with you if you are interested).
Personally I'd call off the interview and let them know they need to rethink their hiring practices. If that's how they interview the company probably is horrible to work for anyways.
> If that's how they interview the company probably is horrible to work for anyways.
If the hiring process seems designed to find the very best people who are willing to put up with being abused, yeah, it seems pretty likely that it's a horrible place to work.
Yes. What's amazing, these incredibly bright people that are being subjected to torture.... Wait, wouldn't the incredibly bright tell you to take your process and shove it?
The incredibly secure would tell you to take your process and shove it. I'm not sure to what degree "bright" and "secure" correlate. I suspect that they may do so eventually, but I think many bright young people are still insecure with respect to jobs and employment.
Heh. Someone was recruiting me a few weeks back. The company/position looked somewhat interesting but, as we talked, it turned out that what they were looking for wasn't quite my core skill set though I could probably have done it. At the end of the day, it was much easier just to say not a good match at this time so both of us could move on. If I were really looking for something, I suppose I would have felt the need to pitch myself more for the position and have them say no.
For science I tried an blatant lie, and it was the most horrendous experience I ever felt regarding work. I was gutted and never want to do it again. But factually, I don't think it mattered to them, it was just smalltalk to them. Although I'm not 100% sure they didn't see through.
Oh and ironically, some recruiters casted doubt on very factual and true parts of my resume.
Twitter uses what they call top grading, but really isn't, it's just a 1 hour reverse chronological set of questions through the most relevant/recent of your work history, asking the same set of defined questions for each role you had. Really just a structured way to understand your history in a consistent way. It basically the same as asking someone about their work history, but in a structured way.
It is absolutely definitely not the actual top grading of multi hours of interviews , phoning references etc.
Comedian Daniel Tosh had a bit about people that claimed to be smart, it's just that they were just bad at taking tests. He said, "oh, so you struggle with the part where we find out what you actually know?"
I hear a lot of complaints about the "typical" software engineering hiring process, and it usually comes from the people that don't do well within the current system. Could the process be improved? Almost certainly, I don't think that anyone thinks that this is an absolutely perfect way to hire people. But it is an undeniable fact that some people pass this interview process; software companies do fill positions with this process.
So that kind of makes me think that many of the complaints are from people that wouldn't cut it at a high-pressure tech company and would be better off coding internal software for a non-tech corporation. I'm sure that the hiring process at Kroger (the grocery store) is much lower pressure than Google's. Google might not need you to code some efficient algorithm to search a b-tree every day, but they pay top dollar and can rightly expect that their software engineers can come up with efficient and creative solutions to hard problems without dragging the rest of their team down.
People are completing 500+ problems on leetcode before heading into interviews at google. Don't believe me? Go read the teamblind forums. People might spend six months studying, after which they pass a bunch of interviews and get good comp. Getting just one offer from a FAANG company often doesnt pay well enough, you need multiple competing ones.
If you think this has anything to do with incompetent people complaining, then you arent reading into the situation.
I will add that one can pass these interviews without extensive preparation, but it makes it alot harder when those around you are willing to spend ridiculous amounts of time studying.
Then its working. Big companies love it when people spend time studying for their interview process. It shows commitment and means that person will feel like they "earned" that job, and should stay longer.
This reduces churn, which is the thing they screening out the most.
To the big tech companies, this isnt a problem, its a sign of success.
Think how whiny this sounds to any law firm/medical practice. People spend years studying/preparing/working for free to get an internship. And yet, most software devs are still payed better.
Lol doctors change jobs and get jobs with relative ease compared to us software engineers. They go work part time at this clinic or that clinic quite frequently.
When I studied for my google interview back in 2011 I learned tons of new things which I used professionally at google and beyond. But I’ll concede that it was before leetcode (although i did casually compete on topcoder just for fun) so I mainly read up on areas where I knew I had blind spots.
I'm imagining it's going to bite these people on the backend later in life when they sacrificed everything for their careers and potentially missed other major life milestones: cultivating a relationship, starting a family, etc. I know not everyone spends 6 months getting into Google, but there are so many other companies that will take you without 6 months of preparation. If career is the only thing that gives you meaning in life, sure, but I'd rather not put all my eggs in one basket.
I used to think that until I heard of people with far less experience than me getting paid $400k total comp at these places because they can ace the interview and get competing options. That's worth putting 6 months of work in.
Yeah, once you're in, it's cushy, for sure. But that's not the full story. You're likely going to have to move to the bay area to make $400k kind of money. Are you willing to forego living near family, friends? Plenty of people do, but time gets more valuable when you have less of it left.
For one thing 6 months is definitely the high end of prep time. Even so, spending your evenings studying for one 6 month period in no way precludes you from ever dating or marrying or having children.
This is anecdotal, but most of the people I know at Google and other FAANGs did not spend that much time preparing for their interviews, if they even bothered to prepare at all...
Maybe some people do that - I didn't do a single interview question prepping for a Google interview; just read through the topics they suggested reviewing, looked up the concepts I hadn't seen before, and did the interviews.
having just recently (in the last 2 weeks) completed >100 problems on leetcode i can affirmatively tell you that it's not actually that difficult to game this system. i read elements of programming interviews (took about a month of a couple of hours a day) and then just blitzgrieged leetcode. this was all in prep for a FAANG internship tech screen i had yesterday. it went well (not perfect but well).
but it is true that these questions bear no resemblance to software engineering so it does feel silly going through the process.
The people complaining are usually the ones who can't just prep for algorithmic interviews with a couple hours a day of effort for a month.
Which makes the algorithmic interview a relatively good filter - ability to learn something difficult quickly is a very important skill at high performance software companies.
When you're paying someone to solve problems for 40 hours a week, assessing them based off if they're willing to do that in their free time seems naive. It's surely a safe option, but you'll miss a ton of qualified talent, and potentially not grow fast enough because of your hyper-idealistic expectations for what it means to be a software engineer.
Speaking as a parent, the idea of having “a couple hours of free time per day for a month” to learn difficult new material is laughable, and it has nothing to do with intellectual ability.
Then try 1 hour every day for 3 months, or 1 hour every 2 days for 6 months, or whatever you can fit into your schedule. Do you really have no time at all after your kid(s) go to sleep? I prepared and interviewed with a 1 year old at home, it was challenging but doable. Your situation might be more complex than mine though, I wouldn't know.
How about taking a few days off to prepare for interviews?
I mean, you're going to spend 4-5 hours per day for each of your onsite interviews (plus an hour or two each for recruiter calls, phone screens, etc.), so if you have zero free time, interview prep is probably the least of your problems...
Tosh's joke ignores that people can struggle with recall and on-the-spot test taking stress, while performing quite well at whatever the test is assessing. When studies have been done on interviewing, nothing has shown that inducing stress is ever helpful, unless the interview is for a job that requires on-the-spot stress, such as interviewing to become a police officer.
To me, here is the actual problem that I see cropping up. FAANG companies have enough volume of applications per position that they can afford to have a system that will strongly prefer false negatives over false positives, so they are willing to err on the side of, "We'll just hire people who can pass our realtime CS-grad battery and sadly say goodbye to equally good candidates who cannot." Ok, FAANG companies can do that as long as they are eyes-open about the situation. Where things screw up is that companies that are not FAANG companies do not understand that, and end up aping the FAANG interview techniques when they do not have the same applicant volume. This starves them of talent, and also leads to good applicants getting rejected by non-FAANG companies.
Really makes me sad to see startups trying to compete with the same talent profile as google: as a small company you need every edge and chasing after the same candidates receiving fat offers from FAANG is not the way.
Yep, I think that the guy who you replied didn't work out that it was a joke. I am not really sure how anyone who has spent time in the real world thinks that tests are effective.
Look at Korea. They torture their kids, and are they smashing the world economically? Nope, economy still totally reliant on chaebols, almost no innovation, GDP per capita is actually quite low for such high levels of human capital. I have seen this in financial services...firms that hire teams of PHds get nowhere (one place even has their own postgrad institute at Oxford...still get shitty returns year after year).
I don't think tests are bad at all, I am not saying they aren't useful...but they optimise for stuff that doesn't always work in the real world. And, unf, hiring is one of those things that is just very hard...trying to uncover talent by doing these tests where everyone knows (roughly) what is going to be asked, and people are just preparing with rote study...that doesn't sound like you are actually trying to uncover talent. It sounds like you have decided hiring is hard, and you don't have anyone who can hire...but if you are Facebook and you are hiring thousands of programmers, statistically you aren't hiring the best of the best so...maybe it doesn't matter.
The ability to acquire and apply technical knowledge, and ability to demonstrate random technical knowledge under time pressure, in a foreign environment, while other people are watching and judging you, are orthogonal skills and many engineers are great at the former and terrible at the latter.
There's also a ton of opinion and taste involved in software engineering, which can bias the interviewer's view of someone's technical ability. Not to mention all the unconscious biases against people who don't "fit the description" of a typical software engineer demographically.
The Googles of the world limit their own potential by rejecting many talented people who couldn't make it through their hiring filter for reasons that have nothing to do with their actual ability to build software. Then they express angst over how difficult it is to fill positions. It's a self-inflicted problem, and a hard one to solve. It's probably impossible to design a theoretically perfectly fair hiring process without also solving all causes of inequality in society generally. But it can be made better and more fair than it is, and many companies and applicants aren't satisfied with the existing hiring processes, so they are making efforts to change the situation, as they should.
Time pressure, foreign environments, and people watching/judging your work are all exactly the things that happen when you're developing stuff that hasn't been done. You run into problems. You find out that requirements or an API spec weren't perfectly written and have to deal with change. You have to work with other people, and they will judge you.
Hard coding exercises with a time limit that have an answer that can't be found on Stack Overflow do a pretty good job of simulating real world job pressures in a controlled environment so they can fairly rank order candidates.
The technical interviewers that might be biased against you are either the exact people that will have to work with you, or at least they fit in the same company. If they don't like you during the hiring interview, they won't like working with you.
Alphabet's market cap is literally a trillion dollars, so I'd love to hear about how they should stop limiting themselves and start hiring people that can't finish an ill-defined task with a deadline looming and other people waiting for you to finish your module.
The market will eventually shift and they will not see it as they are not in touch of reality and everyone there are in the same bubble. It will be something you can not fix with money.
But the questions are not "stuff that hasn't been done." They just test whether you've memorized the answer that took someone far more than 15 minutes to find.
On HN, it's not ok to bring in someone else's personal details as ammunition in an argument. That's a form of personal attack and a steep drop in how users here need to treat each other.
https://news.ycombinator.com/item?id=22334315 ("Looking through your LinkedIn/comments is low effort and confirmed my suspicions of you being whatever the inverse of Dunning–Kruger is") was even worse. Please don't post like that here, no matter how right you are or feel you are.
Surely is relevant when the person is commenting on the experience of something when they've never experienced it.
I'm all for dogs on the internet but no point in accepting dogs commenting on the life of cats whilst strongly giving the impression that they too are cats.
I understand the annoyance, but the problem is that we don't have access to anything like the precision necessary to make such calls well on the internet. There is (vastly) too little information, too many opportunities to get it wrong, and the damage caused by getting it wrong is too great to be worth the risk. Therefore it's the better part of valour just to not go there.
Even getting it right doesn't help, because it will encourage other people to pull the same stunt themselves, get it wrong, and cause damage. We just need to not go there as a community.
I never claimed to work at a FAANG company, but I must have hit a nerve if people are going through the effort of looking at my LinkedIn profile and looking at more than the first page of my comments.
Believe it or not, you don't need to have passed the tests or have software development experience to make the observation that people complaining about a process are the ones that don't perform well. I've written and graded many exams, but only ever received complaints from students with C- grades or lower. Funny how that works.
And it's not like software engineering is some magical pony that is different from other white collar jobs. To get into my current PhD program I had to interview with multiple people, take a 4-hour written exam, do a week-long exam at home, and I wasn't compensated for my time. So I'm not that sympathetic to people that complain about tech job interviews.
I've held many other white collar jobs in my career. Software engineering is different, the interviews are at least an order of magnitude harder.
Google knows and admits that their process has flaws and their HR team does internal studies on it. Just because Google does something, and Google is big, doesn't mean what they do is optimal.
> Believe it or not, you don't need to have passed the tests or have software development experience to make the observation that people complaining about a process are the ones that don't perform well
Actually you do.. It's one thing if you are upset about people questioning your credibility, but you are being disingenuous by making blanket statements with 0 credibility or evidence to back it up.
> only ever received complaints from students with C- grades or lower
I'm not sure what this has to do with anything being discussed. Are you implying that people with decades of experience being weeded out by these interviews somehow equate to C- grades?
By your definition, ideal0227 and mxcl are subpar.
> Google might not need you to code some efficient algorithm to search a b-tree every day, but they pay top dollar and can rightly expect that their software engineers can come up with efficient and creative solutions to hard problems without dragging the rest of their team down.
This is a non-sequitur. Being able to write good software has nothing to do with reading cracking the coding interview and practicing leetcode for an interview in an environment that bears no resemblance to how work is actually done.
But hey, that's fine—they just leave good talent for others to hire.
It still tests something. As long as it tests something, it is useful. If the candidates were stupid, they would not be able to play this (intrinsically pointless) Red Queen game.
Google has strong data that it does predict job performance, better than GPA, college degree and so on. What are your aggregate data showing that Google is wrong on this?
Does it? Because their strong data haven't helped them not screw up their messenger space. Or to have a fast email web client. Indeed, they seem to be going backwards on that chart.
They flopped on wave and Google plus, hard. Those are the kinds of mistakes that kill most companies. Even Google glass still somewhat rankles and has left me with no confidence in any of their consumer things.
And I say this as a happy Google fi user. In that I'm not convinced any alternative is worth moving to. Still can't fathom why Android is wasting fully half of my storage for "system".
I'm not claiming they are crap. But I do have a hard time making all the things they do that are beyond the industry. Other than spend a ton of money.
> their strong data haven't helped them not screw up their messenger space. Or to have a fast email web client.
That second example seems to invalidate your whole point, doesn't it? Yeah, they've had flops, but gmail has been an outrageous success, to the extent that more than a decade after launch it completely dominates internet email. I mean, yeah, I'm sure it could be faster (not a user, which makes me painfully aware of how rare my condition is!). But clearly they're doing this product "right" for any reasonable definition you want to use.
Gmail, the client, has gotten noticeably worse as the years have gone on, sadly. It is laughable how long I have to wait for the page to come up just so I can start drafting an email to my wife.
I don’t think those products failed due to poor engineering, google just hasn’t been great at social (if you don’t count YouTube). Other companies which use the same interview techniques are winning in those exact product spaces.
But, then what are they succeeding at? If engineering hasn't helped them not kill most of their products, what is it helping do?
And again, it is more than just social. ChomeOS? Even still a thing? How is android wear doing nowadays?
Again, I'm not claiming they are bad at engineering. I honestly don't feel qualified to judge. But I don't know that they are qualified to judge success of new hire, either. Their main success seems to be to simply suffocate the talent pipelines of the industry by hiring the top talent first. But not by actually using it.
> "If engineering hasn't helped them not kill most of their products, what is it helping do?"
Engineering does not set direction, they just build what they're told to. There are entire product management, market research, and similar teams that help senior management decide what to build. This is the case at most large software companies.
Yes, direction can be set independent of engineering. But a string of failures, at best, shows a string of misused engineering resources. Which just leads back to my challenge of why do they think they know what a successfull candidate is?
I'm questioning if they really know what good engineering is. I'm not saying they are bad at it. Those are two different claims
That they are the default entry to the web is their main asset. Agreed. Their search is good enough, and they are good at monetizing the top boxes of their search results. Really good.
That said, most of their engineering hires are not working on that. And they have a string of unfocused attempts at entering markets that smacks of not having a good sense of how to use engineering in a field. Basically, of they can't recreate the field, they give up. Rather quickly. That isn't engineering. That is just brash spending of money.
Why not both? It was a poor usage of engineering effort to try and recreate a field, instead of leveraging some assets and building on what they actually had.
It isn't like reader died alone. They had buzz going, which did a decent job of linking reader and Gmail. That is solid engineering. Instead, they have constantly tried to recreate Gmail to kill it. Wave? Plus? Inbox? I'm sure there are others.
Not defending Google, but this is dangerous myopia:
> Those are the kinds of mistakes that kill most companies.
All companies make big mistakes and burn lots of money on failed projects. The difference between a medium-sized company and a huge company is that a huge one can absorb the cost of failure, shrug and carry on. Medium-sized one will indeed die.
The difference between a large company and a huge company is that while both can survive the cost of a failed megaproject, for a large company the failure is probably enough to warrant a rethink and change in strategy. A huge company knows (from their aggregate financial metrics, of course) that what they are doing is right and proper, and will take the failure as just one more datapoint.
The moral is that there is no moral. (Or if we're talking business, morals.) Wild success begets arrogance, which begets organisational cargo-culting.
I'm not sure what the debate is. I'm all for changing strategies. My claim is that they don't have data on success from engineering. As evidenced by every pivot they have done being driven as much from marketing as technical.
Chrome, as an example, had a ton of marketing push behind it. Still some solid engineering, but not really any better than Firefox. Wasn't really any better than edge, but ms decided to drop the push for their own tech.
So, my question is what engineering successes do they have to back up their data on what will succeed?
I think you could pull in some of the ml work they are doing. Not sure how much data they actually have there, though.
My understanding is that they stopped asking brain teasers because they found no correlation with job performance. Which is good because for awhile it seemed like other companies were cargo culting questions like “why are manhole covers round”
What is "job performance"? I assume job performance in this case means getting promotions or good reviews. How well correlated are promotions to actual ability? In my experience they are mostly just political.
Google's 2013 study called Project Oxygen says different, "The seven top characteristics of success at Google are all soft skills: being a good coach; communicating and listening well; possessing insights into others (including others different values and points of view); having empathy toward and being supportive of one’s colleagues; being a good critical thinker and problem solver; and being able to make connections across complex ideas."
> But it is an undeniable fact that some people pass this interview process; software companies do fill positions with this process.
This argument is devoid of logic.
We could have an interview process where everyone runs a 100 meter dash and the fastest get hired. Some people would pass this interview process and get hired.
It's obvious that running fast is not a great predictor of success at software development. It's not obvious that passing l33tcode interview questions is a bad predictor of success; but it's not obvious that it's a good one, either.
You haven't made an argument for either case, here. Personally, I don't think it tests for much that Raven's Progressive Matrices wouldn't cover; but that's illegal, because it's too obvious.
I'm bad at taking tests. I'm also bad at playing guitar when someone is looking or even when recording myself (and pretty good when playing without anyone looking). I get anxious and self-conscious and that gets in the way of good public performance. This does not translate to public speaking - I'm pretty good at that, and I'm not afraid of audiences of just about any size - my largest so far was ~1K people.
I somehow managed to get a masters degree from the top engineering school in my country (with honors), and get hired at MS and Google, and a handful of other places, but that was in spite of my interview performance, not because of it. I've also failed a lot of interviews. I literally look and sound like an idiot when adrenalin kicks in, which for me it does at the most inopportune moments.
I very strongly suspect that there are _a lot_ of people who suffer from this. You can recognize them when they on the one hand have an illustrious resume and on the other suck pretty bad on simple coding problems. Those things are supposed to be mutually exclusive, and they usually are, except when the person's blood is full of adrenalin and they end up on the wrong end of fight-or-flight response.
If I spent 7 years as a SWE on high profile teams at Google it's pretty clear I know how to code, even if my interview performance on your Leetcode problem is not excellent. My C++ and systems design will likely be way better than all of your existing engineers, in a non-interview context, just because I've done a ton of both in an environment which expects excellence in both, and won't let you commit code if it sucks. 5 years after leaving I have not worked anywhere where this wasn't the case.
This is not the same, BTW, as "high pressure" usually encountered in the work environment. I can deal with that just fine. And I can code whatever algorithm you like in that environment, no problem. So I doubt a high pressure interview is terribly predictive of performance under "normal" levels of stress, too.
I'm the exact same in the guitar department, play a riff for 5 mins flawlessly, try to record it as a 10 second clip (or even try to put it on a looper), fuck up a couple notes in.
I also interview badly frequently but not due to poor test performance but due to my demeanor in an inherently awkward situation.
As I perform more and more, I realize the hard part is getting out of my own way. I fumble and stutter playing something when I try to think about what I'm doing, trying too hard to make it good.
I'm at my best when my conscious mind doesn't really know what I'm doing, and I trust the musical muscle to do what I feel which produces more emotional, more compelling music
You just described me haha. In my Google phone screen, I fumbled around on solving an easy-moderate problem - so much so that when it ended, I felt that there was no way even I would hire me. And once it ended, I wrote the code for it in probably 10 minutes. Also, arranging it so that it was the first in the loop did not help either. The only good thing about the process was that the recruiter was nice about the whole debacle and did not make me feel too embarrassed.
Reducing the emphasis on thinking out-loud every single one of your thoughts might have helped. I'm not the type of person who can verbalize everything and moreover, it's too slow and prone to errors. Perhaps I should have fought back and asked for the interviewer to be quiet and also let me be quiet for a while.
Also, the absolute requirement that any of your workings should be done only on the shared Google doc seems like an overkill. There are a lot of times when I wanted to quickly note down / draw something on the notebook I had but couldn't.
Unless your job is coding novel algorithm implementations under strict deadlines without a computer, how does answering this question in a job interview prove or disprove your efficacy in the actual position? It only proves you're good at interviewing, which, if you think about it, is not a desirable skill in your new hire 6-12 months down the road.
I see it as an IQ test. Official IQ tests are illegal for hiring of course. So they use algorithms instead. Not justifying it, but that’s the only logical answer I can think of.
Had to look this up, since I hadn't heard of IQ tests being illegal. It seems to me that a domain specific IQ test should be perfectly fine to use.
AFAICT the origin of this is a case from the 70s [1] where it was ruled against the use of IQ tests at a particular company. The reason was that the IQ test did not reflect an actual business need, but it made it harder for black people to qualify.
So making an intelligence test that actually relates to the work at hand, such as testing the ability to design algorithms as a programmer or the ability to comprehend text for a journalist, seems like more than just a workaround, it's a way to actually follow the intent of the ruling.
Just remember that Herbert Hoover was a terrible test taker. His colleagues vouched for his brilliance because they read his previous work and thought he was a genius. It turned out he was the type to spend a lot of time revising his answers until they were perfect, so under any sort of timed test he would fail, including his entrance exam into Stanford.
I'm only sharing that factoid because I find it interesting. Maybe Herbert was a terrible engineer by today's standards. He almost certainly wouldn't be president today for completely different reasons, but would he be have been accepted into Stanford? Would he even make it as an engineer? I don't know--certainly not if we put as much weight as we do on tests.
I’m a senior engineer with 20 years experience, I just delivered kubernetes into production at a Fortune 500 company. We wrote our own provisioner in go and our own controllers and built a system to manage add-ons. I know pretty much everything about running a cluster and have knowledge of most of the popular tools you’d install on a cluster.
I applied for a job at a Silicon Valley company to work on their kubernetes team. They talked to me for five minutes about anything related to my current job and spent 2 hours asking me to solve algo questions from cracking the coding interview. The experience was so bad that I basically am refusing to do any more interviews that require coding.
The hiring process at Google has a different function at a start up. Google needs to weed out hundreds, thousands of applicants and the good jobs people tend to want to stay in. Google needs to filter more than it needs to hire. I don't know why people see being rejected for a job at Google as a testament to their worth as a programmer.
People who see their worth as a programmer in creating good valuable software and are willing to sacrifice a lot for it tend to make startups. People who want to mark their skills as a programmer in receiving a large number of skills and working their way up to the top of the tree tend to join a large corp.
I don't get this comparative, 'my job is tougher' mindset. Resting your families' livelihood on the back of your startup programming skills is as pressure filled as being the backbone of a highly strung project in the heights of a large corp.
When the startup wins, the large corp licenses it. When the large corp wins, it opens an API to the smaller devs. Too much sour grapes around lately.
In regards to the Tosh quote, how many people at FAANG companies are using most of these tested skills in their day-to-day jobs, ever? This isn't about testing useful domain knowledge (except for the handful of people working on core algorithmic problems).
To a point these questions are an intelligence test but I see them mostly as a form of gatekeeping, seeing how many hoops people will jump through to land a job there. Most decent coders COULD pick up the knowledge to pass but not all of them want to, need to or are willing to grind through the test prep stuff just for the chance. And filtering for THAT has value because people won't grind through the process are less likely to hack it being smaller cogs in these behomoths.
I think the biggest value of the leetcode process is to rub off competent programmers who need to feel like their code is meaningful. Obviously many people produce meaningful code at FAANG corps, but working at a huge company means your code has a decent chance of never see the light of day or get chopped after 2 years, or be thrown out in some new broad initiative...
It is an effective filter for finding people who don't need external motivation to keep plugging on ahead. It is an important distinction because those types will likely flame out or start to wilt after a few projects of coding into the void.
It's worse than that, those "algorithmic" interviews are testing IQ, more-so than knowledge. The hard knowledge that is tested is pretty much only the syntax of the programming language candidate decides to solve the interview question with.
I put "algorithmic" in question marks, because those aren't even that hard as problems in programming contests or questions from uni comp sci coursework. For a phone screen with an online doc, it can be even something concrete, maybe implement a simple feature of a text editor (does not have to be as complex as the online doc the interview is in - it's important that the subject matter is easy to understand).
For an onsite interview, it would be something not likely to have been practiced in advance (questions leaked to websites get banned). Still, it would be something that reasonably fits in RAM, so there's no need to use a database or any networking technology (we can discuss those, too, just not necessarily request to use it in code - similarly, it may be taken for granted that the input data will be valid and there's no need to code defensively, the interview duration time is kinda fixed).
But as a policy we don't tell the candidates what their mistakes were, so those who failed may never know what they were up to. Goes without saying, we get to interview software engineers from different backgrounds - physics PhD s, or high-school IMO medalists, too.
I think there's truth to what you're saying, but I also think it screens out a lot of false negatives (which is kind of its intent since they'd rather that than false positives).
For me personally the process gives me a lot of anxiety/fear to the point where I won't do them even when I know I want to. I suspect a lot of the negative sentiment around interviews or talk about their 'ineffectiveness' is just this fear being poorly interpreted.
I think the technical interview process is also just a separate skill to master that has some overlap with programming, but is mostly getting good at leetcode style problems. It reminds me of things like the SAT for college.
There's a lot of failure necessary most of the time to succeed that I think scares people away because they do one and fail and then think they're not good or smart enough. I think I did ten different phone screens and three or four on sites before getting hired by a famous company. Some of those I totally bombed and others went really well - there's a randomness to it depending on the question you get and the specific interviewer.
I wish this wasn't the case and things were better because it'd be really fun to work on interesting projects with different people at different companies, but the barrier to changing is so tedious it's often better to stay put at a local maximum.
I suck at those interviews but here's a few real life job situations I've been in:
- sitting at my desk with the board of directors on speakerphone. They asked questions, I wrote SQL to find answers, while they tried to come up with a way to stop the company going bankrupt. Small company, I was basically the one guy who knew how the database linked together.
- sitting across the hall from a room full of support people while they went completely insane trying to answer the phones, and I tried to stay cool and calm while peer-coding with two others trying to get the system back up and running.
- having literal truckloads of garbage sitting in a queue while I debugged software that linked number plate recognition systems to a weighbridge and boom gate.
- being "that guy" who kept pushing for an early performance test. Eventually we did one. It went spectacularly badly. Some people wanted to blame me, because I was the one responsible (for the test).
In other words, being able to cope with "completely unexpected interview questions" and being able to cope with "code I wrote has gone wrong" are different skills.
> There is a cottage industry springing up around passing interviews
This, a million times.
I was told to practice solving dynamic programming problems to prepare for the interview[1]. Looking around the web I found out that people spending months solving thousands of dynamic programming problems, just for getting a job. This strongly reminds me of the rote learning I had to do in order to get into university, which includes thousands and thousands of integration, derivatives, series, lense placements etc... A nightmare I thought that ended decades ago.[2]
Now dp is all nice and cool, but I think most jobs don't involve solving dp problems on a daily basis. Just like most mechanics don't need to solve Lagrangian mechanics problems or civil engineer with continuous girder (the interview for those those two don't have those either)[3].
There must be a better way to measure problem solving ability of a candidate, isn't there? Something thay requires more dedication from the company instead of blindly followingbthe practices of Google.
[1] The position is EM at a offshore branch of a medium sized non IT company, way below the likes of Google.
[2] Typical Asian problem.
[3] I started as a mechanics, and then doing some civil engineering job, building bridge and such.
Just speculation but I think a big part of this is that it is often quite difficult to lay off staff.
The issue isn't that you assess employees poorly...it is very hard to be right based on knowing someone for a couple of hours...but that it is so hard to get rid of someone if you are wrong. Would you marry someone after meeting for as long as the interview? That is the decision for a lot of companies.
I think that is why you see places like Denmark and Sweden, that make it easy to fire employees, do well and places like Japan and France do relatively poorly (the latter is particularly odd, they had a big lead in engineering...tech is miles behind)...ofc, it is hard to fire people in California...so not every example fits.
It's not easy to fire people in Sweden. You are not allowed to fire just because of lack in skill. Typically they would have to be severely negligent (like basically intentionally sabotaging) or there has to be a lack of work for that role. (In the latter case, they would have precedence for the job if you try to hire a replacement)
But for people just out of university it's common to hire people with a probationary period of a few month, during which you are allowed to terminate the employment without any specific reason. This probably helps some people, who don't have the right experience, to get a job.
I'd say that it's not very common that the opportunity for termination is actually used though, so I wouldn't credit it for any perceived success of Swedish tech.
To fire people in DK is possible but I would not call it easy. It takes money - for example if the person worked at the same company for 3 years, it takes 4 months salary if the person was hired using a standard contract which follows a law called "funktionærloven" written to create rules between company and employees.
That's… an unusually consistent signal. Suggests to me that either this person is getting into the wrong interviews (eg junior interviewing for senior role—though they say that's not the case), or more likely there's some hidden variable, like a bad reference, bad BO, really noticeable "culture" misfit, or other "red flag".
Regardless, the general points are spot on; it's a mess, for both sides. And even if the game weren't improved, I wish we all gave and got more honest feedback (however illegal that would be).
I think OP should use interviewing.io and take the feedback seriously. It's likely to be helpful if they want to actually pass those interviews. But there are other ways for a non-traditional candidate to make it.
You could be right. But given the highly random and variable nature of interviewing, the author could be the 1 in 100 competent engineer who does get rejected 23 times in a row.
Competent and interviews well can be disjoint sets. I've worked with lots of people from FAANG and helped many of them level up. There are psychological suggestibility and willingness to be slavish to your career heuristics that can silently filter.
These days I ask if they're open to a four day work week as a proxy for their stance towards the data supporting associated productivity and work life balance optimizations. Smart managers exist and this has been an excellent filter mechanism in their interviews for my attention.
Exactly. I mean, hiring strategies like this absolutely do have a bunch of false negatives: people who just didn't get lucky about what problem was asked, or had a brain fart at the wrong time. It happens.
But not at this kind of frequency it doesn't. If I got my quick back of the envelope statistics right (exactly the kind of skill that occasionally crops up in these jobs and on this interviews!), this would mean at 95% confidence the employers were incorrectly rejecting 88% of qualified candidates!
It's funny that the other day I was reading about the door policies of some top-tier Berlin nightclubs and it seems that the underlying processes are similar. The bouncers there do a "door interview" designed to not only filter likely bottom of the barrel (too drunk/high, tourists) but you also need to know arbitrary and often unwritten codes (e.g. the name of the event, line-up, dress code, physical appearance) which is a proxy for showing you've put in some amount of effort and "know the rules". It doesn't seem to help much to possess the real values they desire (actually not causing problems once inside, actually enjoying the music, actually contributing to the party's atmosphere) because they simply can't screen those quickly enough.
In both cases this seems to be the market solution to the problem of having limited capacity, high demand, necessarily short interviewing/screening processes, high cost for admitting sub-par candidates but low reward for admitting good candidates. And in both cases it seems most dislike the process for being ripe for arbitrariness and routinely turning away good candidates and "there ought to be a better way" but the process seems to have evolved naturally and doesn't seem to go away despite there apparently being no major barrier for using a better process should it exist.
I’ve been to that club. The internet descriptions are overblown. When I got all up in my head and attempted to follow all of the advice, I got turned away. I felt like I was wearing a costume and trying to be someone I wasn’t, and that was probably obvious to them.
When I went back years later and just went as myself, my wife and I were immediately welcomed in without much questioning. For those wondering, this is not a club where being with a woman is necessarily advantageous, but I will certainly admit that it likely had an impact.
The biggest things I saw them looking to screen out, beyond drunk - high - obnoxious, were youth and naïveté. They seem to largely be aiming at people who know exactly what they’re getting into, and are relaxed about it + not overly attached to the outcome.
Just so you know exactly what I had on, and how much it flies in the face of some of the advice... on Friday: White t-shirt, jeans, baseball cap. Saturday: Grey Everlane pocket t-shirt, backwards baseball cap, Patagonia 5” running shorts, Off-white Adidas Marathon sneakers. I did learn to dress like you’re going to dance for hours in Friday night, and jeans got hot and shirt came off real quick, so I adjusted on Saturday.
Wife went more classic and wore black jean shorts, black tee with a ripped collar, black baseball cap, black adidas.
If you didn't have female company the first time around, it's very likely that this tipped the balance on your second visit. Clubs are notorious for this.
I'm in my late 50s and after 10+ years at same company I found myself on the job market. 1998 was the last time I had any real interviews - after that point it was all networking with no real tech interviews. After much cursing at the advent of white boarding and code tests, I finally just caved and bought a leetcode subscription and starting working problems I hadn't seen since the late 80s in college. Long story short, After 8 interviews I landed a great job with Big Company. At the end of the day, it's a game. You can play it or complain about it, but it is what it is. Has leetcode made me a better programmer? NO. What has helped though is stackoverflow and github.
It showed that you were able and ambitious enough to learn (re-learn) a somewhat complex skill in a reasonably short time. This seems like a very desirable property to me, and a good substitute for having strong talent or recent experience of algorithm design and implementation.
I honestly don't know why anyone gives FAANG recruiters the time of day anymore. I have yet to meet anyone who feels good about the prospect of working for them, anyone who works there who's super proud of their mission, and the competitors who are looking to hire at that level of talent pay roughly similar wages from what I've seen.
My advice for this poor kid is to look around at startups and do more networking. FAANG jobs aren't anything to aspire to anymore.
- Comp: Total comp for a new hire with 3+ yrs dev experience is probably 300k -> 400k at a FAANG on average (with possibility to be higher). If you want to live and raise a family in your own house in the bay area (2.5 Million for a reasonable house), this matters.
- Access: Few places have the kind of scale and resources of these companies, that can make them fun places to work. You also get to learn a lot from really good coworkers (and go to talks, explore different things, etc.)
- Work/Life: FAANGs are generally pretty good for work/life balance (though this can vary by team and manager). They're generally pleasant places to work as an engineer.
> If you want to live and raise a family in your own house in the bay area (2.5 Million for a reasonable house), this matters.
I love the bay area, and I have terrible judgement, but even my terrible judgement and my love of the bay area combined aren't a bad enough combination to make me think it's a good place to raise a family.
I must admit I always feel weird when I see numbers like that mentioned for software engineers. In Germany a more reasonable number with a few years of experience might be in the €50-55k ballpark.
Granted, the cost of living is significantly lower in most cities here than it is in the bay area, but still it just feels... weird.
I think Europe (and the UK) undervalue software engineers.
At least in the UK this seems like a cultural thing where management is high status/high value and engineers are low status/low value.
I think the US generally gets this right (at least in silicon valley), but it could partly be because the US has some extremely valuable software companies that operate on a global stage that aren't really present elsewhere.
Really great software engineers can generate insane value at a great company with a good business.
I realise this is tangential to the original topic, but this notion that the UK is not a part of Europe (and therefore mentioned separately) seems really weird to me. They can leave the EU as much as they want, but it doesn't change the fact that physically they're still in Europe.
Is this because of some perceived notion of cultural differences? Because if we're starting to draw lines based on that we probably need to divide mainland Europe into a bunch of separate parts as well.
It's because America has (and has historically had) a closer relationship with the UK than with other European countries. The British see themselves as different than the rest of Europe as evidenced by sayings like "on the continent", so it's natural for us to pick some of that up.
I see, thank you for clarifying. It's true that some people do use Europe to mean EU, I hadn't taken that possibility into account.
In my experience, this is mostly done in sentences like "In Europe something or another is allowed/forbidden/... (by law)", but I can definitely see where you're coming from.
Mexico and Canada are technically part of America (North) and Russia is in Asia, yet most people don’t say that Canadians are Americans and Russians are Asians. One of the great funs of language.
You mean the kind of big companies that repeatedly break the law, engage in unethical behaviour, and put growth above all else? Yeah. Only the US has those. Congratulations.
Plenty of tech companies in Europe either way; you just don't know about them. Do you think Europe is some poor underdeveloped continent with uneducated people who can only "write spreadsheets?" What a patronizing comment.
You have to break eggs to make omelettes. The US is the only country in the world (perhaps excepting China) with any tech industry of value, just as it is the only country with any finance industry of value.
Europe has some companies with IT departments, some American companies with European offices, and some no-name consultancies (which are often US-owned). The indigenous European tech industry is a complete joke, since there is hardly any of it.
A normal programmer in Europe earns maybe $2-4k per month, or $24-48k per year. For context, the American poverty line for a family of four is $24.3k, so they are earning about $21/month above the poverty line.
A normal programmer in the USA earns maybe $100k per year, and up to $300-400k if they work at a big company. In Europe, the CEO of an ostensibly big company might earn $300-400k. It's an utter joke.
That I haven't heard of the alleged European tech companies just goes to show my point. DeepL, what the hell is that? Spotify is somewhat larger-scale web development, but still just a Mickey Mouse startup. The NYSE couldn't even get their flag right! The other two (relatively serious companies) are located in the UK, which is slated to leave the European Union soon.
Just so you know, salaries in Bangalore are comparable to that of SF if adjusted for Purchasing Power Parity. If you don't believe me, feel free to look up levels.fyi for both and match the conversions through: http://salaryconverter.nigelb.me/
That's because SV outsources their development work there, artificially inflating prices. In reality, India has a 'tech industry' in the same sense that Africa has an 'AI industry' - there is industry and it is vaguely related to AI, but tagging images does not an 'AI industry' make.
If there is development work happening, then there is a tech industry. Perhaps you may consider a tech industry to only exist if it is spawning a million startups a day but that is not a view shared by the rest of the world. See: http://elitebusinessmagazine.co.uk/global/item/how-the-tech-...
But let's assume for a second that the only relevant companies are US-based. A lot of them also hire in other countries and it is my understanding that compensation isn't what it is in the US either.
ARM have offices all over the world and are owned by the Japanese. The European "tech industry" is and remains a joke.
American companies also have offices all over the world. For example, Google have several offices in Africa. This does however not mean that Ghana has a booming tech industry, it just means that sometimes you need domestic offices for minor regulatory reasons.
SoftBank only bought ARM in 2016, they are by origin very much from the UK and I don't think anyone is going to argue that ARM wasn't relevant before 2016.
DeepMind was also founded in the UK and later bought by Google. Their HQ remains in London.
DeepL, who are providing a much better translation product than Google or Microsoft by many accounts, are a German company.
Spotify, which I'm sure needs no explanation, is a Swedish company.
While it is certainly true that the US pays better, I think you need to re-evaluate your position that noone else is creating good or valuable products.
Two of these companies are British, and the other two are complete jokes. It is like talking about the 'Ukrainian software industry'. Sure, some of them have computers, but that does not a tech industry make.
I can't speak to the job market in the UK, but in Germany there doesn't seem to be a great difference based on anecdotal evidence from friends. There's absolutely a chance this is incorrect as well, because discussing wages is still somewhat against societal norms here (which is stupid in my opinion).
The vast majority of engineers at FAANGs are _not_ commuting out of San Francisco -- looking at where the workforce really is: Mountain View, Menlo Park, Sunnyvale, you most definitely don't need to shell out $2.5M for a reasonable house.
Yes you do - Palo Alto, Mountain View, Cupertino, and nearby peninsula cities are even more expensive than SF. At least in SF you can get a nice new construction apartment for 875k.
You can find a cheap house for $1.25M in San Mateo or on the outskirts of San Jose, but it’ll still be pretty small and far away.
That's not universally true. US homes in warm climates had high ceilings until the advent of central climate control. Homes in cold areas tended to have low ceilings to keep the warm air where it was most useful: at the level of the occupants. Eight foot ceilings are very common in tract homes built between the introduction of air conditioning and the start of the McMansion trend in the 1990s. Common areas with higher ceilings are not rare in newer homes.
It's always... interesting... To look at SF on Zillow. There are a few nice-looking options in the ~1.5M range, mostly foreclosures, and it seems mostly in not-so-great areas. I don't know if there are any great areas in SF proper though.
FAANG has a much larger presence in Silicon Valley than SF. SF is more biased towards startups. Although it’s true all the major tech companies have SF shuttles.
San Jose’s median house price is $1.2 million. A million will get you a quality ranch.
(I fully appreciate the ridiculousness of presenting a million as “affordable”)
> I have yet to meet anyone who feels good about the prospect of working for them, anyone who works there who's super proud of their mission
I worked at the N in FAANG. It was the best large company work environment I ever worked in. The people I worked with were top notch, I looked forward to going into to work.
Our mission was to deliver entertainment around the world. I believed in that mission. I think entertainment is an important part of people on this planet relaxing, which leads to them being happier and all the outcomes that come from that.
I'll admit Netflix is different than most of the rest in that it isn't driven by ad revenue and increased consumerism, so maybe that made it easier to love the mission.
But yeah, I definitely enjoyed working there. Even without the crazy paycheck (although that admittedly helped a lot).
Netflix never wanted to do DRM. They fought the studios and tried to teach them for years that it was pointless. Eventually they had to relent because the studios had more power than they do.
To answer the follow up question -- the Netflix originals have DRM because they aren't made by Netflix, they are still made by regular Hollywood studios that demand DRM. And for the few where Netflix has control, it's easier technology-wise to just put DRM on everything instead of littering the code with exceptions for some content.
At the end of the day, DRM for rented content isn't so bad. You're renting it. You shouldn't have control over it.
Sorry, even if Netflix was used as a front for Hollywood for the DRM in HTML push, this smells too much of a "just following orders" justification - they benefited greatly by bending to Hollywood's wishes !
Also, their subscription model is quite different from plain rentals, and I'm having issues with the renting model anyway... and Netflix isn't so much renting as subscription... and even people that don't follow these issues are starting to realize that a system where there's no "standard" and you have to subscribe to multiple subscription platforms is bad !
I looked into moving to the bay area and FAANG were the only companies paying sufficiently high wages for me to break even after the difference in my mortgage payments. I don't want to work for FAANG, so I didn't move.
The best path in I can see is basically practicing interviews and landing an on site interview with Uber or Lyft on interviewing.io (where you can get a real interview just by passing enough practice interviews), then reaching out to recruiters at FAANGs and saying that you have interviews with X Y and Z lined up already. That tends to get replies, since you’re signaling that you’re vetted already and recruiters are paid per hire.
It's nice working on any well known product really. I spent 3 years with a tiny startup doing enterprise software, and I can hardly even explain it to other employers, because hell, not even my own boss knew what he was trying to sell. We just had some kind of survey builder platform with a mess of features that was starting to stick with people.
Finding my 2nd job is just as hard as getting the first one, as the product I helped develop is just not that interesting. It would be so much easier to just say I worked at Google, Airbnb, Apple, whatever. I'd be upset, but I don't want to work for a FAANG regardless.
I've been doing initial phone screens (small companies) this week (two just today, actually), and with all of them when the recruiter (internal or external) gets to the "we'd like to send you a coding challenge" I interject with: "Let's do a code exchange. I'll point you at some of my GH projects, and you send me some of your code".
So far they've accepted ("I'll forward it to the hiring manager"), and it's far too soon to see if this works... but I'm hoping.
The next step I'll be trying is "I'd like you to pay me for my time. If you're not comfortable with that yet, let's talk about what's involved in getting there."
One approach I really like is a company that will vet you and decide you have promise, then decide to hire you on the spot for some small amount of contract work. "Ok, you seem great, let's commit to 40 hours of work from you on whatever schedule you want, and we'll see how that goes." This lets you squeeze that in on evenings and weekends if you want and not quit your current job. Costs them very little and is way more productive than a standard interview loop.
I interviewed with a start-up mid-acquisition by Indeed and they paid me for my take-home project. Quality move but the rest of their behaviour was utterly reprehensible. I was mad/upset at the time but I'm now grateful.
Also, I had the time available to spend ~8-10 hours on a take-home project (paid or otherwise); most of the time the best candidates already have jobs and will rightfully tell you to pound sand.
I did a tedious take home assignment while employed for a different famous company - it was clear they hadn't updated the instructions (broken links, outdated documentation, changed behavior).
They gave this to me with a 72hr turn around requirement on a Monday morning (which I found a little thoughtless) I got a basic implementation working with reasonable code quality (not just hacked together) which took a few hours and then got turned down with no details.
In general this is worse than a regular phone screen when the instructions are bad and it's not really clear what they're looking for.
The worst is when the spec seems purposely vague (which is a reasonable part of the challenge), but there’s no channel provided to ask clarifying questions. CockroachDB was like this.
It's good to see people complaining about interview processes from Google&co as it's a good idea to always try to improve the current situation. However, I feel there needs to be some context here. While the interviews at FAANG seem not ideal, they are HUGELY better than most other tech interviews I've had experience with. In most other interviews you get to have a chat with some HR person that has no idea what the word "variable" means. You answer a set of standard questions and they barely know how to map your answers to the expected list of answers they have. Then they score you based on that.
Let's not lose that perspective in discussions like these.
Sincere question: What are you all doing accepting these multi-hour, multi-day take away free consulting gigs?
Say NO to this bullshit. Establish a deadline and clear guidelines and expectations:
1. I will not be doing any take away work at all.
2. You will explain how my GitHub repo, resumé, previous experience is insufficient to qualify me for the job in 100 words or more.
3. You will sign an NDA for whatever solution I created to whatever problem you task me with. You do not own my solution’s IP and may not share it outside of the people involved in my hiring process without my consent.
4. In the case where I fail the test you will explain in 100 words or more why my solution was unacceptable.
5. In the case my solution doesn’t compile/run you will allow me 3 attempts/1hour to provide you a solution and/or give me a Dockerfile representing the env where my solution will be tested.
Unless you are a critically important hire / executive level, asking a company to sign an NDA for an interview would be the kiss of death for the vast majority of candidates. To get an NDA signed, I would have to get company lawyers and my upper management involved, which is not something I would do unless we desperately needed your skillset and had zero other options.
I give candidates the option to do a take-home or in-person assessment. For the take-home I communicate that they own everything they produce, and I create an EC2 server for them to use for the interview so that whether or not someone owns a server is not a barrier to entry.
I would definitely decline to continue to interview a candidate if I received this list of demands. The tone is unbelievably entitled and screams "difficult to work with". The suggestion that I would sign an NDA on behalf of my company is absolutely absurd. I would never sign something on behalf of my company without consulting our legal counsel, and I would never continue an interview if I had to involve my legal counsel to determine whether or not a person can code.
I have tried a milder version of this and as anyone can guess - it did not work. The supply is too much and demand not so, the organizations will always pass. Only if you can get the demand-supply to work in your favour will this work.
> It sounds to me that now companies are more afraid of hiring bad candidates than they are excited about the opportunity to hire a great candidate.
People have come right out and said they’d rather miss out on a good hire than get a bad one. There’s no “sounds”. It is.
Rather than more and more convoluted interview processes maybe we should work on better weed out techniques? I mean, what’s the overall cost really of picking the best person you saw in two weeks, getting back to the process of building new functionality (and your new hire training materials) and just kicking the dense ones with a little reflection on what we’re the objective warning signs this was going to happen?
I really think the thing is that people want to believe that training for their team is arduous, and so the cost of every person is huge. I’ve known more than a few people who philosophized about how much they learn about their craft by teaching. And it always seems like the people who create the biggest messes are the ones who can’t explain themselves.
Which we have known forever. In fact during the dot com era it was quite common to hire the most articulate people you interviewed. At least of they were wrong about something you’d know it right away, instead of them obfuscating their bad ideas.
If all you care about is money, go bust your butt on leetcode and ace a FAANG interview. If you care about a work-life balance, and having a big impact on a small team, work for a medium-small startup and negotiate a flexible schedule.
Personally I get a huge kick out of making massive improvements to a small business's tech and infrastructure. The lack of bureaucracy is a freedom that is often taken for granted. If you have the vision and drive, you can improve the business's processes and product offerings by leaps and bounds...something I would argue is not readily available at a big company. Smaller companies are also much more willing and able to negotiate with you to help balance your life. A 4-day work week for example.
Again speaking anecdotally, I don't need that much money. I certainly don't need FAANG-level compensation. If I'm going to work somewhere, it's going to be because I want to be with those people, working on those problems, and having a big impact. Not because of the fat paycheck.
> I'm going to work somewhere, it's going to be because I want to be with those people, working on those problems, and having a big impact.
There are teams in FAANG that are like that. And I'm going to say mine, as we're a new team building a top level public service for a very large cloud company. It does mean sometimes there's lots of work though.
I recently flagged myself as "back on the market" on sites like StackOverflow and LinkedIn.
What a nightmare process this whole thing is.
I end up with a slammed inbox, constant cold-calls from head hunters that are all dead ends, and in between all of the noise are some real opportunities where I get moved from the tech screen to the final round quickly due to my seniority.
It's like most jobs except there is a strange dichotomy between the technical screens, and the on-prem final rounds, which become more of a culture-fit type interview.
I feel like I am up against the Bob's from Office Space a lot of the time.
If anyone needs a 30+ year software engineer currently working with .Net Core 3.1 on Azure Linux and Angular 9, please hit me up.
I was given a 2-hour coding challenge once to build a language server for a programming editor. It had to implement 3 functions:
1. show help text (type/doc string) for a word
2. go to definition
3. find all references
My first thought was "this is an absurd request for a two hour coding challenge". My second thought was "boy I hit the jackpot, a few years ago on a whim I built my own language server for Go in sublime text and could probably crank out a new one pretty quick"
I wish I could say it was a fluke, but I've been rejected by lots of companies due to the coding challenge. One day I'd really love to see what the passing code for these challenges looked like. Maybe I could learn where I dropped the ball.
FWIW. This is an absolutely awful coding challenge for an interview especially in a 2-hour setting. The challenge requires building off of implementation details for a few very
specific technologies. Interviews are supposed to test for general problem solving capabilities within some domain of competence. Unless the job was specifically to work on a go language server, and that was your aforementioned domain of competence, I see no rationale for using this programming challenge to determine employment.
That most people have a hard time viewing the world from different lenses.
The article presents a picture of a guy “studying up” for a career and his adventures in interviewing. As someone who’s interviewed hundreds of candidates I noticed red flags right away. For instance, if someone asks you to design a micro service - you don’t say “I can’t”. No FAANGco interviewer wants you to fail. In fact, they want to help you. The best worst answer would have been “I’m not really familiar with micro services but I’ll give it a shot. Could you explain a bit more about them?” This shows the candidate doesn’t falter at a challenge, is willing to dive deep, and is committed to the task.
The lens shift comes into play when 50% of the candidates can’t complete fizz buzz, another 25% simply lied in there resume about any relating experience, and the other 24% don’t have any real understanding about algorithms.
There are software developers and then there are great software developers. It’s generally initiative and algorithms that separate the two.
And yet, virtually all boot camps allocate time to interview questions now. Hell, there are boot camps devoted entirely to whiteboarding interviews. Surely this cottage industry, similar to those for gaming standardized tests (SAT/GRE/LSATs/MCATs), is a red flag that the industry has fallen into a pit of Goodhart's law?
Hmm, perhaps. But interviewing has become big businesses for prep and passing. There are companies that will ghost interview for a candidate, even through actual onsite interviews. It’s a real problem.
Tangentially, candidates should read “Programming Interviews Exposed: Secrets to Landing Your Next Job” for prep. It was recommended to me a long time ago and it was enough.
There are N other separations I could think of besides the ones you pointed out:
- someone who gets anxious and blanks out given hardcore requirements these kind of interviews have, smart people can also go bad at tests
- someone who's having a tough day and would fare better taking the challenge home with quiet relaxing time like they would expect to have at work if they need to code complex algorithms
- no interest in past code written that could potentially show other traits of the candidate a quick coding quiz can't
- etc (no need to be extra creative here, just be humble and imagine what the candidate might be going through to get a dream job)
The simple fact an apparently smart young person joining the industry gets burned out like that due to stupidly arrogant hiring processes like these is a sign HR are failing miserably in the computer industry, and it's not something that started last month. Simplifying the burden of such process for actual people looking for a job to show how they are worth is dehumanizing.
False negatives waste far less time (dollars) than false positives. It’s unfair but worth it to not force a team to have to work with an unqualified candidate for a year or maybe more.
The problem with an unyielding, fairly uniform obsession with interview problems unrelated to actual day-to-day development is that you're institutionalizing Goodhart's Law. Eventually the interviews will encourage false positives as candidates grind on CTCI and LeetCode and pass interviews without actually being able to excel at actual work responsibilities.
I don’t think so. That’s why you’ll have candidates passing the questions but not the interview. We’re not looking got rote answers, we’re looking for comprehension, problem solving, and discussion.
It’s perfectly possible to drill and take preparatory courses to finesse communication skills specifically for answering and explaining whiteboarding algo/ds questions. These resources are perfectly aware that rote memorization is insufficient but being able to communicate is also required to game these interviews.
This right here, I don’t get. Why TF would a manager make you work with unqualified people for a year+? Between evaluation periods and at-will employment, there’s no reason this should happen.
This is honestly something I've been trying to discuss with peers recently, and it's interesting the push back you get when you simply bring up the concept of "well, it obviously isn't C suite or HR that is advocating for the algorithmic leetcode test, they couldn't begin to understand that shit, it's 100% just other engineers setting up gatekeeping scenarios."
Well our Dev test was developed by the Senior VP and then tested on our developers; only 1 who aced it. Don't blame me and other workin' stiffs for that...
Is that true? I suppose the truly average HR rep can’t be, but I’ve never been given the freedom as an engineer to not ask a silly algorithm question. At most I get to decide which one I think is least silly. Maybe there are engineers somewhere who think the questions are great and high signal, but I’ve never met any.
Cynically: it means that there are a bunch of jobs that people want and that are hard to get, and the people who didn't get them don't like the process that rejected them.
There's no world in which there is an elite (e.g. FAANG) tier of employers who reject most applicants and one in which no one complains about their hiring.
That doesn't say anything about whether the hiring process is good or bad, obviously. But that is what it says about the industry.
Something that strikes me in reading articles like this, is the distopian part often seems to be thinking about this:
p(job_capable | not_interview_capable)
That is, it's crazy that an interview could miss so many people qualified for the job.
However, I wonder if oftentimes companies are aiming for..
p(job_capable | interview_capable)
If p(job_capable | interview_capable) is high, and p(interview_capable) is pretty good also, then the company will probably get what it's looking for.
This means that the author is right to recognize the test is doing a bad job of measuring their job readiness. A reasonable instrument in this case doesn't have to measure everyone's job fitness (whether there are nasty side effects is another big issue).
The simple explanation makes sense, but I'm realizing there's a subtle point here that I should been more clear on.
They might not be filtering out the bad at the expense of the good. But filtering out some of the good in the name of saving the money it would cost to develop / administer more general assessments.
That's the p(interview_capable) piece whereas the trade-off you mention is the conditional probability (also important!).
I don't know about US, but where I live they hire you with 1-3 months "trial period" during which the company can fire you any time if you turned out unfit for the job. This is exactly your proposal.
This will probably be lost in the pile of comments, and I'm sure some people will interpret it as humble bragging. But I genuinely do not get the angst and anger over the tech screen, from the perspective of an applicant. So I want to explain why I like them.
My background: I've never taken any kind of CS or programming class in my life. Mediocre grades in college. My first exposure to programming was at age 24, as I fell into it with an IT tech position. Went from there to a series of jobs at several startups. Before applying to a FAANG, I went through Elements of Programming Interviews and solved all the problems in it, which at around 10 hours/week took maybe 6 months of prep. I then sent in two applications, one to FB and one to GOOG, immediately got phone screens, passed, and then two weeks later went through the on-sites. Every one of the questions was either lifted from the coding prep book or trivial.
End result? Offers from both, joined as an L4, at a total comp higher than I had ever dreamed of, and significantly higher than friends in medicine who have easily spent over a hundred times as much time preparing and studying as I have.
So I'm kind of left flummoxed. Am I just incredibly lucky? There are huge issues in the hiring process, but if you want a job at FAANG, as far as I can tell it's incredibly easy to game the system. Set aside some time each week (easy, if you don't have kids), study for a couple months, and then apply. There's literally no other field than ours that is so open to motivated people without paper qualifications and that simultaneously offers so much in terms of lifestyle and compensation. Whether it hires the best candidates is another question entirely, but that's an issue for the company, not for the applicant.
But, when I give an interview to an applicant and use my go-to question, which I initially feared would provide no useful hiring signal for being too easy (and which, yes, I've tested on all my coworkers, who solve without any difficulty), I find that only maybe a third of applicants complete it at LH or higher.
To be clear, I'm calling this out as a blind spot I have--there's clearly a massive gap in perspective here--but hopefully it'll provide a useful data point for why tech screens aren't universally hated and why they manage to persist.
Your experience is incredibly close to my own. I'd love to know if you also feel the same about a few other issues:
- I used to have a massive impostor syndrome due to not having a CS degree. Joining FAANG alleviated perhaps 80% of it. (Just to be clear, that's not the reason why I joined FAANG; I just wanted to try a large corp after years in tiny startups.) It feels good, but I'm mourning it a little, because I believe it was a driving factor to how intensely I was trying to better myself.
- I enjoyed solving all these problems. There's beauty in finding the most optimal solution to each of them. Binary heaps are plain beautiful, and suffix trees and arrays still blow my mind years later. I wonder if people here dislike this stuff because they were forced to learn it in college for a piece of paper, while we learned it on our own volition for a big jump in compensation. Maybe I'm just projecting because I hated school and college; many HNers seem to have enjoyed their studies, which is awesome.
Absolutely. And that imposter syndrome played a substantial part in motivating me to apply to FAANG :) I found myself in the doldroms for years afterward after starting at G, but I recently quit to do my own thing for awhile and have been so happy to find that I still have the capacity for joy and drive.
And, yes, it was incredibly fun to study and solve these problems. Sometimes I'd end up going on unrelated tangents--cache-oblivious algorithms, a full history of quicksort and all its variations and partitions, how all the concurrent data structures in the Java standard library are implemented--and just spend all day reading about them and/or re-implementing them on paper on a sunny day in Golden Gate Park (and one of my Google interview questions was with a gruff Ukrainian guy who wanted me to implement a concurrent LRU cache, so that went swimmingly!). And so when people talk about how hellishly oppressive and difficult having to learn about binary search trees is, it just doesn't resonate with me. Even if not for the jump in comp, it was just genuinely fun.
My background is math/physics, so perhaps that's part of it? Maybe many applicants just want to build something and just care about the final product, while the part of programming that I enjoy most is the brain teasers and making things work in the most efficient and elegant way possible.
Thanks for answering. If you're still in the Bay, and feel like drinking a beer to our dear departed friend the impostor syndrome, feel free to email me :) it's in my profile.
The potential red flag in this account was Jared interrupting the interviewer who was asking a question that mentioned microservices to say that he had no experience in microservices.
Why did he interrupt the interviewer? And why interject that he had no experience in microservices? So what? You can still tackle a question that mentions microservices...
It's not like one's programming skills are useless for questions that merely mention an architecture you haven't officially worked with before. It's very strange to me that he interrupted that way, for that reason, and it makes me wonder if he acted similarly in other interviews. If his attitude is that he shouldn't have to answer questions about architectures and technologies not specified in his resume, that wouldn't go well.
Also, there's a lot of hype and looseness around the term "microservices" these days. You might have worked with what some people call microservices without knowing it. All the more reason not to cut off the question.
The evolution of the software engineering interview is a consequence of people gaming the metric. As the author points out, once the cat got out of the bag, the problems became increasingly challenging.
The real consequence is for wages. By making interviews a ceremonious practice where even engineers with years of experience need to spend a month Leetcoding, you severely restrict the talent pool. It discourages poaching. Engineers only care to subject themselves so many times, and since they already have a job, they're not too motivated to find another (compared to industry outsiders who aren't already earning software engineering-level salaries).
Fortunately, many places don't put you through the hazing that is the typical FANG interview. You can make 85-90% of a FANG salary, at a company that asks Leetcode easy's. That's what I've chose for myself. Not because I'm an incompetent engineer, but because mastering leetcode isn't a priority for me.
IME, it's more like a >50% pay cut. Plenty of reasons not to do FAANG, but when calculating trade-offs it's important to have an accurate view of the costs of each decision.
This is a topic I wrote about recently[0]. The fundamental problem is that these big companies are so afraid of hiring a bad candidate (a false positive) that they are willing to put up with a ton of smart people who fail their interviews (a false negative).
And the worst part of this is, from the inside, it really looks like the process is working. After all, there are some really smart people who get hired, and saying the hiring process is bad feels like you're saying your coworkers aren't smart. But the truth is, these companies are hitting smart people. They're just hitting a non-uniform dust of all three smart people out there.
I think this is an opportunity for smaller companies to hire people who wouldn't make it into the big companies, and innovate in a way the big companies can't!
Does it work? Maybe, maybe not. Perhaps you get some fantastic candidates (true positives), and perhaps you get people that are very god at gaming the system (false positives).
The process, as it is, is kinda like trying to select potential mathematicians on the basis of how well they solve HS AP Math problems. It is fully possible to rote learn every kind of integral and derivative under the sun, if you just solve enough - without actually understanding the underlying principles. It becomes a pattern recognition problem.
There are tons of anecdotes from seemingly false positives, when it comes to tech hiring. The web is filled with "I was very lucky, because they re-used problems I had just solved".
BTW, when I say false positives, I don't mean incompetent programmers / engineers - I just refer to those that do not master the subjects they're being tested on, but average candidates (on the subject) that luck out on getting asked the right question.
I still think Goodhart's law stands true for this trend.
People game the system, because they want to earn more money. Companies make the system more rigorous and robust against gaming. People still find ways to game the system, and it essentially becomes a race to the bottom. Along the way you start losing out on terrific candidates, because they refuse to partake in the increasing demands. So you end up with a mixture of very talented engineers, and very able test-takers.
This horror story would be enough to quit the entire FAANG game:
"At one particular ‘top’ tech company the process is that when a candidate goes through an interview he or she has a packet compiled about their interview performance. The packet then goes to a committee whose job it is to impartially review the packet to make a hiring decision. At one point a particular committee got so critical that they rejected every packet for several months. When HR caught wind of this they decided to set up a test. They sent the committee a new round of packets and once again the committee rejected them all. HR then called them all into a meeting and explained that they packets they had just reviewed were in fact the hiring committee member’s own packets from when they interviewed for that company. They had unknowingly rejected themselves! How could anyone pass that bar?"
It is my observation that you generally don't need to know how certain algorithms are implemented. You need to know of them, what they do and their strengths and weaknesses compared to other algorithms. That is, just enough knowledge to make the choice on which way to go. The actual implementation part can be Googled when the time comes.
If I was ever an interviewer, I would not ask candidates to implement algorithms, but rather to explain why you would use a certain one. Or give them a situation and some choices and ask them to choose one and justify their choice. (e.g. For this task, would you do it in python or C? Would you use a linked list or an array to solve this problem?)
> “Yes. Can you write an algorithm to find the Kth highest value in a binary tree?”
I got this exact question on a phone screen with "Giant Search and Advertising Company." I got stuck on a stupid detail and botched the implementation. Once I hung up the phone I took a deep breath and fixed the algorithm in about 15 minutes. That still isn't very good since I was only given 15 minutes total at the end of the interview to implement it in the first place so I assume that is the time-span they expect to get an answer from a senior engineer.
Fair enough, I didn't study for the interview, I don't have a lot of binary tree experience. I realized that if I couldn't get through that phone screen cleanly/easily then I probably wouldn't make it passed 4 or 5 whiteboard problems either (which are likely to be significantly more difficult). Fair play to any company that wants to screen candidates using that approach because I am not the kind of guy they are looking for and that is just fine. Everyone I spoke to was polite, professional and sounded competent. I do wish they would stop calling me and letting me know that I did well enough to be eligible to retry.
I have no doubt that I would contribute at an above-average level within any of those FAANG orgs but I appreciate their process and the reasons behind it. I have had no problem finding high-paying employment and distinguishing myself within any team I have worked on for my entire career. I generally get promoted quickly and asked to lead teams. As far as I can tell there is no dystopia, just people looking for different things.
How snarky do people get on these interviews? If anyone asked me to find the kth-greatest element in a tree I'd write down a loop that increments std:set::crbegin k-many times and then dereferences and returns it. This is literally how anybody at Giant Search and Advertising Company would do it, and almost nobody at that company has ever written a tree, they just use the one in libc++, from Jeff Dean on down.
Sigh. They aren't asking you the question because they expect you to write an in-memory data structure library. They are asking you this question because they want to know that you can reason about systems with subtle behavior, and a binary tree is one such system that most programmers learn about in school.
So if you refuse to engage, they'll have no evidence from you about your ability to write subtle code of any kind. And they'll go with someone less snarky who they know does.
Isn’t it up to the interviewer to ask a useful question? This is exactly how I would find the kth item of a search tree. I don’t feel like that is refusal to engage. Is the question is more like “describe various approaches to the designs of search trees and their iterators, and discuss the time/space complexity of a few examples” then that’s a different question.
But... demonstrating the ability to write subtle code is a useful question. "Describing" or "discussing" algorithms isn't the same thing at all.
I mean, I can't speak to the thinking of the original interviewer, but this is what I'm looking for with that sort of question. And I don't see how a binary tree is a bad choice. Again, it's something that everyone sees in school, so it doesn't require a ton of description in the interview.
I guess I put the question back to you: if you won't write a binary tree traversal in an interview, what subtle code would you be willing to demonstrate? And why is that better than a binary tree?
I really can’t more strenuously disagree. At Giant Search writing “subtle” code is very strongly discouraged. The very last thing I want is candidates with a penchant toward subtlety.
The point is to demonstrate capability, not "penchant". I mean, look, subtle code happens. Maybe it shouldn't. But it does, and it has to be fixed. There was a story here just a few days ago about some Project Zero work to find a bug in Chrome that involved a state machine with something like 50+ states! And realistically finding people who can do that requires that they be able to also do things like traversing a binary tree, right?
So I'm going to ask the question one more time: if you won't traverse a tree in an interview, how else do you propose to select for people able to reason about that kind of problem in practical code?
If it makes you feel better I’ve failed google’s interview several times before passing, after just grinding questions. It’s in some ways silly but not so silly that I’m willing to forgo a job which pays so much out of principle if I can help it.
It’s an easy question if you just do an inorder traversal and stop at the kth element, but of course that’s not optimal. To get log(n) efficiency you need to augment the tree with subtree counts.
Not exactly a comment for the piece, but for overall comments going around.
I am really shocked with people's understanding of situations. Like one great example of a different interview process which totally seems like working for the interviewer and his/her interviewees is bashed for not being good for their tastes without even getting the rationale. Or expecting people to spend 6 months on preparation for interviews considered normal or totally acceptable.
Either HN crowd are totally out of loop of life, or their self importance is out of bounds that they can't see anything else which is deemed below.
Is life something that you could spend so easily? What kind of affirmation people get from jumping hoops that would never even matter in the big picture?
The newer interview procedures that are described here really made my jaw drop. I am not the most down to earth guy without the last bit ego, but I believe I improved over the years. Still if I would encounter any of these , I would go jerkiest of egocentrics ever and tell them go do themselves.
> expecting people to spend 6 months on preparation for interviews considered normal or totally acceptable
You're expected to be able to solve a certain set of problems. Whether you don't prepare at all, spend 6 months, or spend 6 years is up to you. Oh, and everything you need to prep is available in cheap books and websites.
That's immensely superior to being required to spend 5 years and thousands of dollars in college to get the degree that nobody will hire you without, like some industries do.
Please look around, here you can find hundreds or thousands of people probably never used advanced algorithms for their lifetime except once or twice for their interviews. And you can see some who uses these daily who never implement them out of their heads but with intuition, preparation, effort, books and research. Oh and don't get me started that they all are compansated for.
Which type do you think these interview methods are optimized for?
These methods are waste of money, time, brains for both parties.
I'm not disputing that it's imperfect or wasteful, and I'm happy to see some companies trying different ways of interviewing that may not have these flaws.
I'm disputing that spending a few months to prepare for free and on your own schedule is particularly abnormal or unacceptable. Maybe we could do even less, but it's extremely benign in comparison with many other high-paying jobs.
Some people in this thread call the tech interview process hazing. It's a word that comes back on almost every HN discussion on the topic. Do you agree with that labelling? If you picked a random, non-software engineer person in the street and asked them whether solving algorithmic challenges at home for a few months before being flown all expenses paid to a tech campus to write on whiteboards and eat sushi constitutes hazing, what do you think would they answer? Remember that hazing regularly kills people and is categorized as a crime in California and many other places.
The industry is not interested in people from the street. We are always interested with people with years or decades of experience.
The problem arise from the discrepancy between how the expertise is and what the interview process searchs for. They are not the same thing or even signal each other.
I hate interviews. Just the idea of need for a job search is hurting my bones.
I did this on both sides multiple times in 2 different countries with different work ethics which are not SF or USA. I still not sure what are the good signals are. It is a lottery for both parties.
Also my concern is not about this, it's about peoples perception of the process. Some, like you consider preparation for the exam, but not the work ok. Some don't. And they both can't understand each others views. We have our perception filters tuned only for own.
About hazing, I absolutely totally agree it's hazing and from what I read here is getting worse.
Take a surgeon. for interviewing ask her to do a frog dissection for a take home project, and than ask her for a 10 hours long lead neural surgery, without meeting the patient before and preparing for it before. Oh you won't be paid, you can ask anything while patient is on the table. Oh I forgot you can't use the latest auto surgeon functionalities that we have which would improve or perfect the chances of success.
Now you know we are paying top notch, also have sushie served to your open office. You won't find a better option!
I know this is ridiculous, but why don't you think what we are exercising is not?
Unfortunately, it doesn't matter - since all tests test for something, and all these things are highly correlated, grueling job interviews are entirely justified.
As much as it pains to say me, HR is entirely justified in their approach of asking people to fill out a form, importing the list into excel, sorting on the GPA column, and calling the top N candidates on the list.
Push for change. Show others the alternative. I have worked with teammates to change hiring culture and gotten some fantastic feedback. Change will happen if you push for it.
Here're my points:
1. Supply candidate with a challenge that I built myself, tested with a co worker
2. Test should have many small goals and bugs: Get more data points on what they achieved, don't make it binary!
3. Challenge should include real bugs from when you built it. e.g. typos, wrong attribute names like 'innerHtml' instead of 'innerHTML', forgetting an import, etc.
4. Make results runnable / viewable (for front end work)
5. Explicitly tell candidate that Google is not just allowed, but expected
6. Allow candidate to ask questions so you're not dehumanizing them (but don't always give a straight answer)
7. Follow up with questions like "what do you think could be improved?"
8. If candidate spends more than 10 minutes on any of the challenges, allow them to skip it
Get as many data points as possible from an interview. Make it as close to real life as possible.
Everyone knows it's broken, but interview cycle still continues to bring in talent, even if there are false negatives. People still brave the grueling gauntlet. People still show up for interviews. Smart people still get hired. The system works, just in a terribly shitty way.
To HR, the engineer hiring process is voodoo magic and we best not touch it.
It only works because there's always another body standing outside the door waiting their turn to be abused by the process. It'll end real quick if they run out of interviewees.
A small agile company could hire undervalued people who don't do well in traditional interviews and clean up, if they didn't cargo cult programming interviews.
See these make a bit of sense for huge companies that have to filter millions of potential candidates. They don't make sense for your ten person bootstrapped company that wants to hire a junior full stack dev.
> At one particular ‘top’ tech company the process is that when a candidate goes through an interview he or she has a packet compiled about their interview performance. The packet then goes to a committee whose job it is to impartially review the packet to make a hiring decision. At one point a particular committee got so critical that they rejected every packet for several months. When HR caught wind of this they decided to set up a test. They sent the committee a new round of packets and once again the committee rejected them all. HR then called them all into a meeting and explained that they packets they had just reviewed were in fact the hiring committee member’s own packets from when they interviewed for that company. They had unknowingly rejected themselves! How could anyone pass that bar?
I am not sure anyone mentioned it before, but in many occupations you are required to take standardized tests which you are required to renew each X years. This way if you hold the credentials than you don't have to actually demonstrate your technical skills when applying for jobs, since your certificate proves them.
And guess what?! Your diploma is actually such a certificate, at least something that's close enough. Still our industry largely ignores that for some reason.
To get to the point I wouldn't mind to renew my credentials with supplemental diplomas every X years on standardized tests facilitated by educational institutions to avoid the stupidity of the industry's current trends.
The word 'dress' doesn't appear once in this thread and that's a sign of the disgusting state of affairs all in itself
It used to be people took care in small gestures like wearing a pressed shirt but now all the auspices have gone awry in favour of this laughable meritocracy
No wonder tests of this nature have been devised by people who haven't ever buttoned a collar and it's everyone's fault for not taking the moral high ground
When's the last time you walked into a formal interview that actually was formal?
Casual guys in a jizzing contest over O(logn) implementations of tree traversal is the reason every start-up fails after 18 months
What? I interviewed at my current location wearing a cargo short and a tshirt. It’s a trillion dollar company and we’re not failing any time soon.
Coding interviews aside, no dress requirement is one of the biggest plus and allow people to focus on the thing that matters. I have no idea where you come from that software engineering is helped by dressing up pressed shirts.
Bro the very fact that you're defending your right to wear your crusty cargo pants everywhere (to an interview for shame! Did you sleep in them the night before to shave off a few extra minutes?) shows that dress matters and it's very personal I never said otherwise
This whole industry in its infantile attempts to over optimize for comfort and everyone's right to wear their favorite rags to the office while enabling a command and control structure peopled by petty bureacrats has created the very worst of socialist factory conditions and if you can't see that you don't deserve to call yourself a systems professional
GREAT question. For one thing you’re not getting any job in mechanical engineering without a degree and an EIT, so that narrows the possibilities. Companies recruit at universities and this is the main pipeline into the industry. Connections are very important, so doing internships in summers during university gets your foot in the door. After you practice for ten years you get your PE and set up your practice either within a large company or independently. It is very likely that an ME can do their entire career without ever being subjected to the trick questions of some kid with six months of industry experience, like we pretend is normal for software developers.
I find this post accurate. Please also keep in mind that interviewing is as much about deciding if the company is right for you as it is if you are right for the company. When I take a bit too long to solve the coding challenge and the interviewer puts on an attitude I just assume that this is what it would be like working with this person, no thanks.
I recently interviewed with a hot VC funded start-up, the interviewer was the most dry and passive aggressive person I have ever met, I decided about 5 minutes into the 'get to know you, tell me about your work history' section of the conversation that I would not like working for this person. I had never wanted to end an interview early before this experience. When they sent me a leetcode link (to a problem I had solved in preparation for a series of interviews I was doing) and asked me to solve the problem I just sat there wondering how long before they would ask me to leave if I typed nothing. About 5 minutes later they asked me to leave, and that was the first time during the entire interview that the interviewer cracked a smile. I think that company will fail.
Am I the a-hole for playing that sort of game?
Edit: I also interviewed with a medical startup during which the interviewer, while telling me it took me a while to get to the solution and critiquing my implementation, admitted (I think by mistake) that they had spent some time researching the solution prior to the interview. I asked them how long it took them to solve, he did not answer that question.
The FAANG's of the world are doing us a big disservice. They filter out the best of the best programmers in the world, and then shackle them with 300K+ golden handcuffs to work on meaningless tasks on already developed products.
I was talking with a recruiter many years back about when Yahoo had a massive layoff. The following year, he was suddenly awash with jobs to fill with new startups that were created by these Yahoo employees that were in comfy jobs for life.
If one of the FAANG companies laid off their workers, we would have a huge tech boom as these brilliant people suddenly would be forced to either get another job, or create something new, and that percentage of people that would create something new would rock the world. We would have new innovations across the board in IT and other fields that they would apply their talents to.
Instead, they are building plumbing in a system that really is just in maintenance mode. Remember, 99% of the functionality of these systems that exist today was already in existence 5 years go for them. This swarm of high priced talent is basically just moving the needle about 1-2% per year to just stay ahead of any other potential competitor.
The trouble is that these companies are so successful, that they can burn the cash trapping talent, and still pull in billions per year. This grind for small returns is just a small line item compared to the flood of cash they all rake in.
Hiring and interviewing are incredibly broken, I totally agree... And the algorithm puzzles are basically silly and don't tell you any relevant things, like how pleasant would this person be to work with, how conscientious are they, etc.
But.
Usually interviewers are asking these questions to see how you think, not because they expect you to get it exactly right. And so verbalizing your thought process is how you prove yourself. And if you have trouble verbalizing your thought process, I sympathize, but being able to explain to others what you're trying to do and why you want to do it that way is a really big part of the job. And there are going to be a lot of times on the job where you DO need to tackle something wildly outside your skill set, and people need to see that you can at least start iterating towards the right thing. You don't have to be right, you just have to convince them you'd get there in a reasonable amount of time.
Also, if a small amount of pressure causes you to forget your entire CS education, that's kind of relevant to being able to do your job? I'm not trying to pile on to people that have anxiety issues, but being able to do things under pressure is a skill. If we're up against a deadline and you entirely freeze up and can't do anything, that would be a bit of a problem wouldn't it?
It's incredibly hard, and would take years for anyone to come up with any algorithm from first principle. Which means that any test of algorithm is a test of knowledge, rather than "how you think" or "being able to reason about subtle behavior in system" etc. You looks good if you already have the knowledge, and you will look like a clown otherwise. That is okay if you also realize that the breadth of CS fundamentals are incredibly broad and everyone only knows a subset of it (ask as many simple things as you can).
My deadlines are measured in months, weeks and in the minimum, days. There is practically no cases where it is in hours, and absolutely no case where it would be 30 minutes. I (We?) have trained myself to work and deal with deadlines/pressures of those standard time frame, which means that if I have only a day to deadline left, my technical mind shut down and it is now thinking about the business to see what should be best done next.
I believe people would feel more pressure at the risk of failing an interview than the risk of their company's product having a downtime
Its so funny, but I was with a good friend of mine who I've worked with on private projects, and we were just talking about this.
We spent a good lot of the night interviewing eachother in our own respective questions and judging eachother.
I'm a bit more senior that I like to admit, and I loved his questions. His approach was more simple questions, then go and follow up on them. This was evident when he mentioned 1 hour was not enough time for him.
I have quick fire nonsense questions that are just an entrance fee, What is SOLID, how can you prepare a unit test. Then important things (IMO) Patterns, identifying refactoring needs.
As for the questions themeself they're actually not that important and both of us tonight realised..
The questions you ask should reflect the work you EXPECT(if a senior/mid) the person to be able to do.
If you're hiring a JUNIOR I will say... The most important thing is to make sure they actually have an interest. I have been burnt hard on this.
Forget about language specifics also.. They can be learned, and as for Patterns, I am taking a step back on them because a lot of people use them without knowing it.
Our world comes from experience.. If you're willing and able to teach, hire like that, if you need some core team member quickly, hire for that.
It was easily the best chat I had with him in a long time and I hate interviewing!
I don't even have the coding level that the writer has, but I felt myself so expelled from the industry that I quit looking for jobs. I just gave up and started working independently. Financially now I'm really broke but I think I'm better with myself. Maybe I'm not the "super-programmer-hacker" but at least I don't have to participate feeding the sadistic pleasure and sense of power that recruiters have on us.
> The second was to write a recursive permutation generator using dynamic programming which is no easy task. I got totally stumped in the moment by that one. At the end of the interview I asked the interviewer “This problem seems a little steep for a phone interview. Do you often write recursive algorithms at Payment Processing Company?” He replied “No, we don’t use recursion.” “How about permutations? When have you used those?” He answered “Our algorithms have no need for permutations. Most of the engineers here work on user interfaces and infrastructure.”
This is absolutely hilarious, and has happened to me a bunch of times interviewing at large corps. Although I wish I had the balls to do what Jared does here, which is ask the interviewer if they ever even _used_ dynamic programming on the job.
Like, I get that some jobs are algorithms intensive. I've worked in such jobs myself. On the job, I had a lot of resources to help me - access to textbooks like CLRS and Wikipedia, so that building an algorithm and coming up with it's big O was mostly straightforward. But we've never had the CEO come and say "I need a O(n) algorithm stat for this problem _text dump of hard DP problem_".
Yes it sucks but so what? It's worth it. FANG will give anyone an interview if you have an internal reference. I am an undergrad English major in my 30s and just got in.
Gaming the system is easy. You just have to put in the work. Do every question in EPI and then do a few hundred leetcode questions until you're ready. It will take between 100-500 hours depending on where you're at when you start. Good luck!
How can you think clearly when someone is watching and judging you?
The ideal scenario would be - give a problem, leave the room, and come back after 15 minutes - give the candidate some breathing room.. to make mistakes, to try out few methods, to collect their thoughts.
This concept of 'We want you to think aloud, We want to see your approach', doesn't match reality.
In reality, the only time that happens is when both parties are trying to figure out a solution collaboratively. Not when one party already knows the answer and is 'testing' the other party.
An author's first draft, or a speaker's demo, has a million corrections before it gets to print/stage. Can RR Martin write freely if the NYTimes reviewed his every draft version ? Can Steve Jobs go on stage and give a demo if he has not already rehearsed the entire saga ?
It's like judging a person at their vulnerable stage. Unless they are a saint who can completely block out the existence of another human being sitting a few feet away, it's hard to concentrate.
You're more worried about how your thought process looks than you are about solving the problem at hand.
https://www.youtube.com/watch?v=EuPSibuIKIg took less than 45 minutes and was considerably deeper than FizzBuzz. Moreover, it would be easy to do better than the interviewee did. Granted, it's a pretty artificial situation.
There are some things that are really tricky and so they take longer than that to write even when they're less code, but the examples above are not among them. Also, it's pretty often that I've written longer programs than 30 lines inside of 45 minutes.
I know there are people who can do things like that but can't do them in an interview because they freak out, and there are people who can program somewhat but can't do things like that, and they might be better at other things than I am. You aren't going to find out how well someone's high-level architectural abilities can help you steer clear of unnecessary implementation problems in a 45-minute interview, unless they're the same as your own high-level architectural abilities, in which case you can recognize them.
But you can find out if they can write code that works, at least sometimes, because that's a thing that you can actually do in that timespan.
When I was young and free the FAANGs were my ultimate dream. I even saw the interview process as a cool pissing contest. However living in the US wasn't for me, so always had to regrettably pass on interviews... but now as time passed and we've seen the FAANGs go from good guy to Bond villain, I'm forever glad I never hauled my family across the world to be part of the cool gang.
Talking to friends who now work for the FAANGs, I've heard stories of having to spend 40+ hours (re-reading Sedgewick and practicing programming questions etc) to just prepare for the first round.
Fuck that...
FAANG interviews might be dystopian, but if you look outside the Silicon Valley bubble, you can find interviews that are far more enjoyable than spending days in front of whiteboards just to move onto the next round. The most common pattern of past interviews for me has been beer/coffee/coke and a 30 minute chat about the company's future goals and see if I fit might in. That should be how it's done.
I've designed an interview test before and I am ironically now doing a very similar interview test to what I designed for the company I used to work at. It worked extremely well for where I used it and I am absolutely thrilled to work on it now for this company. The key element here is indeed relevancy to the job you apply for and not looking for a perfect answer.
For anyone doing programming tests, I would like to give some advice, too, based on the tests I did and got through successfully:
- Always give it a try
- Always explain what you do and what you are trying to do
- Don't worry about sending in an incomplete test when you don't manage to do it
- Be verbose about what you are trying to do to solve it
- Don't be afraid to ask questions
My first great programming job was at a place where I got a hard mathematical problem to solve, and I didn't manage to solve it at the moment, so I asked if I could take it home. I didn't manage to solve it at home but sent in the broken code that I had either way.
I got the job.
Why? Because the broken code I sent in showed that I understood recursion (it was for a Common Lisp job, that code was in Clojure) and the other people, even if they did manage to solve it, used more common languages and iterative solutions. He wanted someone who got the spirit of what they were working with, so that got me in. I asked my boss later how to solve that question, and he didn't manage either.
When I did the interviewing myself, the situation was similar. One candidate sent in a huge resume that looked impressive, but didn't send in the test. Immediate fail. Two others had a hard time with the test, but they showed that they cared about making it work, and that was enough for us to accept them: the core thing we wanted to see was that they could learn and cared enough to learn about what they needed.
One of those became main programmer and leader of many others later on, and made the company hugely successful.
I mean looking at the author's resume, it looks like he is mainly focused on machine learning domain, where the hiring is tight. Yes, in ML top 5% candidates are sought after like there is no tomorrow, but there is barely anything left for the left 95% of candidates.
So here is my advice. For your first job, and as a newbie, be accommodating. When I was out-of-college, I thought Java is no fun and is only for old people, I am functional and cool. And the job scene is just a hammer right on my head. So brush up my Java knowledge like in 2 weeks, and putting Java everywhere on my resume. Get a job pretty quickly.
Now I have experience, and don't have to bundle myself as Java programmer anymore. But that is only after I have grown from that early experience.
So again, be accommodating, get a job first and everything else can be figured out more easily.
Whenever I've interviewed people I've always made sure to them feel comfortable, so any anxiety does not get in their way.
Then, we talk and I look for all the qualities they /do/ have.
Sadly, lots of interviewers get a kick out of finding out what the interviewee does not know, so they can feel superior.
Coding challenges should be:
-1. take-home
-2. concise
-3. relevant to the job
-4. take no more than 4 hours
One example of such a decent test that I came across involved having to read a file, parsing it and turning its contents into some basic HTML. During the interview we talked about things like "what if the file were really big", e.g. let the candidate reflect on the limitations of their implementation.
This was enough to suss out where somebody is, professionally.
And nobody had to have a bad day.
All this discussion is spot on. The problem is all these startups now think they are FAANG companies also. You're not Google dude and you're probabaly passing on great hires and making the hiring process harder on everyone.
We recently did a bunch of hiring. Our coding excersize was practical and involved working through some existing code that had a bug and extending it. They had to be able to state the problem back to us clearly. It was take home solutions submitted to git. It was simple to weed through candidates looking at the code for 30 secs. We looked for things like clean code and well thought out solutions. We didn't do the silly BigO optimization stuff that every company is obsessed with. We've been very happy with our hires.
> companies are more afraid of hiring bad candidates than they are excited about the opportunity to hire a great candidate
Pretty much - they're willing to reject 100 good candidates in order to avoid hiring one bad one by mistake.
It's also a feedback system/arms race (like college admissions, conference paper submissions, etc..) The lower the acceptance rate, the more places you have to apply. This raises the number of applicants for each position, which in turn lowers the acceptance rate even further. This continues until you reach the maximum number of applications that each candidate can produce. Needless to say, the quality of evaluation is inversely proportional to the number of candidates, so acceptance becomes arbitrary and random.
I have a poor opinion of the Google style job interview to the point where despite having worked at Google for 8 years and trained in the interview process twice I just won't give interviews... I don't like the idea of giving an interview that I wouldn't pass myself.
BUT...
Having recently been through an interview with a well-known open source software company where the third interview ended with a "No" based on what seemed like purely subjective factors with no skill-based or evidence based reasoning at all... I do now have a lot more sympathy for our process @ Google which at least requires a panel of people with calibrated scores, multiple interviews with copious note taking and documentation, etc.
It really is hard to find a middle ground, though.
Ok maybe it is different as I did not apply for permanent position for about 25 years but I have developed/helped to develop many products on consulting basis for other companies and had to go to numerous interviews. Here is my experience:
Some companies are hiring a pie in a sky while other have real problems and want to hire people that can solve real problems. Hence 2 type of questions:
1) Write me working Lisp code of some exotic sort algorithm, oh and btw what that Hermite–Minkowski theorem is about.
2) They ask what you've done, how you did it, some references and how you can help them to solve their problem.
When I smell #1 I just apologize and leave. #2 can go either way but at least you're talking to a reasonable people with real needs.
This is life though right? These companies pay crazy high salaries -- they're not going to make it easy on you.
The fact that you'll barely be using the algorithms if at all doesn't matter. They use that for interviewing specifically because it's hard, and it screens for intelligence, problem solving speed, knowledge, and even how fast you learn (since everyone's got to learn the same algorithm question prep).
The end goal for them is that all their workers are at a minimum screened for the ability to grind at and break through difficult and esoteric problems, which are the biggest time sinks and therefore biggest limiters on the progress of the business.
I once got a Union Find algorithmic problem in an Embedded Systems phone screen.
Seriously.
I've seen that same role unfilled on LinkedIn for more than a year. How do you stop Google engineers from straight out gatekeeping if they are afforded so much freedom?
I have over 20 years of experience but due to the constantly changing and re-inventing of tooling I consider myself "junior". I like to do my "cooking" using fresh ingredients, but I prefer to use a sharp knife, rather then special purpose cutting tools, so when I get asked: -"Have you used popular framework and tool x,y,z" my answer is often no, so they probably think I've been living under a rock for the past 5 years. But quite the opposite, I constantly read about most of these tools, but they do not solve any problem I have.
If you work at a FANG too much of your income is hoovered up by rent anyways. Especially factoring in the hours and stress. Promises of a career ladder are breadcrumbs for most people. Why bother.
Big Tech has been captured by finance and professional management. In other words those companies are now political bureaucracies where workers, as opposed to connected operators, are exploited.
Workers now need to go elsewhere, save up some cheddar, and start their own companies. Same as it ever was.
There's nothing special about Silicon Valley. It preys on idealism and naivety just as much as Hollywood.
I have done multiple hiring and interviews in tech industry and find it quite baffling what has s/w engineering interviewing process degenerated into. I hear many sad interviewing stories these days. Some my conclusions: Interviewing is an art and it takes a very good interviewer to identify good candidates, this algo/prog interview in 45 mins can not do justice. Problem solving is what is really should be checked and extremely difficult to check, dont ignore the attitude of the candidate. Einstein with a bad attitude should be avoided.
You need to follow a pretty similar path to get good at competitive programming, which seems to be what that type of interview optimizes for. Know lots of optimal approaches to a large class of problems, and be able to very quickly identify and classify the problem you are given and apply those approaches to solve the specific problem. I agree this isn't really a good match for real-life work. I'm pretty happy with my non MFAANG job but I took up competitive programming as a hobby just so I can have options next time I want to change jobs.
I start a new position Monday. I expected my search to be exactly like this, so I started early.
Within a week of setting the "would hear from recruiters" flag on my admittedly-thin LinkedIn profile, I had 3 solid leads from 3 companies.
I had 3 in-person interviews, and even feeling like I flailed a bit on a couple of the coding exercises (I had the exact panic about writing The Game of Life in 60 minutes), I had two offers and one almost-offer. (The almost was more due to they wanted a principal engineer vs. senior engineer).
Maybe around where I am companies are learning their lesson.
The priority of a big company is to get a "good enough" person as quickly as possible. They have tons of applications, and interviewer time is expensive. Naturally, the process is geared towards minimizing false negatives, and getting a reasonably good hire in the minimum time. The current process works well for that. People who clear these interviews are usually not terrible, and are good enough. There is no incentive for a large company to do anything differently, unless they are looking for a very specific skillset, which is rare.
Re: 'Time limits are detrimental and discriminatory' the short answer is that it's really testing if you already know the answer - some of these original algorithms took decades to discovery the first time. My interview process if a bit different but still very tough. I talk about some of my opinions on that here https://medium.com/@anthony_sarkis/software-engineering-path...
I wonder if they were actually effective with that recruitment strategy. I got that notification a bunch of times, generally when googling for documentation, and thus when I’m in the middle of something relatively technical. Finally, I accepted the challenge, looked at the problem, realized it would take at least an hour, and then went back to the programming problem I was doing in the first place.
You’re selecting for employees who are able to get distracted for a few hours when they’re in the middle of something else. That’s not who you want.
I think Giant Search and Advertising should make the interview more difficult, then more difficult still, then cease hiring entirely, then atrophy employees until they die and/or are legislated out of existence. You - yes, you, HN reader who already works at one of these companies - are ethically responsible for the actions of your employer. When you're the one on the front lines helping realize their dystopian dreams, then the blame falls on you. Don't work for FAANG.
Netflix is the better of the bunch, but they still develop and support DRM (Digital Restrictions Management).
Apple is awful, they have a long and storied history of anti-competitive and anti-consumer behavior. Pay-to-play developer ecosystem, walled gardens of applications, proprietary connectors just for the sake of being proprietary, armies of lawyers finding creative new ways to evade taxes...
To me the main misstep with a lot of modern interview testing is the time-constraint factor. Having 20 minutes to solve a complex problem sans-Google in a not-really-a-text-editor field on a web page just isn’t a real-world scenario. And, what you do in that setting doesn’t really say anything useful.
If you’re going to test people, either whiteboard it and make it absolutely clear you just want to see how they break it down; or, give them hours to do it right without a lot of restrictions.
> Hierarchies are real - I am rather confused with the advertised rankings of a software engineer. There seem to be only two rankings: non-senior and senior.
This one greatly differs between large and small companies, but I think for small companies there are only two positions they can interview for, junior and senior. Anything beyond that, be it Director, VP or SVP, the company is no more interviewing a candidate but rather is doing everything in their power to convince them to join.
A lot of the article can be explained by viewing the interview as a test. The economics of false positives vs false negatives are vastly different. Giant search company can afford to not hire great candidates. More will apply tomorrow. The cost of hiring somebody they shouldn’t have is disproportionately higher.
I’m not saying this is a good thing, but to me it does explain why interviews are so hard and why they are so disconnected from actual jobs that applicants will actually perform.
Last year I did the initial phone screen for a management level role at large search company and the next step was the infamous code test. Such a hard pass. Maybe it's different at a FAANG but my day job is communication and coordination, being technical enough to unblock and optimise work across multiple teams. The process just felt like it was optimising for the wrong thing. Not to mention that it's 20 years since my degree and I have better things to do.
Every time I read one of these articles, I'm surprised at the complexity of the coding questions the candidates had to solve. When I interviewed for my jobs, the questions were much simpler, and as an interviewer myself, I (a) pick much simpler questions and (b) even so, the candidates tend to have plenty of struggles solving them.
Am I really missing an army of engineers who can write an involved image filter in 45 minutes without that actually being their specialization?
Can we move on? Interviews suck in every industry. "Sell me this pen" isn't relevant to what a saleman will be doing. He will be on the phone, following a script but its so standard.
It could be worse. In the medical industry you have to work for free (or low pay) for 1-2 years to even be considered for a "real job". Law firms are highly competitive, and have very rigorous interviews . And yet software engineers are payed better on average then both.
I feel this personally. But I suppose the author is doing a lot better job that I could of as I typically just don't receive a response at all to anything I would apply for. Finding work here feels quite tough, and even with recently graduating with a bach in CS, I ended with contract work writing English content for Japanese websites. It's not demanding and pretty breezy, but at the very least keeps me from turning up homeless.
I've multiple colleagues who got offers from all of FAANG. They tell me about solving 500 problems on LeetCode 2 or 3 times before appearing for interviews.
For example, you don't ask a carpenter if they know what a dovetail joint is. You don't ask a bricklayer on which brand of bricks he prefers, or how tall his last wall was.
You certainly don't ask a mechanic how an internal combustion engine works!
Sure throw a few algorithms at entry level employees, with no experience, to make sure they understand the basics. But not experienced developers!
I strongly encourage self-taught developers to take a good theoretical algorithms class. In it, you'll learn to represent most problems as some sort of graph problem and map the problem at hand to nodes, edges, etc. and find the most efficient way to solve it, prove your solution and show how long it takes. You'll also learn (more importantly) what classes of problems cannot be solved at all.
The heart of the issue is that the interview and even the application process are geared towards finding this mythical coder who lives to churn out code. "URL for website or GitHub repo" is a required field on so many applications now. Sorry... between music, art, exercise, children, and commuting, finding unpaid time to do my job even more is a little tricky!
It's bad, but it's less bad than all the other ways of testing SWE's. These companies aren't averse to self-reflection on hiring criteria. They no longer care about GPA, whether you went to college, or test scores. Evidently their data have shown that algos questions are effective at identifying high performers, albeit inhumane and non-holistically.
The worst interviews of my life were at Google. The reason is, they ping me when I am not looking and that gives me the idea to look - then they are my first interview. The last time I went through a new job search I studied first for two months. The google interview was before all that. Bombing was painful! IMHO job interviewing is a skill and practice is essential.
They are missing a lot of good engineers by putting sink or float weight on white boardings. Apple does this as many big companies. a lot of candidates can code but can’t white board or they can white board because they studied the cracking the interview. You will get some that can actually get whiteboarding but you are hiring people with very simular minds
I really, really want to see Crystal succeed. I've been playing with it over the past few weeks. Since it is so Ruby-like, it's the first language I sat down and pretty much immediately knew how to achieve most of my goals. And having Spec (RSpec-like testing framework) made me nostalgic. I hope to see a critical mass grow behind this one.
At my last job, I was trying to hire a frontend engineer. More programmery than designery, so I would kind of expect the ideal candidate to have heard of Typescript, and to have maybe written a unit test before. Our recruiter put a job listing on the usual places with those exact criteria, and ... we got hundreds of resumes by the time I took a look at the queue a few days later. I reviewed them all! 90% of the applicants had gone to a bootcamp and had nearly identical resumes. They wrote down their camp projects as though they were work experience. They linked to their Github that had line-for-line identical code between applicants that went to the same boot camp. Some were just directly the output of create-react-app with no additional code added. The common theme was, "I hear you get paid a lot to be a programmer. Count me in!" The other 10% of applicants didn't really have anything negative going on. They have some claimed programming experience, and they want to get paid to write computer programs. Why not call them up and ask them to find the k-th element of a binary tree? It's not a super-obscure area of study.
When I was at... erm... "Giant Search and Advertising Company"..., I did in-person interviews. I went through a lot of the shared interview questions to use, but ultimately came up with my own: given a stream of events from a variety of event sources, count how many unique event sources emitted an event in the last 5 minutes and last 30 minutes. I chose this because I literally wrote this exact program, and it took me a few iterations to get it to be optimal. (Or what I think is optimal!) For that reason, I found it to be a pretty fair question. The answer is just a few lines of code. The problem is a real-world problem. It's not a puzzle, but it does involve some thinking and maybe asking some questions.
The last thing I'll say, which I know is kind of snarky... As a Senior Software Engineer at Google, your total compensation is going to be north of $300,000 a year. You should be able to find the k-th element of a binary tree. Teach yourself how; it's kind of fun, and might someday be useful.
I agree with the HN consensus that hard CS comes up somewhat rarely in the day-to-day life of a programmer. But when it does come up, you really do need to know it. You will never be finding the k-th element of a binary tree. But there will be tree structures, and you will come up with some brute-force algorithm because you haven't seen that class of problems before, and you will push your "uses too much memory and time on production-sized datasets" hack to production, and production will crash, and then you find yourself with a production outage you don't have the tools to fix. You aren't getting paid $300,000 a year for that. So that's probably why they ask you CS-y questions.
What I've noticed about interviews is that there are a lot of generally unhappy and insecure people out there. People, especially in the Bay Area, are under the thumb at home and work and have a lot of debt and stressful family lives. Social comparison is an instinctual response in such instances and extreme bias is commonplace.
“When I was asked to write an image filtration algorithm I spent the first 15 minutes just to understand the question. I ran out of time. ”
I have been through few of these, I just assume that there are people out there who can understand and code up the question asked within 15 min. Those are the people this company is looking for. Not you and me.
It's a form of "guess the teacher's answer". I was once observer to a committee that rejected a candidate that came up with a more efficient and correct answer than the interviewer was looking for. I couldn't argue against it because I had recommended the candidate.
After 15 years, patents, open source, and repeats successes it hasn't gotten better. I got into this because I loved it so much... I feel asked to be a hyper energetic, extroverted ego case and really I just want to be humble and quietly write some code I can feel proud of that does something useful with some kind people.
Much of these hiring practices are just a self-perpetuating narrative. Just spreading the news that interviews at your company are hard is a way to discourage unqualified candidates. And candidates that don't want to put up with your (perceived) bullshit.
Either way, the choice of playing the game is entirely on us.
2. Each user story, commit for feature, etc is tagged
3. Pending features are correlated to (2).
Finally, no interview or references. Simply hire people who can complete high level implementations for the features to extent one can given an arbitrary time frame.
The best part is they might hire someone that knows the answers by chance when someone with much better technical skills doesn’t know the answers to the particular set of questions and then the new hire might be technically savvy but often have very poor interpersonal skills
I almost got into a role as a lead dev only to decline myself later. Their entire team had left for some reason and last developer wanted to leave too. No technical interviews, though lol.
Small companies aren’t that great either, when their main business isn’t tech
I mean interviewing sucks yes. And don’t spend too long on take home work, no more than what you’d expect to put into a normal interview at that stage eg if it’s a screen no more than 1 hr if it’s later no more than a few.
No matter how many APIs and tutorials you do it comes down to being calm under pressure and knowing who you are talking to. You have to practice your communication skills and be cool. Often times you will be interviewed by HR people and managers - rarely will you get to be interviewed by a TDD Clean code geek that you follow on twitter. Eitherway there is nothing out there that you deserve more than other people. If you are young shut up and build stuff. (I wrote this as satire a couple moons ago; http://owensoft.net/v4/item/2162/ )
> rarely will you get to be interviewed by a TDD Clean code geek
Have to disagree. Every interview in the last 3 years was majority technical with top-tier team members. Yes, I talked to a couple HR reps and managers but they were less than 10% of the individual interviews.
Face it, FANG companies are mega corporations. All that made them good in the eyes of most employees vaporized when they grow much bigger and they lose their culture. That means less autonomy for the new employees (how many remember mythical 20% own time at Google?) and less freedom
of expression (James Damore).
If you want to be part of something special join a startup or at least a small or mid size company made up of people that actually values your whole skillset and creativity instead of only one aspect.
I actually really like Google's process. It's got everything I look for, as a candidate:
* Predictability - I know what it's going to be like clearly from the beginning
* Trainability - I can become better at it
* Memoryless - They don't care that I did terribly a year ago
Of course, in the end, I didn't actually interview even once with them so maybe I'm lying about what I like. I guess I'm one of those guys who goes from job to job not having a whiteboard interview. Lucky me.
Everytime this topic is mentioned in HN it always garnered so many comments more than any other topic.
And so many people have rehashed over and over their positions. I did, and I will do it again today.
Tech booming just happened pretty recently. People are going from law and finance and medicine to software in droves. Though it is arguably that those people better stick with law, finance or medicine than software, the fact is that software field has lower barrier of entry, from socio-economic/financial point of view and artificial gatekeeping point of view. Majority of people just don't have the resources to study law, finance or medicine.
We have a gold rush, and majority of people want to improve their life, with the least amount of effort/barrier possible.
This result in new supplies of software engineers, whether from graduating bootcamp or graduating CS degree. All of these engineers are of varying quality. Let's not talk about the older experienced software engineers, because I think it is safe to point out the fact that older more experienced software engineers are of better quality in general.
So now, we have massive influx of newbie/junior software engineering candidates. How do companies realistically interview all of them? Knowing that these people graduated with varying degree of skills/quality.
If the majority of the workforce are older experienced software engineers of good quality, then companies won't have this filtering problem. They can just give interviews by talking from previous projects/referral and call it a day.
But now we have this DS&A and take home test as well, because interviewing is hard, and the more candidates out there the harder it becomes.
I am about 5 years into my career in this, and did interviews at a few companies and also FAANG. I experienced take home tests, work for a day, and DS&A. And I choose DS&A every single time because the other two sucks.
I don't have that many projects, or even side projects that I can be proud of. I love doing hard tutorial such as learning how to do compilers rather than doing some projects. All my github is filled with trash/throwaway code. And for some reason I always got involved with projects that ended up being throwaways in my previous companies, because those projects were generally hard problems.
Work for a day, take home tests, those two are a waste of time in my opinion. I can't do multiple of them and get competing offers. But with DS&A I can just learn once and do it multiple times and get multiple competing offers. Not to mention that I won't have to compete with more senior engineers that are obviously more capable than me. By doing this DS&A game I already filtered myself up for better.
Besides, I hate learning about framework this, framework that, technology this, technology that, multiple times. It gets old quick. Don't get me wrong, I love learning new stuffs, but too many of those and I just spin around in circles learning the next Javascript framework flavor of the month. I'd rather be interviewed about how to do recursion than being interviewed about the nitty gritty of React vs Angular, Express vs Koa, etc etc etc.
In general I favor DS&A interviews. For those of you who are more senior than me. Please don't do DS&A. Please stick with what works for you. If competent people like you start doing DS&A and be good at it, then what are the chances of people like me, or other non senior engineers for getting a job. If you think I'm being sarcastic, believe me, I am not. I truly believe there are people out there that can code in circles around me despite me knowing how to recursively generate a permutation.
In general I have success in interviewing at non FAANG/Unicorn companies. I usually finished those coding challenges in 10-15 mins, and the rest 30 mins I just talk to them about random stuff and they ask me about previous project, culture, etc.
However, I still haven't found success in FAANG companies. I still got rejected, despite having solved 300+ Leetcode questions. And yes I know people who solved 500+ and still got rejected.
Now that brings me to the things that bother me the most. I've seen, as many of the commenters here, that there are people who got in despite not doing any preparation at all. I thought at first those were lies, until I saw it myself, and not just once, but twice, three, and now four times. Everytime I heard these stories it demoralized me.
I've seen people who got into L3, L4, E4, without knowing how to reverse a binary tree or do a simple BFS/DFS.
Why? What am I doing wrong? What are they doing right?
p.s. Don't ask me why I want to work for FAANG. I need (not just want) the money. I have people that I support.
I see peoples' opinions here generally falling into one of two camps. The standard way interviews are conducted are either good or bad. I think it's important to consider both the good and bad elements, and then come to a conclusion about what to do in order to move the collective interview process in a better direction. To note, I've never gone through a traditional technical interview, so take what I'm saying with a grain of salt. Let's look at the example in the given in the blog post, write an algorithm to find the Kth highest value in a binary tree. Now my data structures and algorithms are a bit rusty, so assuming that I remember the correct definition for node height, I believe the solution looks something like the following.
data Tree a = Tree a (Maybe (Tree a)) (Maybe (Tree a)) deriving Show
-- Assuming k=1 Means the highest node, k=2 means second, etc...
-- Note this solution successfully puns non-positive k's
-- to return Nothing
kHighest :: Int -> Tree a -> Maybe a
kHighest 1 (Tree a _ _) = Just a
kHighest k (Tree _ (Just l) (Just r)) =
case (lRes, rRes) of
(Just x, _) -> Just x
(_, Just x) -> Just x
(_, _) -> Nothing
where
lRes = kHighest (k - 1) l
rRes = kHighest (k - 1) r
kHighest k (Tree _ (Just l) _) = kHighest (k - 1) l
kHighest k (Tree _ _ (Just r)) = kHighest (k - 1) r
kHighest _ (Tree _ _ _) = Nothing
Barring some fundamental misunderstanding of the problem (entirely possible), the evaluation criteria is not that the solution is exactly correct and covers all edge cases. The evaluation criteria is does the solution show fundamental knowledge about properties that are used to classify things as tree-like, and does it use the common idiom (decomposition into smaller sub-problems) that is used to process tree-like data.
In my opinion, the common criticism that interview questions hold no similarity to day-to-day software engineering problems, holds no water. Yes, you will not directly re-write the tree data type every day in your job. However, you deal with recursive data definitions that require solution by decomposition _multiple_ times a day. If you are not dealing with problems that fall under that category, then you should think hard about which problems you see that could be framed as such because I guarantee you're missing a few.
The beauty of the tree as a data structure is that it captures a common set of algebraic properties. Even when other data structures don't exactly fall under said algebra, the concepts to reason about them are reused (note the early language that specifically said "tree-like").
The point of drawing interview questions from your data structures and algorithms course is not to test you on remembering arcane minutia from 5+ years ago but to see your fundamental reasoning skills within the domain of computer science.
I might be mistaken (and I'm no Haskell expert) but I believe your solution is based on a misunderstanding of the problem.
> Find the Kth highest value in a binary search tree
Your code seems to return _any_ node that is at level K. Where K is 1 for the root node, 2 for its children, 3 for its grandchildren, etc.
But unless I'm mistaken, by the wording of the problem, it's looking for the concretely K highest value, in sorted order. Not "highest in the tree". So if a binary search tree has values (1, 3, 5, 8, 13) the algorithm is supposed to return 8 when K=2, _regardless_ of how the nodes are structured. (E.g. Even if it's unbalanced and 8 is the root node.) Because 8 is the 2nd highest value contained by the tree.
Sounds like a harder puzzle than your interpretation...
I love posting things to the internet that end up being wrong :).
I think this is an interesting look at ambiguity in wording for computer science terminology. In my mind, height or highest always means node height. The term largest should be reserved for numerical measurement. See the next paragraph for a good example.
Correct me if I'm wrong, but the k highest interpretation with an unsorted tree sounds like a simpler problem. If the tree is unsorted, you must traverse the entire tree, sort the result, and then you have your answer. The more challenging problem sounds to me to be what happens when the tree is already sorted. Interestingly, I think the solution for this problem makes my point better than the original problem. Look at how buildHeights breaks the sub problems down. The height (size) of a value in a node at a given level (height) is a function of the heights (sizes) of sub-trees. I included a main method, so you can run the code and not mentally parse it :). What's interesting to me is the commonality in structure between the two solutions despite the problems asking for radically different things.
Note, I probably could not have come up with this solution in the amount of time allotted in an interview because it took a while to find a solution that properly showed problem decomposition.
import qualified Data.Map as Map
data Tree a = Tree a (Maybe (Tree a)) (Maybe (Tree a)) deriving Show
buildHeights :: Tree a -> Map.Map Int a
buildHeights (Tree a Nothing Nothing) = Map.singleton 1 a
buildHeights (Tree a (Just l) Nothing) =
Map.insert 1 a lRes
where
lRes = Map.mapKeys (+1) (buildHeights l)
buildHeights (Tree a (Just l) (Just r)) =
Map.unions [rRes, lRes, curRes]
where
rRes = (buildHeights r)
maxRight = maximum $ Map.keys rRes
lRes = Map.mapKeys (+ (1 + maxRight)) (buildHeights l)
curRes = Map.singleton (1 + maxRight) a
kHighest :: Int -> Tree a -> Maybe a
kHighest k t = (buildHeights t) Map.!? k
main = do
let tree = (Tree 4
(Just (Tree 2
(Just (Tree 1 Nothing Nothing))
(Just (Tree 3 Nothing Nothing))))
(Just (Tree 6
(Just (Tree 5 Nothing Nothing))
(Just (Tree 7 Nothing Nothing)))))
in do {
putStrLn $ show $ kHighest 1 tree ;
putStrLn $ show $ kHighest 2 tree ;
putStrLn $ show $ kHighest 3 tree ;
putStrLn $ show $ kHighest 4 tree ;
putStrLn $ show $ kHighest 5 tree ;
putStrLn $ show $ kHighest 6 tree ;
putStrLn $ show $ kHighest 7 tree ;
putStrLn $ show $ kHighest 8 tree ;
}
=-=-=-=-=-=-=-=-=-=-=-=- Warning Heavy Cynicism Ahead -=-=-=-=-=-=-=-=-=-=-=-=
I've worked at my current job for a long, long time now. Every year or so I decide to peak my head out from it and test the job waters. I get nearly the same set of 4 outcomes each time. I have over 7 years of experience with everything from front-end development to sysops, devops, and management. I've built entire companies by myself in months. Albeit buggy ones.
I bloody hate interviewing.
Outcomes:
1. I get rejected for messing up a programming fundamentals question. Which, honestly stings because, yeah, I should probably be more informed. But, currently, I ain't got no time fo dat. I'm too busy solving a bombardment of problems like: "Hey, programmer X quit, I know you don't work with X language at all but we need this fixed, yesterday".
2. I spend a bunch of my precious time writing a fully functional code test, to be inexplicably rejected. Maybe because I didn't write unit tests? Maybe because I didn't use doc blocks. Maybe I didn't make the code reusable enough given their imaginary scope. Who knows.
3. They're super excited to hire me for a position I am not at all qualified for. Usually for a ridiculously minuscule salary. I had a company ask me, after spending 2 hours on a phone interview, to build and run their development shop. They wanted to on board 50 employees by my 6 month mark, and completely dismantle their overseas workforce.
4. I'm just plain ghosted.
I'm absolutely sick of potential employers asking me why I am excited to work with them. Well sir, to be honest, appearances and mission statements are superficial. I am excited to experience something new. I really hope that your shop lives up to the hype. I am excited to learn.
Take note employers. Saying pretty much anything else is either ignorance or a lie carefully concocted over the countless hours you require of potential employees, just to get in the door. Your interview question responses are almost never genuine talent. They are hours of memorization. I know, because I've asked, and answered them.
Why even require a resume? I've spent hours cultivating a bomb resume and 19 out of 20 employers, have literally no idea what it says.
Employer: "So what languages are you familiar with?"
They're literally listed on the resume that you required I send you, with demonstrations. The one I customized to your company and needs.
A different employer: "So, you don't actively work on any opensource projects, we can review"?
No, I try to have a life when I am not working, and go outside. I know, hiss...
Right now 7:23 PM on Valentines day, I am trying to speed up a program, an MVP, that I rebuilt in a week. One that I acquired after the prior developer got fired. One of my many, many projects. This one is particularly pesky as I am also trying to build out another app that is due, about 23 days from now.
In my admittedly limited experience, there's one way to avoid such nonsensical interviews - run away from bureaucracy. Seek smaller organizations (startups in particular) and if you're lucky enough to have a minimally cross-disciplinary background, you can seek out niche organizations where you'll interview with technical specialists who'll ask reasonable questions that are actually related to your work and your interviewers won't be saddled with "standardized" managment pleasing bullshit. One of the biggest problems I see with modern tech (and large industry in general) is this ridiculous idea that MBAs can standardize all processes across all departments across all industries. This is a source of needless pain and waste - but I suppose it keeps execs happy when they can reduce every metric to a nice little [bullshit] number. Interviewing at FAANG is a case in point.
I've never in my life had to implement a recursive memory optimized underwater red black tree balancing algorithm, and it's insulting to be told I'm not a good enough programmer if I can't pass your totally contrived white board problem. Who the hell are these people even selecting for with these kinds of questions? Do they understand how much talent they're throwing away?
In any case, I have a strong suspicion that, aside from compensation, working for FAANG is hugely overrated. And that's not just sour grapes talk - mountains of red tape, processes upon processes, overwork and burnout, and best of all, you get to spend your best years infecting society with the cancer that is adtech.
I agree on small orgs, but... recommending startups is a bit iffy, IMO. DGMW, startups can be great, but if you're just a good programmer wanting a stable job, then that startup job is not the job for you.
However, you could be a huge contributor and positive influence in a small org... and it's possible to gain a lot of life satisfaction that way[0]. Plus, your employer actually knows you and understands the value you bring, etc. etc.
Yes, you probably will not earn as much as you could by indirectly peddling ads, tracking users, or whatever, but personal fulfillment matters... at least it does to me... and I hire people who feel the same way.
[0] It sounds weird, but studies have shown that giving people agency (as they must be in a small org), setting their own goals, etc. has a positive influence on their well-being and productivity.
I only disagree with "as they must be in a small org". I only wish that was true, but my experience says otherwise. A small company might give one agency or it might not. Or it can do both over time. With a dozen people in the company you'd think it'd be wise, but the latest management trends and compensation procedures prevent it. In other words, we build what the boss wants and have zero incentive and time to work on anything else. In fact, if there is time, I actively avoid any tasks not delegated by management so as not to appear like I'm working on non sanctioned things. But mostly, the time just expands to fill the work. Or the other way around. There is zero incentive to try to change this or do anything not scheduled as it has been shown it'll not be appreciated but with empty words.
That's a very fair point. I can only speak from my own experience on this.
It's a great observation that authoritarian tendencies can probably arise in any size of organization.
(I would advise getting out -- if you can, financially, etc. -- if you do not have self-determination. It's incredibly soul-destroying in the long term. Best of luck.)
I'm principal-ish engineer level, and, after being tempted to go to a FAANG, but turned off by the hazing rituals (and other behavior of some of them), I ended up choosing a startup a few months ago.
Even in best case I can imagine for eventual equity liquidation for the startup, the startup pays only about 1/3 what Google would, and the stress is high at times-- but I've already made crucial contributions to the company's success, my coworkers didn't try to haze me or play other arrogant power games during the recruiting process, and there's a genuine sense of don't-be-evil.
Agreed. I've never had much difficulty finding software development work at smaller companies. If I have the required skills that they are looking for, I'm usually confident that I'll get an interview. An interview at a smaller company is likely to be much shorter and easier than the algorithm-based interviews at larger companies. The chance of an offer is also much higher.
The pay at smaller companies is still good enough for you to live comfortably, even at the entry-level. I worked a software development internship half-time while going to college, and it was easier and more enjoyable than all of the non-programming jobs that I did before that.
If you can't get a job at the companies that you want, you have no choice but to settle for something else until you have the experience and knowledge that is required.
Thinking some more on it, there is another (long shot) way to get hired at a large company: start your own software company that is eventually acquired by a large company.
> start your own software company that is eventually acquired by a large company
Just a heads up, that isn't how it works. If you've built a product that's good enough to be turned into a company and be bought by google/ms/etc, they don't want to hire you. They want your product. If they hired you, you'd steal away their workers to make another startup. At least that's the usual line of thinking.
Source: this happened to 3 friends of mine, whose companies were purchased by Google, Amazon, and Microsoft. Working around startup folk, this is a common story.
Too quick to generalize from your exp; brother founded a company w product good enough to get noticed, but it was an aquihire situation; FB wanted him and his cofounder, not the product/IP.
I've made a career out of working for and with smaller companies. My paycheck is very good and I'm always learning new/different technologies.
Most smaller companies dont have these sorts of interviews. Most of mine have been technical in nature and some involved take-home projects, which were then discussed.
I've also avoided the dreaded non-compete clauses that FAANG employees need to sign and work on my own side-business with no issues.
Presumably he meant IP ownership or something along those lines.
To his other point, take homes have their own problems, especially for anything beyond the most trivial 2-3 task. That said, there are certainly many jobs where you want to see concrete evidence of ability. I'm not going to hire someone for a job that involves a lot of writing without seeing some writing samples. And if they don't have anything they can show me for confidentiality reasons, I'm going to ask them to produce something.
We live in a copy-cat world, it’s endemic in every facet of our society. Look at the NBA, every team now shoots 3s because it worked well for the Golden State Warriors, even when they don’t have the same type of team where that strategy makes sense.
In my experience interviewing people for small companies, I learn towards problems that aren't particularly hard but that demonstrate basic engineering fundamentals. I do value questions that give some insight into the interviewee's thought processes, but it's not necessary to give them a leetcode style question to get there. Startups that try to emulate Google hiring process are pretty clearly shooting themselves in the foot. Thoughtlessly copying successful companies is one of the banes of our industry.
Some companies are solving problems which might demand a higher level of algorithmic rigor in the interview, but it's always worked out for me on the hiring side to consciously avoid Google style questions. I don't think I've given the thumbs up to any truly 'bad hires' for many years, and I've given the thumbs up to many.
I interviewed at some startups from the HackerNews "Who's Hiring?" threads, and I had positive experiences with them. There wasn't much Leetcode BS, it was mostly talking with human beings. (Unfortunately, it turned out I was overqualified and overconfident for the jobs I applied to.. I didn't know that was even a possibility, haha.)
In any case, I have a strong suspicion that, aside from compensation, working for FAANG is hugely overrated. And that's not just sour grapes talk - mountains of red tape, processes upon processes, overwork and burnout, and best of all, you get to spend your best years infecting society with the cancer that is adtech.
It’s a little weird to say “other than comp”, given that almost no one would work for their employer, whether startup or FAANG, if they weren’t getting paid for it. And the difference isn’t small. Multiple startups in NYC offered me comp of around $200k, while the public tech companies were all in the $400k to $500k+ range.
Additionally, I think overwork and burnout are much worse at startups vs big tech. The offer I took pays more than twice as much as the startups and the people on my team are in the office for 40 hours at best, work from home as needed, no emails or slack on evenings or weekends, and take 4-5 weeks of vacation. It’s definitely not the grind that startups are.
Your complaints about bureaucracy and ad tech are fair, which is why I went with Square over G or FB. I like their business model and they’re a fraction of the size of the bigger tech companies, but still pay much better than most startups.
“ mountains of red tape, processes upon processes, overwork and burnout, and best of all, you get to spend your best years infecting society with the cancer that is adtech.”
Your mileage will vary depending on the team you land on.
This only gets worse when you’re old enough to go in, sit in a room across two or three people and realize you have at least as much experience as all of them _combined_ - not necessarily in terms churning out of code in the language _du jour_ or their domain specifics, but in terms of people management and systems design.
There are multiple kinds of dysfunction at work here:
- When I was looking for purely technical gigs I breezed through phone screens and automated testing only to go up against the ageism wall on the first Skype call. Period.
- Recruiters reproducibly drop out of the blue without a clue as to what you actually do or your experience level. Adding “Senior” to my LinkedIn profile measurably decreased the amount of randos that reach out on a weekly basis.
- Puzzle-based screenings are a complete waste of time. It’s not about the prep, it’s about the likelihood you’ll ever encounter those problems. People are much more likely to have to address system design problems, but those cannot be tested for by the online questionnaire cottage industry, so you get mediocre engineers who know how to write fizzbuzz but have zero clue of how to design an order management system from scratch or where to look for issues in an old one.
- Companies often don’t understand what is involved in the roles they hire for--even if you’re a perfect match for the job description (if there is one), the hiring team has an agenda that seldom matches it.
- Engineering is not just about writing code. The second you start asking questions about how teams interact or if they have a strategy for X, the people in the room (or call) are seldom the ones that can get past canned replies.
- Startups tend to be extremely picky and hype-driven. The language _du jour_, their “triple mocha with a squeeze of raspberry” Agile flavor or someone’s pet organizational methodology (teams/tribes/packs/etc.) usually feature prominently in senior interviews, but even VPs _very seldom_ talk about how they manage people--just product and investors.
As a result, I’ve long stopped applying to “normal” engineering positions (and even senior management ones at startups). I drop out of the process (politely) as soon as I get the first hint of automated tests, ageism or VC hype, and prefer networking and getting to know the culture first.
Even so, I’ve had a few notorious duds--I would talk to a VP, have a great conversation, and then have “peer” discussions with people half my age that might as well have lived inside a bubble (and had obvious gaps in empathy and emotional intelligence), or simply have an “OK, boomer” moment whenever the conversation steered into how they managed people growth or I commented on their org structure.
Or I would go through the _whole_ thing and then be told that they wanted someone at “a different career stage”, even though you ticked all the boxes, talked to around a dozen people, and gotten consistently excellent feedback (that one smarted a bit, because it was in a very niche field I was particularly good at).
My key takeaway is that “vanilla” engineering jobs are most often not seen as being long-term hires that bring in outside experience: they are fresh cogs for an internal hype-driven, Rube Goldberg-like contraption that many tech companies cling to and want to preserve at any cost, and the hiring process (and lack of care in it) mirrors that.
This is the obvious point which needs to be repeated till it sinks in. We are not seeing the evidence we would expect to see if this was a tight labor market.
As a point of contrast, consider American industry in 1942, as the nation mobilized for war. It doesn’t matter what profession you look at, the attitude everywhere was “Just show up and we can train you.” That applied to welders and bolt tighteners and also the engineers who designed tanks and aircraft. Every company was hiring and every company was willing to hire inexperienced workers and then train them.
I've gotten a couple of those "show up and we'll train you" jobs but with a catch - the hiring people didn't believe that "anyone" could be trained quickly to do it. But I convinced them that I could.
Now that I've been on the other side of the table for a while, there's no shortage of candidates looking for job, but there's a (real or not) perceived shortage of quality candidates. And the thing that makes it really screwy is that we don't even know how to train developers very well. CS programs don't teach the "art"/"instinctual" part of it, bootcamps don't, even many jobs don't. Yet the difference between a bad codebase and a good one can have impacts a project that persist for years after those first developers have moved on...
> We are not seeing the evidence we would expect to see if this was a tight labor market.
The evidence of a tight labor market is in remuneration. If the appropriately skilled labor was so abundant, then there’s simply no way to explain the remuneration.
You can use some pretty simple first principles to explain the hiring practices. If you were advertising a high salary position in a tight labor market, what would you expect to happen? I would expect a huge amount of low/no skilled applicants to apply, and a small amount of appropriately skilled ones. Anybody who’s tried hiring to a decently paid engineering position has seen this for themselves. How would you expect companies to deal with this? I’d expect to see rigorous evaluations being performed on candidates.
The software industry also has some additional confounding factors, in that it’s filled with low quality products (although for which there is still plenty of demand). The average software product is low quality and poorly coded, because that’s the only kind of product that the average product manager, technical leader or software engineer knows how to make. Software is a very immature industry, and a result of that is it essentially has no consistent standards for quality. So if you want to implement your own standards, you have to content with the fact that a majority of the labor market won’t be able to meet them.
I once interviewed a "senior engineer" who was nearly twice my age. I was very intimidated; his resume indicated that he should be the one interviewing me, not the other way around.
We chatted for a while, and I felt really good about him. However, I had a gut feeling I should just check to make sure he could do the equivalent of fizz buzz. I said something like "Sorry for this formality, I know it might be seen as an insult to your experience... could we do a bit of coding?" His resume indicated nearly twice as many years of C++ experience than me.
I took out my laptop and produced three function signatures - one passing by reference, one passing by pointer, and one passing a pointer by reference. I asked him to explain the difference between the three. With a completely straight face and unshakable confidence he replied "no difference, they are all three ways of doing the same thing". I asked some clarifying questions, trying to probe the difference between pass-by-reference and pass-by-pointer. Again, he answered extremely confidently and coolly (but incorrectly).
"Err, no." I replied. "This ampersand here is a pass by reference, which means c++ handles the referencing and dereferencing of the pointer automatically. It's much safer than the other two, where you are ultimately dealing with a raw pointer and need to check for null pointers before dereferencing". Immediately he broke out into an uncontrollable sweat; it was really remarkable. Before asking the technical questions, I felt really good about him. I wonder how many companies he has fooled.
At this point everyone knows he's a fake. He's not involved in anything technical despite being a "senior dev". It was quite uncomfortable when he was programming and we had to review his code but at this point he's just hanging out in the office and sitting in on meetings.
I wonder about his psychological state. He doesn't seem happy.
It's a story I've been told. Candidate is being interviewed for a senior position, there are three employees conducting the interview: one HR rep, one (non-technical) manager and one senior engineer.
The engineer supposed to help with the interview arrived late so the HR rep and manager briefed him, basically telling him the interview was going well and that they were considering hiring him unless he had any objections.
Going back, he asked the candidate a simple Fizz Buzz question, something like finding the largest element in an array. All hell broke loose suddenly. He was outraged and started telling them that, back in his country he was a university professor and that this was beneath him. The interview ended with the candidate arguing for 10 minutes that he shouldn't have to do this test. If I recall, at this point the senior engineer just left the room and didn't bother with the remaining 15 minutes of the interview.
Needless to say they didn't hire him. HR was shocked as he seemed to be a great hire.
Fast forward a few years later, I'm the one interviewing and I systematically get great resumes who can't implement a simple version of word count in 30 minutes.
Yeah, which is why in-person coding challenges became a fashion in the first place. It's shocking to see the number of "software engineers" who manage to engineer for themselves careers where they don't actually engineer software.
If anything, my personal beef with the classic FAANG interview problem is that it's conflating two very different skills. These are "hard" problems, and require some reasoning and logic in addition to coding. What's constantly surprising to me is the extent to which these skills are decoupled. It's routine to find very smart people with excellent math skills who can't code, and the converse.
And the really mind-bending thing to me is that of the two, it's coding which is by far the rarer skill!
This statement applies to software developers of all ages and fortunately it is very easy to identify these kinds of developers.
However, using the write an algorithm test for this can be problematic as it can easily eliminate software developers who are very good at coding and problem solving, but have chosen not to spend their time memorising the inner workings of standard algorithms, in the hope that one day they will be asked about them in an interview situation.
I don't need to know how to write my own hash table to know how, why and when to use a hash table.
I don't need to implement my own sorting algorithm to sort my list of items.
These and many more standard build blocks come pre-built and ready for use as part of the software development kit.
It honestly is shocking. I tend to ask a question that I think would be an easy 101 homework assignment, and easily a third of candidates fail it so poorly I could end the interview right there. Another third fail, but close enough to where there's a bit of hope if they did the rest of the interview perfectly.
It's basically a word problem that can be solved with a for loop, and you wouldn't believe the number of people who hard code for the values in the list instead of just looping through it (think 10 if statements).
If the problem was oversupply, we wouldn't be getting the cushy salaries and benefits we do. I think the issue is more that it's pretty easy for people with no programming ability to appear competent on a resume, especially to a clueless HR rep or headhunter. There are a lot of people out there whose backgrounds look good on paper who can't solve FizzBuzz...
For most programming jobs wages are lower now than in 1995. Back then, I had many friends who were charging $100 an hour just to build VisualBasic apps and they had more work than they could handle. And Phillip Greenspan has written that his company, from 1996 onwards, offered $100,000 to recent college grads. That was really good money back then, especially if you wanted to buy a house.
Wages right now only look good compared to where they were during the depths of the Great Recession. Over a longer time frame, wages look terrible, except for certain jobs at FANG companies.
That’s my point. Ars Digita (Greenspan’s startup) was a small startup. You don’t see small startups paying 170k as a base salary nowadays.
All available evidence shows that wages have fallen for software developers. If the market for software developers was tight, then we would see very different behavior from companies.
There's such a flood of qualified labor that employers can afford to arbitrarily shrink the pool of applicants without significantly worsening their outcomes. Their behavior indicates that just the top N% of the market is enough to fill the needs of all selective companies. "Top" can be a semi-random filter, since the pool of basically competent people is much deeper than N.
(There's also a much larger flood of people who aren't qualified, which definitely complicates the process.)
All else equal, if employers simply stopped rejecting qualified applicants for arbitrary reasons, they could solve the "shortage" overnight and pay much lower wages that developers would still accept. But all else isn't equal. Their past decisions shaped the playing field, so now external-but-related factors like the housing market and competitors' responses limit their options in practice. They can't just take a bunch of people and drop wages, even though they "could", without disrupting other things that aren't worth disrupting.
Edit: Too late to delete, but this is not a good analysis. Companies are clearly feeling some pressure to do something, but there are too many unknowns in this to draw the conclusion, and a ton of factors I've ignored.
Not exactly. If every employer randomly threw out 80% of the resumes without looking at them, and then perfectly evaluated the remaining 20%, then you would expect that all qualified developers would have a job (they just might have to apply to several jobs to get an offer).
I don't think the filter is literally random. It's a poor predictor of success, applied inconsistently.
Just from what I've heard and experienced, I'd guess that if N = Q (percentage of qualified workers), everyone in N would find some job as you describe. Alice gets Apple and Google but not Netflix, Bob gets Netflix but not Apple.
Could Alice do Bob's job at Netflix, or vice-versa? Absolutely. Does Apple care they could have had Bob? Does Netflix care they could have had both? Not really.
Everyone in N lands somewhere, eventually, enough though a better process could have had a better outcome overall. Maybe Alice really wanted Netflix; maybe she picks Netflix-like projects at Apple that aren't Apple's best use of her skills. Maybe that rejection shook her confidence or maybe she's distracted getting ready for another Netflix interview next year. (She's learned she has to study really hard at who-knows-what to prove she's capable of doing a job she's already doing.)
Does Apple care? Not really. Her manager might, but not Apple. Inefficient allocation is death by a thousand cuts.
The greater problem is when Q > N and the difference keeps growing. If you take the Googler joke of PhDs as protobuf jockeys at face value, that's where we've been for a while. But I don't know if we are.
I think this point is really key, more than the general idea that "there isn't really a short supply of good programmers." It's imminently easy for a rich capitalist to tell the difference between a factory laborer who works hard and one who does not, than it is for them to say the same about an engineer; the evidence is plain as day in front of you. Longer hours, more sweat, quantitatively more physical tasks done, period.
For engineers of most sorts, the signals are actually counter intuitive, a lot of the time. There's the easy cliche story of two engineering teams tasked to the same project (not necessarily even software only). Team A has a slow and steady road map, no drama, everyone leaves at 5pm, they never make any noise, mostly hit their deadlines, even if the deadlines are unambitious, etc. Team B always is fighting fires, huddled around someone's desk talking, always working overtime burning to make aggressive deadlines that are never quite reached anyways, always communicating with the wider company about status of issues and problems, etc. Which is the more effective team? Team B will definitely be "known" more in the wider company, and might have more individuals who respect them and think they are hard workers. If you took a "peer survey," Team B might actually still come out ahead. But they may still be a much less effective team for the larger business in a lot of ways.
I think the cushy salaries come from the fact that programming done right is extremely profitable. So the capitalists toss a chunk of money to the engineers.
That's what I think every time I see one of these articles but tech companies still have a permanent door into every congressional office to plead the exact opposite while seeking to import more labor into the market.
I think you'd be surprised at the sheer number of unqualified^ applicants that apply though. It's possible to simultaneously have more qualified applicants than you need and even more completely unqualified applicants trying to bullshit their way to a job. Filtering them out can be tricky.
^When I say qualified I mean the informal sense - is able to do the job, not has a university degree.
Bad example really. There are many companies where you don't need to know this stuff, Google is not one of them. You want that 350k a year, but you don't know the basics about computer science to find the k-th highest element in a BST, well doh. What can I say...
To be honest, this is really a super simple question and I would be stunned if this was anything but a warmup for you, like the interviewer giving you a simple question to get you into focus. I haven't done anything with BST in years but still I could easily do this with a piece of paper. Back in the days, Google was asking to insert an element in a Red-Black-Tree. Well, this is a clusterfuck and far too specialized. But questions like those were rightfully banned.
Yeah sure, it's not what you do all day, but not being able to answer these questions has implications. There are many code monkey mills where you just write some JS code to hack a webpage together and it would seriously bother me if they would ask you such questions.
Just rethink what you really want. FAANG is not for everyone.
> To be honest, this is really a super simple question and I would be stunned if this was anything but a warmup for you, like the interviewer giving you a simple question to get you into focus.
> Back in the days, Google was asking to insert an element in a Red-Black-Tree. Well, this is a clusterfuck and far too specialized. But questions like those were rightfully banned.
Our blindspots are pretty funny. I can assure you that many people thought Red Black trees were easy enough and if you had a hard time, their advice would be:
> Just rethink what you really want. FAANG is not for everyone
I disagree - the recruiters are forced to be the messengers of dysfunction. I've seen some pretty reprehensible examples of this where I actually felt sorry for the recruiters.
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.