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."
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.
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...
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.
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.
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).
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.
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.
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.
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.
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?!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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 :)
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. 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.
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.
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.
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.
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).
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.
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...)
>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.
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
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.
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.
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.
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...
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.
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.
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.
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.
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.
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 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.
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).
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!
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.
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.
“ 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.
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.
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.)
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 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.
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.
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.
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.
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."
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.
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.
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.
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.
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.
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.
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”)
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.
> 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.
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.
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).
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.
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-...
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.
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.
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.
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.
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.
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.
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.
> 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 !
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.
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...
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.
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...
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.
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.
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.
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.
You're speaking as if you have experience with this but looking at your LinkedIn and previous comments, you have zero years professional software dev experience?
Yet, you speak so authoritatively and decisively in this comment and your parent comment. The other people responding (including me) all have multiple years experience in actual software companies of all sizes.
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.
Yet you spoke as if you had worked at some/any software company. Literally zero years dev experience (FAANG or any other). Zero software interviews. You have zero knowledge or experience of what we're talking about.
Looking through your LinkedIn/comments is low effort and confirmed my suspicions of you being whatever the inverse of Dunning–Kruger is.
If GoT was still relevant, I'd wistfully look at you and whisper "You know nothing, Jon Snow"
> 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.
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.
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.
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.
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.
> 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?
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."
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.
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.
> 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.
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.
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.
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.
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.
Every time this discussion pops up, there's this naive idiot who thinks that because he's good at these types of interviews, anyone who isn't must be incompetent. They always without fail mention "high-pressure" situations and ignorantly assume that people with performance anxiety can't handle a completely different type of pressure. They also make the ridiculous assumption that pressure is objective. This time, that idiot is you.
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.
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.
> 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 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.
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.
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.
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.
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).
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.
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 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?
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.
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.
> '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.'
Is that really what you think? Here's the harsh, cold reality: psychologists are mostly quacks. The fact that you so strongly believe otherwise shows that your brainwashing runs deep.
In reality, it's quite possible for awake and learned persons to study and understand the thinking of others. I do it every day. Case in point:
> 'why should i believe that you a random software engineer have any competency whatsoever.'
It seems you're one of those 'specialist' types, who is so much of a specialist that they actually believe being hyper-focused on one narrow thing to the complete and dimwitted exclusion of all else is the only possible mode of existence.
God help you if you were ever to learn that there are actually other types of people out there in the world who in some cases know twice as much as you do about your given area of 'expertise' plus 1000x what you know of anything else.
> '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.'
Not everybody is average, dimwit. Especially the sort of people who are supposed to be interviewing top tier programmers. And not everybody is an autistic dweeb who can't understand other humans.
Poker players have a saying: if you haven't figured out in the first 5 minutes who the mark is, then you're it. Get a clue, noob.
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
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.
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?"
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
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.
> 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
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.
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.
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.
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.
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.
> does the candidate want to code it up or understands that they could do: cut | sort| head
Piping together commands is undoubtedly programming, just in ancient shell script. So in a sense you're really testing for bash expertise. Which is maybe really relevant to you but I wouldn't say you're really "avoiding" coding by knowing to use those commands together, you just decided to code it with obscure shell commands. I might fail your test by choosing to write that sort of thing in python, because I could write it much more reliably in 10 minutes than deal with all the incredibly weird things that can happen in bash. I mean the final product in bash might be slightly more elegant, but your terminal history is probably littered with "man cut" and various attempts at it.
But for your example, my answer might be: if you're querying this file once, you may be querying it again, it's probably just way simpler to load the thing into sqlite instead of trying to imitate sql with some janky unix commands.
> everyone with real work experience has a story about sorting.
I am 34 and an experienced coder and I literally have no stories about sorting, and I've never once wanted to sort a CSV file on the terminal.
sqlite answer - excellent, that is exactly what I am looking for, things people did, potential solutions let me understand the candidate's real background - not the buzzwords
what is not well received is the judgmental tone, passing judgment about me for things you cannot possibly know, no need for that either, simple questions also irritate some, very important to weed those people out too,
I expect you would fail the test because of the attitude, even though if this were a real job interview you'd do your best to suppress it, it would come out
Dear God, I hope you don't do interviews. Talking about the "attitude" of someone you don't know, taking criticism personally, thinking that you are weeding people out by trying to "irritate some", suggesting they are trying to suppress it, and (of course) that you will be detect it. Every thread on hiring about HN has these weird passive-aggressive interviewers...interviewing is hard, it is really something that people should be trained to do (and some people really won't ever be able to do it).
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 :-)
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.
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."
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.
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.
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".
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.
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.
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...
> 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.
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.
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.
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...
“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.
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.
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.
850 comments
[ 3.6 ms ] story [ 523 ms ] threadThe 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.
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.
- 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.
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.
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).
https://en.wikipedia.org/wiki/Topgrading
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.
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 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.
The one time I recorded a video I had to redo it like 10 times and I eventually just submitted it because I was tired of the shit.
cover letters are terrible anyway. the signal to noise ratio there must be comical.
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.
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?!
- 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.
https://www.insider.com/van-halen-brown-m-ms-contract-2016-9
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.
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.
Very large online retailer is 100% this.
It's a recipee for fake.
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.
I mean what stupid game is this.
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.
Thanks for dropping in the defense here, I've never heard of this process.
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.
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.
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.
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.
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.
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 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're describing a good manager, who costs a lot of money, even more than a good SWE.
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).
Maybe the high salary is to compensate for something else (poor work environment, boring job, etc) rather than attract very skilled people?
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).
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.
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...
Additionally, IDK how many times I've found people using different lingo to describe the same thing in this field. It's like a bigger version of this: https://hbr.org/2018/07/what-to-do-when-each-department-uses...
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.
Applicant: 600,000 golf balls
Recruiter: What about a coffee?
Applicant: Because the man hole is round
> I hope we can find a bit more maturity in our industry
Me too
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.
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.
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.
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.
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.
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.
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...
I think this is a really important point.
What does it mean to be a good developer? How do we know?
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.
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.
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.
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'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 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!
^When I say qualified I mean the informal sense - is able to do the job, not has a university degree.
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.
Your mileage will vary depending on the team you land on.
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.
This kind of person would probably refuse a FAANG / GAFAM job, even if asked for it!
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.)
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.
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.
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.
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.
spot on.
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.
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.
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.
It is necessary to do well on coding interviews, but not sufficient. optimizing for coding interviews is the wrong approach.
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.
To HR, the engineer hiring process is voodoo magic and we best not touch it.
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.
I'm pretty sure the only meaningful coding test is if you can program at all. After that everything becomes artificial in an interview setting.
I think most things you can write in less than 30 lines of code or so could be reasonably written inside of 45 minutes. Like this Lisp interpreter in JS http://canonical.org/~kragen/sw/dev3/terp.js or this octal-to-binary converter in assembly http://canonical.org/~kragen/sw/dev3/osmb.s or this Collatz-sequence searching program http://canonical.org/~kragen/sw/dev3/collatzsearch.py or this paren-matcher in Scheme http://canonical.org/~kragen/sw/dev3/pmatch.scm or this paint program in C https://gitlab.com/kragen/bubbleos/-/blob/master/yeso/%CE%BC... or this Unicode Wang tile ASCII-art maze generator http://canonical.org/~kragen/sw/dev3/uniwang.py or numerous other things like that.
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.
Though some would take longer than 45 minutes.
archived version from feb 2019 since cloudflare dns seems to be broken atm: https://web.archive.org/web/20190219135427/http://rosettacod...
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."
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.
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.
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.
If you actually read the linked article, there aren't really any interviews.
The OP is just getting let down by recruiters.
It seems that you were the one who didn't read the article. He mentions several.
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.
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.
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”)
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.
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.
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.
Edit: Fixed a typo.
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.
It's just stupid nonsense like "writing spreadsheets for the local government" and minor web development. In tech, it really is US vs. ROW
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.
I’m not 100% sure - I have less insight into this.
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.
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.
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.
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.
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.
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.
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.
Good luck!
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).
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.
I still don't like DRM on content I'm buying.
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 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.
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.
but it is true that these questions bear no resemblance to software engineering so it does feel silly going through the process.
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.
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...
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.
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.
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.
Yet, you speak so authoritatively and decisively in this comment and your parent comment. The other people responding (including me) all have multiple years experience in actual software companies of all sizes.
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.
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.
Yet you spoke as if you had worked at some/any software company. Literally zero years dev experience (FAANG or any other). Zero software interviews. You have zero knowledge or experience of what we're talking about.
Looking through your LinkedIn/comments is low effort and confirmed my suspicions of you being whatever the inverse of Dunning–Kruger is.
If GoT was still relevant, I'd wistfully look at you and whisper "You know nothing, Jon Snow"
It states that experts tend to underestimate their ability and amateurs overestimate their abilities
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.
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.
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
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.
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.
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.
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.
[1] https://www.washingtonpost.com/news/answer-sheet/wp/2017/12/...
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.
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.
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?
Nope, you're actually claiming that they're bad at product. Maybe you can question their product management or marketing hires?
Their most successful product is still search, followed by android and youtube. Their stock is up 300% in the past 5 years.
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.
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.
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.
> 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.
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.
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.
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.
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.
[1] https://en.wikipedia.org/wiki/Griggs_v._Duke_Power_Co.
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 also interview badly frequently but not due to poor test performance but due to my demeanor in an inherently awkward situation.
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
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.
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.
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.
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.
Unless you’re hiring for a detective that has to write code to stop crimes in progress why are companies so focused on testing coding under pressure.
- 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.
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.
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.
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.
However, I wonder if oftentimes companies are aiming for..
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).
Because the cost of hiring the wrong person is a LOT higher than missing out on the right one.
Why can't anyone come up with a good solution for this? A "we'll hire you for a month and see how it goes" kind of deal?
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!).
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?
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.
https://leetcode.com/problems/merge-k-sorted-lists/
https://www.geeksforgeeks.org/external-sorting/
and it's literally called "merge sorted files" (page 175 of elements of programming interviews).
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.
...
> 'clinical psychologists go to school for a long time to learn how to assess people's abilities to think.'
Is that really what you think? Here's the harsh, cold reality: psychologists are mostly quacks. The fact that you so strongly believe otherwise shows that your brainwashing runs deep.
In reality, it's quite possible for awake and learned persons to study and understand the thinking of others. I do it every day. Case in point:
> 'why should i believe that you a random software engineer have any competency whatsoever.'
It seems you're one of those 'specialist' types, who is so much of a specialist that they actually believe being hyper-focused on one narrow thing to the complete and dimwitted exclusion of all else is the only possible mode of existence.
God help you if you were ever to learn that there are actually other types of people out there in the world who in some cases know twice as much as you do about your given area of 'expertise' plus 1000x what you know of anything else.
> '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.'
Not everybody is average, dimwit. Especially the sort of people who are supposed to be interviewing top tier programmers. And not everybody is an autistic dweeb who can't understand other humans.
Poker players have a saying: if you haven't figured out in the first 5 minutes who the mark is, then you're it. Get a clue, noob.
This answer would make you fail the interview :-)
Hope I never pass your interview!
This sort of thing is sadly common in interviews, where the interviewer some arbitrary answer in mind and expects you to read his mind, which is possible only some of the time.
By definition you can't sort an infinite list. You've conveniently turned the question, in your mind, into something like "how do you efficiently maintain an ordered list of incoming items?"
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
If a list is sorted, then you'd be able to return the largest value. Since that is impossible the correct answer is that it's impossible.
This sort of utter nonsense question, heavily loaded to your "standard" experience, which is anything but, is even worse than the questions cited in the article.
All you're doing is filtering for people who are in your tribe, who followed the same path as you and think like you, use the same tools as you and the same OS as you.
Pretend all you want, but you're filtering not by "experience" but by trying to find people in your tribe, which is naturally heavily weighted.
I didn't realize Linux Users counted as a race now :D
OP asked a very open ended question, merely made a suggestion that it could also be done with some standard Unix programs (I grew up on windows and even I know about cut and awk because you spend enough time anywhere in tech you will know these). Why it triggered you, not sure, but perhaps the question it's doing its job after all.
I've watched a number of new grad hires pick up bash, vim, and version control from scratch in a month or two and go on the be very successful. For better or worse some good schools don't cover those sorts of ancillary skills, and not every good candidate will tinker with Linux as a hobby.
I am not selecting for a tribe, I am selecting for a job. The questions are loaded, of course. Among the many duties, the jobs do require processing large files, sometimes with cut, Python or C. I want the candidate to use the most appropriate tool as needed. I'd rather not have people implement functionality that already exists in the 'comm' command.
Of course, I want the candidate to ask me what the column separator is. That's why the question is formulated that way.
The right answer will depend on the column separator. Proposing the UNIX cut if the file is CSV is not such a good answer, but for tab-separated files, it is just fine. If the file is CSV and they tell me about cut, my next question would be if that is a good universal solution for CSV files in general.
When someone that knows about the pitfalls of using cut when parsing CSV it shows me they have indeed had experience with that.
Do you see why this question is the best... the possibilities are endless, and the rabbit hole much deeper than it may seem
TSV and CSV have the same limitations. A tab-separated file could still have tabs inside a field depending on the quoting convention. Either separator could be used with cut. I can't believe you are so confident in your partially truthful answers.
Oddly no one has heard of that, the only reason why I found out about it is because I had to read in punched tapes with 7 character ascii from an experiment done in the 80s during my undergrad.
https://en.wikipedia.org/wiki/Delimiter#ASCII_delimited_text
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.
All tech interviews start with a need to legitimize and reinforce the interviewers as successful and talented ....
Even if we're basically all terrible
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.
i.e. Be careful with your phrasing. That is a bias in itself.
I guess this is not what the questioner meant because they referred to using cut | sort | head as a solution. Though, I don't understand why head would be at the end of either problems solution so maybe I'm missing something. head could be a useful way of peeling out the column you want in the column-oriented problem.
This is like complaining that you can't read the basics of a new programming language.
An example was a whiteboard problem requiring the BETWEEN syntax for SQL window functions, which is very uncommon. After I asked for a hint, the interviewer replied "You don't know the BETWEEN syntax for window functions? Everyone knows that."
I could tell I annoyed my interviewer when they told me I was wrong and I demurred, and politely asked them to look it up since there was some question about the facts. They did not look it up.
Good times.
On a take-home test around that time, the question specifically said to use PostgreSQL just because the answer required a window function.
> does the candidate want to code it up or understands that they could do: cut | sort| head
Piping together commands is undoubtedly programming, just in ancient shell script. So in a sense you're really testing for bash expertise. Which is maybe really relevant to you but I wouldn't say you're really "avoiding" coding by knowing to use those commands together, you just decided to code it with obscure shell commands. I might fail your test by choosing to write that sort of thing in python, because I could write it much more reliably in 10 minutes than deal with all the incredibly weird things that can happen in bash. I mean the final product in bash might be slightly more elegant, but your terminal history is probably littered with "man cut" and various attempts at it.
But for your example, my answer might be: if you're querying this file once, you may be querying it again, it's probably just way simpler to load the thing into sqlite instead of trying to imitate sql with some janky unix commands.
> everyone with real work experience has a story about sorting.
I am 34 and an experienced coder and I literally have no stories about sorting, and I've never once wanted to sort a CSV file on the terminal.
what is not well received is the judgmental tone, passing judgment about me for things you cannot possibly know, no need for that either, simple questions also irritate some, very important to weed those people out too,
I expect you would fail the test because of the attitude, even though if this were a real job interview you'd do your best to suppress it, it would come out
But this is the irony---a job interview is a judgment. Why do you think feelings on this run so high?
How is this relevant? Now you're just taking cheap shots.
"I wouldn't hire you with that attitude"
I'm getting more judgemental vibes from interviewer than interviewee.
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.
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.
If the data is on a filesystem, then sed, grep and cut pipelines will likely be your fastest option (Yahoo! processed petabytes of logfiles for decades that way.)
If the data is already inside a database table and indexed well, that could be fast enough. But generally speaking, the ETL is often a bottleneck. And DBAs are $$$$ compared to "the UNIX way."
Source: DBA
But maybe that’s more about separating sheep from shepherds.
Learning sort and cut takes literally takes all of 10 minutes, so if it makes you pass over an otherwise qualified candidate you have your priorities completely backwards.
Generally speaking, people like this have never actually dealt with large data sets, never dealt with issues involved with installing "unapproved software" on a machine (ridiculously common in The Real World), has probably never cleaned a dirty data set (what do you do when your giant csv is formatted in a way that Wes McKinney didn't think of?), and will in a senior role be a long term liability for a data science team that works on serious problems. Sure at one point I didn't know about them either: I wasn't a senior data scientist then. I submit that if you don't know about them and haven't actually used them, you aren't either.
Another good weeder for a person claiming to be senior: discuss how you would fix the performance of the default R naive Bayes implementation in e1071. It's numerically more or less correct, but written by deranged ape-men who don't understand how computers work (a problem in a lot of the R ecosystem; in the Python ecosystem, the problem is nobody has yet written algorithms for X, which ends up being a very similar problem: aka it's your job to code up sane algorithms).
OP is using knowledge of a specific technology as a heuristic for "has experience in role x"
But this always makes me wonder, couldn't you see that experience from a resume? If the candidate filled a data science role at somewhere reputable for 3 years, and you verify that they successfully filled that role, why rely on that heuristic?
As you say testing for the specific technology, when it can be learnt in 10 minutes, does not seem logical.
> Generally speaking, people like this have never actually dealt with large data sets
I'm a bit younger, but have done this dozens and dozens of times.
----
A lot of one off processes are way easier to handle with a bunch of terminal commands and pipes.
there is some simple elegance and power to these old C tools
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".
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.
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.
I suppose we could agree that college admissions are as broken as tech interviewing though...
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.
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.
What did Netflix do? And don't we like Apple now? They ship crypto to billions that annoys the government's spyware programs.
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...
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.
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.
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.
Depends on which FANG. And G/F with their refreshers means the gap will widen significantly year over year