AWS rejected me since I failed to write prefect code to traverse a tree in level order. Google did not even give me an interview since I told the campus recruiter I have not prepared for the coding questions.
Then I ended up with an internship at CoreOS and created etcd. I am glad that they did not hire me back then.
Today, I am sure I still cannot pass the coding interview at "Giant Search and Advertising Company", but they run a lot of my code in production :P.
Cynical answer though — Google does not want people like you. They don't want to hire entrepreneurs or inventors. They want people who can churn out code when given specific instructions, and that is what their interview process optimizes for.
I've done some pretty interesting things in biotech in my career, things that required learning about motion control, digital imaging, signal processing, and biology... but if I want a job as a web dev I apparently need to memorize how to implement every sorting algorithm... on a whiteboard... in ten minutes. The fact that I know which to use when is irrelevant. Bleh.
"If tests truly were tests of learning, things wouldn't be so bad. Getting good grades and learning would converge, just a little late. The problem is that nearly all tests given to students are terribly hackable. Most people who've gotten good grades know this, and know it so well they've ceased even to question it. You'll see when you realize how naive it sounds to act otherwise."
The greatest programmer I've had the privilege of working closely with could easily pass most technical screens, but he's an odd fellow, and I don't think could handle the stress and anxiety of these crazy interviews. Lots of diamonds in the rough out there, but I suppose large companies understand that and just consider it acceptable loss.
Nobody can perform well like that.. One great colleague who I wish I was in the interview for, simple started thinking out loud.
Everything he was thinking, he said out loud, and of course, the team loved it. Because thats all it's about.
If its not over a video chat/submission, comment your code your thoughts, remember, they want to know you chain of though, not your knowledge of a framework/algorithm (unless its very specific)
> Today, I am sure I still cannot pass the coding interview
If you know how to figure out the problem, forget the technical side and explain how you would go and figure it out.
Problem solve. Don't worry.
I hate to break it to you, but Amazon doesn't reject a candidate because he bombed his coding challenge. I know people who received a job offer from Amazon for a developer position although they somewhat bombed their hard skills component. If you were rejected after passing the coding challenge and phone screening interview then odds are you actually bombed their personality and/or soft skills aspect of their interview process.
They are happy. You are happy.
People are jumping higher and higher hoops with a smile.
Everything is for the best in the best of all possible worlds.
Hopefully as a wiser person you have your contingency ready for when the machine come to collect its blood tribute.
That said, I'm skeptical about your particular story. As a process rule, AWS doesn't provide interview feedback, so I'm pretty sure you don't _actually_ know why you were rejected, you can only guess. Perhaps if you were rejected in phone screen(s) it can be obvious, but if you made it to an on-site, I can guarantee (based on experience being in the room during hiring decisions at AWS) that they don't almost someone because of one bad whiteboarding result; there are multiple people collecting and reporting on results and only one person, the bar raiser, has veto power, and I've never seen it used for something as banal as not writing perfect code.
I also don't know what happened in your interview, but consider it's also possible that you completely bombed it: failed to ask questions, failed to communicate properly, or made more mistakes than you even realize.
It's certainly great that you went on to do great things, but maybe at the time you interviewed you weren't yet doing those great things...
I want to work for myself however in the long run and I think the skills are more important for that
We run your code in production too! Thanks!
No, but I can write a storage solution that works even when your dummy engineers are actively melting down servers.
Ah, the difference between "computer science" and "software engineering".
You did the project you wanted.
AWS and Google got the code they wanted.
Your friends for the jobs they wanted.
How long do you think it would’ve taken you to prepare and ace these kinds of coding interview questions? (I bet less than 100 hours.)
But I’m more interested in the following: what interview process do you think would have correctly (and reliably) evaluated someone with your profile?
There are plenty of people who do both. They work on their projects, and when needed, they prepare for coding interviews.
The google interview process was not made to filter you out. It was made to guarantee that they will not make a mistake on hiring you. People with the capability to do those interview problems have a high chance of being good programmers. There are many people like you who can't do those problems but are still very good programmers. Google doesn't need to hire you, the whole interview process is optimized for preventing a bad hire rather than finding people like you who are good hires but can't interview.
Second, traversing a tree in level order is a trivial problem from the interview question perspective. It is more than likely that this question will NOT be given by the interviewer because it is too easy. The interview questions FAANG tends to give are a bit more novel. In fact the method in which you use to solve this problem and the problem itself is often just taught directly in school depending on the class you're in, meaning you don't need to practice interview questions to solve it because it's a basic topic.
The solution is called tree traversal using BFS. If you didn't know this, despite working on and creating things like etcd you will appear stupid because the question is just too basic. When I interview I am 100% expecting questions way harder than this... even on phone interviews. Additionally when I'm the interviewer this type of question is the lowest bar, I will fail someone who can't answer this question.
This is not to comment on your abilities. Rather it is to give you a dose of truth. I truly believe that there are many people like you who can program an entire kernel but can't even solve fibonacci recursively on a white board. Despite this I can't stop judging you based off of the white board question nor do I know how to confirm that you can write a kernel despite lack of ability to solve very very basic programming questions.
I 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.
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.
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.
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.
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 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 only sharing that factoid because I find it interesting. Maybe Herbert was a terrible engineer by today's standards. He almost certainly wouldn't be president today for completely different reasons, but would he be have been accepted into Stanford? Would he even make it as an engineer? I don't know--certainly not if we put as much weight as we do on tests.
I 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.
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.
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.
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.
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.
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.
- 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.
A few days later I got an email saying, "Sorry, we're going to pass. The feedback from the person who reviewed it said that, 'It crashed with res.flat() is not defined when we tried to run it'".
"That's weird", I thought. I assumed they were running it in a different browser that lacked Array.flat(). Annoying, but maybe browser compatibility was part of the test (it hadn't been stated as such). So I did some digging just to be sure; I asked what version of NodeJS they were using. Version 10. Turns out that version of Node is somewhat old and doesn't have flat(). Huh. Dug some more.
.flat() wasn't even called in my code.
The stack trace went down into NextJS itself. They had given me a project with a particular dependency declared and then run it in an environment which was incompatible with that dependency, and then immediately punted it without any further debugging. I tried to engage my contact via email, presenting the proof that it wasn't my fault. I got an icy "Thanks for your feedback, we'll forward it to our hiring team", followed by silence.
Go in for the in-person interview which goes extremely well, but talking to their two most senior engineers it seemed like they had just recently learned what OOP is and "drunk the Kool Aid". I found this extremely odd given that this was well into the 2010s already.
They gave me a take-home exercise which was basically to implement some feature with Laravel using established best practices. I turn in something that's clean, documented, with tests, using the documented best practices (like literally from the Laravel docs), and extremely performant (would scale to a high volume of requests). Functional style though, broken out into 1-3 line functions that only do one thing -- similar to what you'd expect from a Rubyist.
Rejected and they told my friend that I don't know how to code. My friend knew better and got a new job himself a month later and I went on to much better things.
Basically, if the code looks right and you can show it working on your system, we're pretty understanding. The goal of a takehome isn't perfection - it's to demonstrate underlying abilities.
Now I abandon any interview that requires a code assignment. I have better things to do than mind reading or dicking around with subjective code style nonsense. If they are taking this seriously they will provide their grading criteria along with the assignment text.
You have demonstrated solid debugging skills and stated your case. That's usually harder to find than someone who can churn out code based on simple and well-defined specs. Because that's the easy part.
Be similarly wary to point out bugs in code reviewer's code. Unless you have a healthy professional atmosphere and multiple reviewers, your best course is to manipulate the reviewer into "coming up" with the idea for the bugfix from your ticket.
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).
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.
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.
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.
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.
It's a recipee for fake.
It is absolutely definitely not the actual top grading of multi hours of interviews , phoning references etc.The question would go like this:
Suppose I have a column-oriented file and I want to print out a column in a reverse-sorted order. How could I go about it?
This question is among the most effective ever. First it filters out the FizzBuzz failures right away, let's you see immediately how people think (does the candidate want to code it up or understands that they could do: cut | sort| head)? It lets you explore the various aspects of sorting numerical, alphabetical, different locales, in numerical you can have generic numerical sort etc. Then what if the file is really large, now a much better approach could be to split sort then merge sort back into one file.
everyone with real work experience has a story about sorting.
but then you can move on, let's do it in your favorite programming language, then explore of what if the data is "infinite" long, a stream ... and so on
it is a topic that can produce very interesting solutions, nobody is stressed out, and people that "fail" do understand why.
Edit: I will also say I feel that I can learn more about a person based on how they respond to easy questions. Are they cocky, are they showing off, are they rattled etc.
> does the candidate want to code it up or understands that they could do: cut | sort| head
Piping together commands is undoubtedly programming, just in ancient shell script. So in a sense you're really testing for bash expertise. Which is maybe really relevant to you but I wouldn't say you're really "avoiding" coding by knowing to use those commands together, you just decided to code it with obscure shell commands. I might fail your test by choosing to write that sort of thing in python, because I could write it much more reliably in 10 minutes than deal with all the incredibly weird things that can happen in bash. I mean the final product in bash might be slightly more elegant, but your terminal history is probably littered with "man cut" and various attempts at it.
But for your example, my answer might be: if you're querying this file once, you may be querying it again, it's probably just way simpler to load the thing into sqlite instead of trying to imitate sql with some janky unix commands.
> everyone with real work experience has a story about sorting.
I am 34 and an experienced coder and I literally have no stories about sorting, and I've never once wanted to sort a CSV file on the terminal.
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.
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."
As a FAANG data scientist, I've never once wanted to use cut|sort|head nor have I wanted to work with CSV's. Everything is already sharded and encoded as a schema-enforced binary encoding like protobuf or thrift. The file is so large its better to favor Apache Beam or equivalent to parallelize the aggregations of particular fields over very large amounts of data. But, hopefully you just use some SQL-like interface such as BigQuery that when pointed to sharded files, can easily do aggregations for you with SQL-like language (which, kicks of distributed computing jobs under the hood and is not truly relational). Unless you're streaming data, then that's another question.
Testing unix commands is narrow minded IMO. If you want to test divide and conquer plus streaming, then just ask a flavor of that Leetcode question.
My partner is learning about data science now so I asked them if I could try this question on them in the context of a data science interview, first thing in the morning and without coffe. They looked at me and said "being asked data science interview questions by your spouse right after waking up is the worst thing in the world but I dunno I would load it into pandas and put it in a data frame". And like honestly that's not how I would do it (I would do awk | sort | head because I always forget the cut column options) but the whole point is that the answer prompts further discussion. Now I know to ask about python and pandas (the thing the candidate uses and knows), and not, I dunno, scala and cascading/scalding or whatever (the thing that I know or use). Good questions investigate what the candidate knows. Bad questions investigate whether or not the candidate knows the things you already know.
People on this site are way too concerned with "being correct".
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).
Say NO to this bullshit. Establish a deadline and clear guidelines and expectations:
1. I will not be doing any take away work at all.
2. You will explain how my GitHub repo, resumé, previous experience is insufficient to qualify me for the job in 100 words or more.
3. You will sign an NDA for whatever solution I created to whatever problem you task me with. You do not own my solution’s IP and may not share it outside of the people involved in my hiring process without my consent. 4. In the case where I fail the test you will explain in 100 words or more why my solution was unacceptable. 5. In the case my solution doesn’t compile/run you will allow me 3 attempts/1hour to provide you a solution and/or give me a Dockerfile representing the env where my solution will be tested.
Any interviewing experiences, really, but bad ones too.
I would definitely decline to continue to interview a candidate if I received this list of demands. The tone is unbelievably entitled and screams "difficult to work with". The suggestion that I would sign an NDA on behalf of my company is absolutely absurd. I would never sign something on behalf of my company without consulting our legal counsel, and I would never continue an interview if I had to involve my legal counsel to determine whether or not a person can code.
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.
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).
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.
Personally I get a huge kick out of making massive improvements to a small business's tech and infrastructure. The lack of bureaucracy is a freedom that is often taken for granted. If you have the vision and drive, you can improve the business's processes and product offerings by leaps and bounds...something I would argue is not readily available at a big company. Smaller companies are also much more willing and able to negotiate with you to help balance your life. A 4-day work week for example.
Again speaking anecdotally, I don't need that much money. I certainly don't need FAANG-level compensation. If I'm going to work somewhere, it's going to be because I want to be with those people, working on those problems, and having a big impact. Not because of the fat paycheck.
There are teams in FAANG that are like that. And I'm going to say mine, as we're a new team building a top level public service for a very large cloud company. It does mean sometimes there's lots of work though.
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.
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.
That's… an unusually consistent signal. Suggests to me that either this person is getting into the wrong interviews (eg junior interviewing for senior role—though they say that's not the case), or more likely there's some hidden variable, like a bad reference, bad BO, really noticeable "culture" misfit, or other "red flag".
Regardless, the general points are spot on; it's a mess, for both sides. And even if the game weren't improved, I wish we all gave and got more honest feedback (however illegal that would be).
Wishing you luck in this numbers game!
But not at this kind of frequency it doesn't. If I got my quick back of the envelope statistics right (exactly the kind of skill that occasionally crops up in these jobs and on this interviews!), this would mean at 95% confidence the employers were incorrectly rejecting 88% of qualified candidates!
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
I got this exact question on a phone screen with "Giant Search and Advertising Company." I got stuck on a stupid detail and botched the implementation. Once I hung up the phone I took a deep breath and fixed the algorithm in about 15 minutes. That still isn't very good since I was only given 15 minutes total at the end of the interview to implement it in the first place so I assume that is the time-span they expect to get an answer from a senior engineer.
Fair enough, I didn't study for the interview, I don't have a lot of binary tree experience. I realized that if I couldn't get through that phone screen cleanly/easily then I probably wouldn't make it passed 4 or 5 whiteboard problems either (which are likely to be significantly more difficult). Fair play to any company that wants to screen candidates using that approach because I am not the kind of guy they are looking for and that is just fine. Everyone I spoke to was polite, professional and sounded competent. I do wish they would stop calling me and letting me know that I did well enough to be eligible to retry.
I have no doubt that I would contribute at an above-average level within any of those FAANG orgs but I appreciate their process and the reasons behind it. I have had no problem finding high-paying employment and distinguishing myself within any team I have worked on for my entire career. I generally get promoted quickly and asked to lead teams. As far as I can tell there is no dystopia, just people looking for different things.
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.
My background: I've never taken any kind of CS or programming class in my life. Mediocre grades in college. My first exposure to programming was at age 24, as I fell into it with an IT tech position. Went from there to a series of jobs at several startups. Before applying to a FAANG, I went through Elements of Programming Interviews and solved all the problems in it, which at around 10 hours/week took maybe 6 months of prep. I then sent in two applications, one to FB and one to GOOG, immediately got phone screens, passed, and then two weeks later went through the on-sites. Every one of the questions was either lifted from the coding prep book or trivial.
End result? Offers from both, joined as an L4, at a total comp higher than I had ever dreamed of, and significantly higher than friends in medicine who have easily spent over a hundred times as much time preparing and studying as I have.
So I'm kind of left flummoxed. Am I just incredibly lucky? There are huge issues in the hiring process, but if you want a job at FAANG, as far as I can tell it's incredibly easy to game the system. Set aside some time each week (easy, if you don't have kids), study for a couple months, and then apply. There's literally no other field than ours that is so open to motivated people without paper qualifications and that simultaneously offers so much in terms of lifestyle and compensation. Whether it hires the best candidates is another question entirely, but that's an issue for the company, not for the applicant.
But, when I give an interview to an applicant and use my go-to question, which I initially feared would provide no useful hiring signal for being too easy (and which, yes, I've tested on all my coworkers, who solve without any difficulty), I find that only maybe a third of applicants complete it at LH or higher.
To be clear, I'm calling this out as a blind spot I have--there's clearly a massive gap in perspective here--but hopefully it'll provide a useful data point for why tech screens aren't universally hated and why they manage to persist.
- I used to have a massive impostor syndrome due to not having a CS degree. Joining FAANG alleviated perhaps 80% of it. (Just to be clear, that's not the reason why I joined FAANG; I just wanted to try a large corp after years in tiny startups.) It feels good, but I'm mourning it a little, because I believe it was a driving factor to how intensely I was trying to better myself.
- I enjoyed solving all these problems. There's beauty in finding the most optimal solution to each of them. Binary heaps are plain beautiful, and suffix trees and arrays still blow my mind years later. I wonder if people here dislike this stuff because they were forced to learn it in college for a piece of paper, while we learned it on our own volition for a big jump in compensation. Maybe I'm just projecting because I hated school and college; many HNers seem to have enjoyed their studies, which is awesome.
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.
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...
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.
In both cases this seems to be the market solution to the problem of having limited capacity, high demand, necessarily short interviewing/screening processes, high cost for admitting sub-par candidates but low reward for admitting good candidates. And in both cases it seems most dislike the process for being ripe for arbitrariness and routinely turning away good candidates and "there ought to be a better way" but the process seems to have evolved naturally and doesn't seem to go away despite there apparently being no major barrier for using a better process should it exist.
Just a random though.
When I went back years later and just went as myself, my wife and I were immediately welcomed in without much questioning. For those wondering, this is not a club where being with a woman is necessarily advantageous, but I will certainly admit that it likely had an impact.
The biggest things I saw them looking to screen out, beyond drunk - high - obnoxious, were youth and naïveté. They seem to largely be aiming at people who know exactly what they’re getting into, and are relaxed about it + not overly attached to the outcome.
Just so you know exactly what I had on, and how much it flies in the face of some of the advice... on Friday: White t-shirt, jeans, baseball cap. Saturday: Grey Everlane pocket t-shirt, backwards baseball cap, Patagonia 5” running shorts, Off-white Adidas Marathon sneakers. I did learn to dress like you’re going to dance for hours in Friday night, and jeans got hot and shirt came off real quick, so I adjusted on Saturday.
Wife went more classic and wore black jean shorts, black tee with a ripped collar, black baseball cap, black adidas.
1. show help text (type/doc string) for a word
2. go to definition
3. find all references
My first thought was "this is an absurd request for a two hour coding challenge". My second thought was "boy I hit the jackpot, a few years ago on a whim I built my own language server for Go in sublime text and could probably crank out a new one pretty quick"
Sadly despite my best attempt they rejected me. They never did give me an explanation. (fwiw: https://github.com/calebdoxsey/languageserver-challenge)
I wish I could say it was a fluke, but I've been rejected by lots of companies due to the coding challenge. One day I'd really love to see what the passing code for these challenges looked like. Maybe I could learn where I dropped the ball.
p(job_capable | not_interview_capable)
However, I wonder if oftentimes companies are aiming for..
p(job_capable | interview_capable)
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.
And the worst part of this is, from the inside, it really looks like the process is working. After all, there are some really smart people who get hired, and saying the hiring process is bad feels like you're saying your coworkers aren't smart. But the truth is, these companies are hitting smart people. They're just hitting a non-uniform dust of all three smart people out there.
I think this is an opportunity for smaller companies to hire people who wouldn't make it into the big companies, and innovate in a way the big companies can't!
[0] https://hiringfor.tech/2020/02/10/false-positives-and-false-...
Does it work? Maybe, maybe not. Perhaps you get some fantastic candidates (true positives), and perhaps you get people that are very god at gaming the system (false positives).
The process, as it is, is kinda like trying to select potential mathematicians on the basis of how well they solve HS AP Math problems. It is fully possible to rote learn every kind of integral and derivative under the sun, if you just solve enough - without actually understanding the underlying principles. It becomes a pattern recognition problem.
There are tons of anecdotes from seemingly false positives, when it comes to tech hiring. The web is filled with "I was very lucky, because they re-used problems I had just solved".
BTW, when I say false positives, I don't mean incompetent programmers / engineers - I just refer to those that do not master the subjects they're being tested on, but average candidates (on the subject) that luck out on getting asked the right question.
I still think Goodhart's law stands true for this trend.
People game the system, because they want to earn more money. Companies make the system more rigorous and robust against gaming. People still find ways to game the system, and it essentially becomes a race to the bottom. Along the way you start losing out on terrific candidates, because they refuse to partake in the increasing demands. So you end up with a mixture of very talented engineers, and very able test-takers.
I am really shocked with people's understanding of situations. Like one great example of a different interview process which totally seems like working for the interviewer and his/her interviewees is bashed for not being good for their tastes without even getting the rationale. Or expecting people to spend 6 months on preparation for interviews considered normal or totally acceptable.
Either HN crowd are totally out of loop of life, or their self importance is out of bounds that they can't see anything else which is deemed below.
Is life something that you could spend so easily? What kind of affirmation people get from jumping hoops that would never even matter in the big picture?
The newer interview procedures that are described here really made my jaw drop. I am not the most down to earth guy without the last bit ego, but I believe I improved over the years. Still if I would encounter any of these , I would go jerkiest of egocentrics ever and tell them go do themselves.
You're expected to be able to solve a certain set of problems. Whether you don't prepare at all, spend 6 months, or spend 6 years is up to you. Oh, and everything you need to prep is available in cheap books and websites.
That's immensely superior to being required to spend 5 years and thousands of dollars in college to get the degree that nobody will hire you without, like some industries do.
It used to be people took care in small gestures like wearing a pressed shirt but now all the auspices have gone awry in favour of this laughable meritocracy
No wonder tests of this nature have been devised by people who haven't ever buttoned a collar and it's everyone's fault for not taking the moral high ground
When's the last time you walked into a formal interview that actually was formal?
Casual guys in a jizzing contest over O(logn) implementations of tree traversal is the reason every start-up fails after 18 months
Coding interviews aside, no dress requirement is one of the biggest plus and allow people to focus on the thing that matters. I have no idea where you come from that software engineering is helped by dressing up pressed shirts.
But.
Usually interviewers are asking these questions to see how you think, not because they expect you to get it exactly right. And so verbalizing your thought process is how you prove yourself. And if you have trouble verbalizing your thought process, I sympathize, but being able to explain to others what you're trying to do and why you want to do it that way is a really big part of the job. And there are going to be a lot of times on the job where you DO need to tackle something wildly outside your skill set, and people need to see that you can at least start iterating towards the right thing. You don't have to be right, you just have to convince them you'd get there in a reasonable amount of time.
Also, if a small amount of pressure causes you to forget your entire CS education, that's kind of relevant to being able to do your job? I'm not trying to pile on to people that have anxiety issues, but being able to do things under pressure is a skill. If we're up against a deadline and you entirely freeze up and can't do anything, that would be a bit of a problem wouldn't it?
My deadlines are measured in months, weeks and in the minimum, days. There is practically no cases where it is in hours, and absolutely no case where it would be 30 minutes. I (We?) have trained myself to work and deal with deadlines/pressures of those standard time frame, which means that if I have only a day to deadline left, my technical mind shut down and it is now thinking about the business to see what should be best done next.
I believe people would feel more pressure at the risk of failing an interview than the risk of their company's product having a downtime
Big Tech has been captured by finance and professional management. In other words those companies are now political bureaucracies where workers, as opposed to connected operators, are exploited.
Workers now need to go elsewhere, save up some cheddar, and start their own companies. Same as it ever was.
There's nothing special about Silicon Valley. It preys on idealism and naivety just as much as Hollywood.
What did Netflix do? And don't we like Apple now? They ship crypto to billions that annoys the government's spyware programs.
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.
Am I really missing an army of engineers who can write an involved image filter in 45 minutes without that actually being their specialization?
import math from "some huge math lib that does everything you can think of"
print math(image)Let's not lose that perspective in discussions like these.
People have come right out and said they’d rather miss out on a good hire than get a bad one. There’s no “sounds”. It is.
Rather than more and more convoluted interview processes maybe we should work on better weed out techniques? I mean, what’s the overall cost really of picking the best person you saw in two weeks, getting back to the process of building new functionality (and your new hire training materials) and just kicking the dense ones with a little reflection on what we’re the objective warning signs this was going to happen?
I really think the thing is that people want to believe that training for their team is arduous, and so the cost of every person is huge. I’ve known more than a few people who philosophized about how much they learn about their craft by teaching. And it always seems like the people who create the biggest messes are the ones who can’t explain themselves.
Which we have known forever. In fact during the dot com era it was quite common to hire the most articulate people you interviewed. At least of they were wrong about something you’d know it right away, instead of them obfuscating their bad ideas.
What a nightmare process this whole thing is.
I end up with a slammed inbox, constant cold-calls from head hunters that are all dead ends, and in between all of the noise are some real opportunities where I get moved from the tech screen to the final round quickly due to my seniority.
It's like most jobs except there is a strange dichotomy between the technical screens, and the on-prem final rounds, which become more of a culture-fit type interview.
I feel like I am up against the Bob's from Office Space a lot of the time.
If anyone needs a 30+ year software engineer currently working with .Net Core 3.1 on Azure Linux and Angular 9, please hit me up.
Why did he interrupt the interviewer? And why interject that he had no experience in microservices? So what? You can still tackle a question that mentions microservices...
It's not like one's programming skills are useless for questions that merely mention an architecture you haven't officially worked with before. It's very strange to me that he interrupted that way, for that reason, and it makes me wonder if he acted similarly in other interviews. If his attitude is that he shouldn't have to answer questions about architectures and technologies not specified in his resume, that wouldn't go well.
Also, there's a lot of hype and looseness around the term "microservices" these days. You might have worked with what some people call microservices without knowing it. All the more reason not to cut off the question.
"At one particular ‘top’ tech company the process is that when a candidate goes through an interview he or she has a packet compiled about their interview performance. The packet then goes to a committee whose job it is to impartially review the packet to make a hiring decision. At one point a particular committee got so critical that they rejected every packet for several months. When HR caught wind of this they decided to set up a test. They sent the committee a new round of packets and once again the committee rejected them all. HR then called them all into a meeting and explained that they packets they had just reviewed were in fact the hiring committee member’s own packets from when they interviewed for that company. They had unknowingly rejected themselves! How could anyone pass that bar?"
If I was ever an interviewer, I would not ask candidates to implement algorithms, but rather to explain why you would use a certain one. Or give them a situation and some choices and ask them to choose one and justify their choice. (e.g. For this task, would you do it in python or C? Would you use a linked list or an array to solve this problem?)
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.
Here're my points:
1. Supply candidate with a challenge that I built myself, tested with a co worker
2. Test should have many small goals and bugs: Get more data points on what they achieved, don't make it binary!
3. Challenge should include real bugs from when you built it. e.g. typos, wrong attribute names like 'innerHtml' instead of 'innerHTML', forgetting an import, etc.
4. Make results runnable / viewable (for front end work)
5. Explicitly tell candidate that Google is not just allowed, but expected
6. Allow candidate to ask questions so you're not dehumanizing them (but don't always give a straight answer)
7. Follow up with questions like "what do you think could be improved?"
8. If candidate spends more than 10 minutes on any of the challenges, allow them to skip it
Get as many data points as possible from an interview. Make it as close to real life as possible.
And guess what?! Your diploma is actually such a certificate, at least something that's close enough. Still our industry largely ignores that for some reason.
To get to the point I wouldn't mind to renew my credentials with supplemental diplomas every X years on standardized tests facilitated by educational institutions to avoid the stupidity of the industry's current trends.
I recently interviewed with a hot VC funded start-up, the interviewer was the most dry and passive aggressive person I have ever met, I decided about 5 minutes into the 'get to know you, tell me about your work history' section of the conversation that I would not like working for this person. I had never wanted to end an interview early before this experience. When they sent me a leetcode link (to a problem I had solved in preparation for a series of interviews I was doing) and asked me to solve the problem I just sat there wondering how long before they would ask me to leave if I typed nothing. About 5 minutes later they asked me to leave, and that was the first time during the entire interview that the interviewer cracked a smile. I think that company will fail.
Am I the a-hole for playing that sort of game?
Edit: I also interviewed with a medical startup during which the interviewer, while telling me it took me a while to get to the solution and critiquing my implementation, admitted (I think by mistake) that they had spent some time researching the solution prior to the interview. I asked them how long it took them to solve, he did not answer that question.
I was talking with a recruiter many years back about when Yahoo had a massive layoff. The following year, he was suddenly awash with jobs to fill with new startups that were created by these Yahoo employees that were in comfy jobs for life.
If one of the FAANG companies laid off their workers, we would have a huge tech boom as these brilliant people suddenly would be forced to either get another job, or create something new, and that percentage of people that would create something new would rock the world. We would have new innovations across the board in IT and other fields that they would apply their talents to.
Instead, they are building plumbing in a system that really is just in maintenance mode. Remember, 99% of the functionality of these systems that exist today was already in existence 5 years go for them. This swarm of high priced talent is basically just moving the needle about 1-2% per year to just stay ahead of any other potential competitor.
The trouble is that these companies are so successful, that they can burn the cash trapping talent, and still pull in billions per year. This grind for small returns is just a small line item compared to the flood of cash they all rake in.
We spent a good lot of the night interviewing eachother in our own respective questions and judging eachother.
I'm a bit more senior that I like to admit, and I loved his questions. His approach was more simple questions, then go and follow up on them. This was evident when he mentioned 1 hour was not enough time for him.
I have quick fire nonsense questions that are just an entrance fee, What is SOLID, how can you prepare a unit test. Then important things (IMO) Patterns, identifying refactoring needs.
As for the questions themeself they're actually not that important and both of us tonight realised..
The questions you ask should reflect the work you EXPECT(if a senior/mid) the person to be able to do.
If you're hiring a JUNIOR I will say... The most important thing is to make sure they actually have an interest. I have been burnt hard on this.
Forget about language specifics also.. They can be learned, and as for Patterns, I am taking a step back on them because a lot of people use them without knowing it.
Our world comes from experience.. If you're willing and able to teach, hire like that, if you need some core team member quickly, hire for that.
It was easily the best chat I had with him in a long time and I hate interviewing!
This is absolutely hilarious, and has happened to me a bunch of times interviewing at large corps. Although I wish I had the balls to do what Jared does here, which is ask the interviewer if they ever even _used_ dynamic programming on the job.
Like, I get that some jobs are algorithms intensive. I've worked in such jobs myself. On the job, I had a lot of resources to help me - access to textbooks like CLRS and Wikipedia, so that building an algorithm and coming up with it's big O was mostly straightforward. But we've never had the CEO come and say "I need a O(n) algorithm stat for this problem _text dump of hard DP problem_".
Gaming the system is easy. You just have to put in the work. Do every question in EPI and then do a few hundred leetcode questions until you're ready. It will take between 100-500 hours depending on where you're at when you start. Good luck!
The ideal scenario would be - give a problem, leave the room, and come back after 15 minutes - give the candidate some breathing room.. to make mistakes, to try out few methods, to collect their thoughts.
This concept of 'We want you to think aloud, We want to see your approach', doesn't match reality.
In reality, the only time that happens is when both parties are trying to figure out a solution collaboratively. Not when one party already knows the answer and is 'testing' the other party.
An author's first draft, or a speaker's demo, has a million corrections before it gets to print/stage. Can RR Martin write freely if the NYTimes reviewed his every draft version ? Can Steve Jobs go on stage and give a demo if he has not already rehearsed the entire saga ?
It's like judging a person at their vulnerable stage. Unless they are a saint who can completely block out the existence of another human being sitting a few feet away, it's hard to concentrate.
You're more worried about how your thought process looks than you are about solving the problem at hand.
Talking to friends who now work for the FAANGs, I've heard stories of having to spend 40+ hours (re-reading Sedgewick and practicing programming questions etc) to just prepare for the first round.
Fuck that...
FAANG interviews might be dystopian, but if you look outside the Silicon Valley bubble, you can find interviews that are far more enjoyable than spending days in front of whiteboards just to move onto the next round. The most common pattern of past interviews for me has been beer/coffee/coke and a 30 minute chat about the company's future goals and see if I fit might in. That should be how it's done.
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.
So here is my advice. For your first job, and as a newbie, be accommodating. When I was out-of-college, I thought Java is no fun and is only for old people, I am functional and cool. And the job scene is just a hammer right on my head. So brush up my Java knowledge like in 2 weeks, and putting Java everywhere on my resume. Get a job pretty quickly.
Now I have experience, and don't have to bundle myself as Java programmer anymore. But that is only after I have grown from that early experience.
So again, be accommodating, get a job first and everything else can be figured out more easily.
Then, we talk and I look for all the qualities they /do/ have.
Sadly, lots of interviewers get a kick out of finding out what the interviewee does not know, so they can feel superior.
Coding challenges should be: -1. take-home -2. concise -3. relevant to the job -4. take no more than 4 hours
One example of such a decent test that I came across involved having to read a file, parsing it and turning its contents into some basic HTML. During the interview we talked about things like "what if the file were really big", e.g. let the candidate reflect on the limitations of their implementation. This was enough to suss out where somebody is, professionally. And nobody had to have a bad day.
We recently did a bunch of hiring. Our coding excersize was practical and involved working through some existing code that had a bug and extending it. They had to be able to state the problem back to us clearly. It was take home solutions submitted to git. It was simple to weed through candidates looking at the code for 30 secs. We looked for things like clean code and well thought out solutions. We didn't do the silly BigO optimization stuff that every company is obsessed with. We've been very happy with our hires.
Pretty much - they're willing to reject 100 good candidates in order to avoid hiring one bad one by mistake.
It's also a feedback system/arms race (like college admissions, conference paper submissions, etc..) The lower the acceptance rate, the more places you have to apply. This raises the number of applicants for each position, which in turn lowers the acceptance rate even further. This continues until you reach the maximum number of applications that each candidate can produce. Needless to say, the quality of evaluation is inversely proportional to the number of candidates, so acceptance becomes arbitrary and random.
BUT...
Having recently been through an interview with a well-known open source software company where the third interview ended with a "No" based on what seemed like purely subjective factors with no skill-based or evidence based reasoning at all... I do now have a lot more sympathy for our process @ Google which at least requires a panel of people with calibrated scores, multiple interviews with copious note taking and documentation, etc.
It really is hard to find a middle ground, though.
Some companies are hiring a pie in a sky while other have real problems and want to hire people that can solve real problems. Hence 2 type of questions:
1) Write me working Lisp code of some exotic sort algorithm, oh and btw what that Hermite–Minkowski theorem is about.
2) They ask what you've done, how you did it, some references and how you can help them to solve their problem.
When I smell #1 I just apologize and leave. #2 can go either way but at least you're talking to a reasonable people with real needs.
The fact that you'll barely be using the algorithms if at all doesn't matter. They use that for interviewing specifically because it's hard, and it screens for intelligence, problem solving speed, knowledge, and even how fast you learn (since everyone's got to learn the same algorithm question prep).
The end goal for them is that all their workers are at a minimum screened for the ability to grind at and break through difficult and esoteric problems, which are the biggest time sinks and therefore biggest limiters on the progress of the business.
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?
Within a week of setting the "would hear from recruiters" flag on my admittedly-thin LinkedIn profile, I had 3 solid leads from 3 companies.
I had 3 in-person interviews, and even feeling like I flailed a bit on a couple of the coding exercises (I had the exact panic about writing The Game of Life in 60 minutes), I had two offers and one almost-offer. (The almost was more due to they wanted a principal engineer vs. senior engineer).
Maybe around where I am companies are learning their lesson.
You’re selecting for employees who are able to get distracted for a few hours when they’re in the middle of something else. That’s not who you want.
This one greatly differs between large and small companies, but I think for small companies there are only two positions they can interview for, junior and senior. Anything beyond that, be it Director, VP or SVP, the company is no more interviewing a candidate but rather is doing everything in their power to convince them to join.
I’m not saying this is a good thing, but to me it does explain why interviews are so hard and why they are so disconnected from actual jobs that applicants will actually perform.
It could be worse. In the medical industry you have to work for free (or low pay) for 1-2 years to even be considered for a "real job". Law firms are highly competitive, and have very rigorous interviews . And yet software engineers are payed better on average then both.
For example, you don't ask a carpenter if they know what a dovetail joint is. You don't ask a bricklayer on which brand of bricks he prefers, or how tall his last wall was. You certainly don't ask a mechanic how an internal combustion engine works!
Sure throw a few algorithms at entry level employees, with no experience, to make sure they understand the basics. But not experienced developers!
https://en.wikipedia.org/wiki/Competitive_programming
The world's top companies receive a flood of applicants and use this format to filter them.
If you work in simple web applications with mild traffic volume, filtering candidates in this way is unnecessary.
At my last job, I was trying to hire a frontend engineer. More programmery than designery, so I would kind of expect the ideal candidate to have heard of Typescript, and to have maybe written a unit test before. Our recruiter put a job listing on the usual places with those exact criteria, and ... we got hundreds of resumes by the time I took a look at the queue a few days later. I reviewed them all! 90% of the applicants had gone to a bootcamp and had nearly identical resumes. They wrote down their camp projects as though they were work experience. They linked to their Github that had line-for-line identical code between applicants that went to the same boot camp. Some were just directly the output of create-react-app with no additional code added. The common theme was, "I hear you get paid a lot to be a programmer. Count me in!" The other 10% of applicants didn't really have anything negative going on. They have some claimed programming experience, and they want to get paid to write computer programs. Why not call them up and ask them to find the k-th element of a binary tree? It's not a super-obscure area of study.
When I was at... erm... "Giant Search and Advertising Company"..., I did in-person interviews. I went through a lot of the shared interview questions to use, but ultimately came up with my own: given a stream of events from a variety of event sources, count how many unique event sources emitted an event in the last 5 minutes and last 30 minutes. I chose this because I literally wrote this exact program, and it took me a few iterations to get it to be optimal. (Or what I think is optimal!) For that reason, I found it to be a pretty fair question. The answer is just a few lines of code. The problem is a real-world problem. It's not a puzzle, but it does involve some thinking and maybe asking some questions.
The last thing I'll say, which I know is kind of snarky... As a Senior Software Engineer at Google, your total compensation is going to be north of $300,000 a year. You should be able to find the k-th element of a binary tree. Teach yourself how; it's kind of fun, and might someday be useful.
I agree with the HN consensus that hard CS comes up somewhat rarely in the day-to-day life of a programmer. But when it does come up, you really do need to know it. You will never be finding the k-th element of a binary tree. But there will be tree structures, and you will come up with some brute-force algorithm because you haven't seen that class of problems before, and you will push your "uses too much memory and time on production-sized datasets" hack to production, and production will crash, and then you find yourself with a production outage you don't have the tools to fix. You aren't getting paid $300,000 a year for that. So that's probably why they ask you CS-y questions.
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.
I've had a successful and well paid career as a contractor in London and highly advise others to check the scene out.
Some of the best contracts I worked on were just casual interviews, I didn't even write any code.
1. Open source your entire codebase
2. Each user story, commit for feature, etc is tagged
3. Pending features are correlated to (2).
Finally, no interview or references. Simply hire people who can complete high level implementations for the features to extent one can given an arbitrary time frame.
Small companies aren’t that great either, when their main business isn’t tech
In some countries I see job postings with a third experience level: "Medior". Is there an equivalent in English?
Well, there's your problem right there.
"The pay's respectible when the company's not."
If you want to be part of something special join a startup or at least a small or mid size company made up of people that actually values your whole skillset and creativity instead of only one aspect.
* Predictability - I know what it's going to be like clearly from the beginning
* Trainability - I can become better at it
* Memoryless - They don't care that I did terribly a year ago
Of course, in the end, I didn't actually interview even once with them so maybe I'm lying about what I like. I guess I'm one of those guys who goes from job to job not having a whiteboard interview. Lucky me.
And so many people have rehashed over and over their positions. I did, and I will do it again today.
Tech booming just happened pretty recently. People are going from law and finance and medicine to software in droves. Though it is arguably that those people better stick with law, finance or medicine than software, the fact is that software field has lower barrier of entry, from socio-economic/financial point of view and artificial gatekeeping point of view. Majority of people just don't have the resources to study law, finance or medicine.
We have a gold rush, and majority of people want to improve their life, with the least amount of effort/barrier possible.
This result in new supplies of software engineers, whether from graduating bootcamp or graduating CS degree. All of these engineers are of varying quality. Let's not talk about the older experienced software engineers, because I think it is safe to point out the fact that older more experienced software engineers are of better quality in general.
So now, we have massive influx of newbie/junior software engineering candidates. How do companies realistically interview all of them? Knowing that these people graduated with varying degree of skills/quality.
If the majority of the workforce are older experienced software engineers of good quality, then companies won't have this filtering problem. They can just give interviews by talking from previous projects/referral and call it a day.
But now we have this DS&A and take home test as well, because interviewing is hard, and the more candidates out there the harder it becomes.
I am about 5 years into my career in this, and did interviews at a few companies and also FAANG. I experienced take home tests, work for a day, and DS&A. And I choose DS&A every single time because the other two sucks.
I don't have that many projects, or even side projects that I can be proud of. I love doing hard tutorial such as learning how to do compilers rather than doing some projects. All my github is filled with trash/throwaway code. And for some reason I always got involved with projects that ended up being throwaways in my previous companies, because those projects were generally hard problems.
Work for a day, take home tests, those two are a waste of time in my opinion. I can't do multiple of them and get competing offers. But with DS&A I can just learn once and do it multiple times and get multiple competing offers. Not to mention that I won't have to compete with more senior engineers that are obviously more capable than me. By doing this DS&A game I already filtered myself up for better.
Besides, I hate learning about framework this, framework that, technology this, technology that, multiple times. It gets old quick. Don't get me wrong, I love learning new stuffs, but too many of those and I just spin around in circles learning the next Javascript framework flavor of the month. I'd rather be interviewed about how to do recursion than being interviewed about the nitty gritty of React vs Angular, Express vs Koa, etc etc etc.
In general I favor DS&A interviews. For those of you who are more senior than me. Please don't do DS&A. Please stick with what works for you. If competent people like you start doing DS&A and be good at it, then what are the chances of people like me, or other non senior engineers for getting a job. If you think I'm being sarcastic, believe me, I am not. I truly believe there are people out there that can code in circles around me despite me knowing how to recursively generate a permutation.
In general I have success in interviewing at non FAANG/Unicorn companies. I usually finished those coding challenges in 10-15 mins, and the rest 30 mins I just talk to them about random stuff and they ask me about previous project, culture, etc.
However, I still haven't found success in FAANG companies. I still got rejected, despite having solved 300+ Leetcode questions. And yes I know people who solved 500+ and still got rejected.
Now that brings me to the things that bother me the most. I've seen, as many of the commenters here, that there are people who got in despite not doing any preparation at all. I thought at first those were lies, until I saw it myself, and not just once, but twice, three, and now four times. Everytime I heard these stories it demoralized me.
I've seen people who got into L3, L4, E4, without knowing how to reverse a binary tree or do a simple BFS/DFS.
Why? What am I doing wrong? What are they doing right?
p.s. Don't ask me why I want to work for FAANG. I need (not just want) the money. I have people that I support.
It is necessary to do well on coding interviews, but not sufficient. optimizing for coding interviews is the wrong approach.
data Tree a = Tree a (Maybe (Tree a)) (Maybe (Tree a)) deriving Show
-- Assuming k=1 Means the highest node, k=2 means second, etc...
-- Note this solution successfully puns non-positive k's
-- to return Nothing
kHighest :: Int -> Tree a -> Maybe a
kHighest 1 (Tree a _ _) = Just a
kHighest k (Tree _ (Just l) (Just r)) =
case (lRes, rRes) of
(Just x, _) -> Just x
(_, Just x) -> Just x
(_, _) -> Nothing
where
lRes = kHighest (k - 1) l
rRes = kHighest (k - 1) r
kHighest k (Tree _ (Just l) _) = kHighest (k - 1) l
kHighest k (Tree _ _ (Just r)) = kHighest (k - 1) r
kHighest _ (Tree _ _ _) = Nothing
In my opinion, the common criticism that interview questions hold no similarity to day-to-day software engineering problems, holds no water. Yes, you will not directly re-write the tree data type every day in your job. However, you deal with recursive data definitions that require solution by decomposition _multiple_ times a day. If you are not dealing with problems that fall under that category, then you should think hard about which problems you see that could be framed as such because I guarantee you're missing a few.
The beauty of the tree as a data structure is that it captures a common set of algebraic properties. Even when other data structures don't exactly fall under said algebra, the concepts to reason about them are reused (note the early language that specifically said "tree-like").
The point of drawing interview questions from your data structures and algorithms course is not to test you on remembering arcane minutia from 5+ years ago but to see your fundamental reasoning skills within the domain of computer science.
I've worked at my current job for a long, long time now. Every year or so I decide to peak my head out from it and test the job waters. I get nearly the same set of 4 outcomes each time. I have over 7 years of experience with everything from front-end development to sysops, devops, and management. I've built entire companies by myself in months. Albeit buggy ones.
I bloody hate interviewing.
Outcomes:
1. I get rejected for messing up a programming fundamentals question. Which, honestly stings because, yeah, I should probably be more informed. But, currently, I ain't got no time fo dat. I'm too busy solving a bombardment of problems like: "Hey, programmer X quit, I know you don't work with X language at all but we need this fixed, yesterday".
2. I spend a bunch of my precious time writing a fully functional code test, to be inexplicably rejected. Maybe because I didn't write unit tests? Maybe because I didn't use doc blocks. Maybe I didn't make the code reusable enough given their imaginary scope. Who knows.
3. They're super excited to hire me for a position I am not at all qualified for. Usually for a ridiculously minuscule salary. I had a company ask me, after spending 2 hours on a phone interview, to build and run their development shop. They wanted to on board 50 employees by my 6 month mark, and completely dismantle their overseas workforce.
4. I'm just plain ghosted.
I'm absolutely sick of potential employers asking me why I am excited to work with them. Well sir, to be honest, appearances and mission statements are superficial. I am excited to experience something new. I really hope that your shop lives up to the hype. I am excited to learn.
Take note employers. Saying pretty much anything else is either ignorance or a lie carefully concocted over the countless hours you require of potential employees, just to get in the door. Your interview question responses are almost never genuine talent. They are hours of memorization. I know, because I've asked, and answered them.
Why even require a resume? I've spent hours cultivating a bomb resume and 19 out of 20 employers, have literally no idea what it says.
Employer: "So what languages are you familiar with?" They're literally listed on the resume that you required I send you, with demonstrations. The one I customized to your company and needs.
A different employer: "So, you don't actively work on any opensource projects, we can review"? No, I try to have a life when I am not working, and go outside. I know, hiss...
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Right now 7:23 PM on Valentines day, I am trying to speed up a program, an MVP, that I rebuilt in a week. One that I acquired after the prior developer got fired. One of my many, many projects. This one is particularly pesky as I am also trying to build out another app that is due, about 23 days from now.
Send help.
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.
There are multiple kinds of dysfunction at work here:
- When I was looking for purely technical gigs I breezed through phone screens and automated testing only to go up against the ageism wall on the first Skype call. Period.
- Recruiters reproducibly drop out of the blue without a clue as to what you actually do or your experience level. Adding “Senior” to my LinkedIn profile measurably decreased the amount of randos that reach out on a weekly basis.
- Puzzle-based screenings are a complete waste of time. It’s not about the prep, it’s about the likelihood you’ll ever encounter those problems. People are much more likely to have to address system design problems, but those cannot be tested for by the online questionnaire cottage industry, so you get mediocre engineers who know how to write fizzbuzz but have zero clue of how to design an order management system from scratch or where to look for issues in an old one.
- Companies often don’t understand what is involved in the roles they hire for--even if you’re a perfect match for the job description (if there is one), the hiring team has an agenda that seldom matches it.
- Engineering is not just about writing code. The second you start asking questions about how teams interact or if they have a strategy for X, the people in the room (or call) are seldom the ones that can get past canned replies.
- Startups tend to be extremely picky and hype-driven. The language _du jour_, their “triple mocha with a squeeze of raspberry” Agile flavor or someone’s pet organizational methodology (teams/tribes/packs/etc.) usually feature prominently in senior interviews, but even VPs _very seldom_ talk about how they manage people--just product and investors.
As a result, I’ve long stopped applying to “normal” engineering positions (and even senior management ones at startups). I drop out of the process (politely) as soon as I get the first hint of automated tests, ageism or VC hype, and prefer networking and getting to know the culture first.
Even so, I’ve had a few notorious duds--I would talk to a VP, have a great conversation, and then have “peer” discussions with people half my age that might as well have lived inside a bubble (and had obvious gaps in empathy and emotional intelligence), or simply have an “OK, boomer” moment whenever the conversation steered into how they managed people growth or I commented on their org structure.
Or I would go through the _whole_ thing and then be told that they wanted someone at “a different career stage”, even though you ticked all the boxes, talked to around a dozen people, and gotten consistently excellent feedback (that one smarted a bit, because it was in a very niche field I was particularly good at).
My key takeaway is that “vanilla” engineering jobs are most often not seen as being long-term hires that bring in outside experience: they are fresh cogs for an internal hype-driven, Rube Goldberg-like contraption that many tech companies cling to and want to preserve at any cost, and the hiring process (and lack of care in it) mirrors that.
To be honest, this is really a super simple question and I would be stunned if this was anything but a warmup for you, like the interviewer giving you a simple question to get you into focus. I haven't done anything with BST in years but still I could easily do this with a piece of paper. Back in the days, Google was asking to insert an element in a Red-Black-Tree. Well, this is a clusterfuck and far too specialized. But questions like those were rightfully banned.
Yeah sure, it's not what you do all day, but not being able to answer these questions has implications. There are many code monkey mills where you just write some JS code to hack a webpage together and it would seriously bother me if they would ask you such questions.
Just rethink what you really want. FAANG is not for everyone.
If you actually read the linked article, there aren't really any interviews.
The OP is just getting let down by recruiters.