I haven't cleared a single technical interview after applying to FAANG companies in last 5 years. I'm currently employed and I have been working for than 8 years. I'm good at what I do. I might not the greatest programmer but I can come up with a approach to solve a problem.
My past experiences have been terrible, not a single person who interviewed me wanted to know what I worked on or what I have achieved or how I solved a given problem. Few introductory questions and jump into coding questions. Some of them are medium and few of them were hard. But at most I was able to find a way to solve(not completely code a solution).
It seems lot easier when you are in college and are surround by students who are practicing coding interviews. You can talk, discuss and gain more experience. I don't know how I can do that, when I'm busy maintaining and coding for my current job. Its just so demotivating.
This entire industry is just awful, and the antithesis of anything resembling the compassionate virtues they claim to espouse. I'm done with programming, and maybe that's what is supposed to happen, but it has left a very bitter taste in my mouth. If you have serious chops, go for it. Otherwise, give it a wide berth.
To continue the normal HackerNews go-around on this topic: there are plenty of companies that don't interview like this, at least outside of Silicon Valley.
It's like tech interviewing has become the modern equivalent of the old Chinese Imperial examination: keep your head down, don't rock the boat, study these arbitrary tests to rise in status. A far cry from the early days of HN when the culture was more "think different".
I would be wary of new teammates whose motto is "think different" when it comes to operating services at $B scale, because if they break something, someone else on the team will have to work all day and night to get things fixed and it won't be them.
That does probably depend on whether you're doing greenfield work or not, but even then these costs are there but just not immediately visible.
Which is understandable, if you have services at $B scale. It's a bit like teams that adopt microservices or Kubernetes for their three-person startup: just because Amazon or Facebook do it doesn't mean you should.
The usual HN sentiment seems to be that take-home assignments are degrading, whiteboarding interviews are broken, which can be summarized as "I take a lot of pride in my craft, how dare you ask me undergrad trivia"; whereas the Blind sentiment is that all you need to do to get a 300K+ salary is to grind Leetcode and system design prep, which can be summarized as "I'll do anything to get money and that's the only thing that matters". I guess there's also cscareerquestions, which is more "I've applied to 500 jobs and heard back from none, help!".
This is pretty explicit in interview training at least at Google. Nobody cares how you solved some problem because inside the Google none of your experience applies. What are needed are people who can read and write code, who know algorithms and can discuss the complexity of them.
There's a lot luck involved because there are so many candidates, most of whom cannot come up with an approach to solve a problem (let alone to solve it well enough to serve billions of users well). So even most candidates who are qualified can't convincingly demonstrate that given the time constraints and pressure etc.
It is hard to get into FANG for college new grads, it is even harder if you're trying to break into the tech industry from outside without the schedule flexibility and focused community support of a top tier university. It is possible but you need a combination of high ability, strong drive, and luck.
At my FANG, we've made some interviewing changes over the past 5 years such that these days you'd spend at least 20% of your day interviewing talking about what you worked on and achieved and how you solved problems, whereas in the past it would be entirely at your interviewer's discretion and typically only be a few minutes of unscored small talk.
FANG is an interesting life experience and it pays well, but plenty of people find it is not all it is cracked up to be. Just as in every job, a lot depends on the particular people you work with and whether you enjoy the particular problems you are solving. So maybe also consider whether you really need to go FANG (right now) or whether you could be just as happy at a place that's willing to take a more individual approach on hiring. That place could even be a stepping stone to reach FANG later on if that's what you want to do later.
An honest question; do you need to work for FAANGs if this is the case? I think it's fairly accepted that you need X amount of hours per week to designate only to studying for your FAANG interview if you want to pass. This might be 10h a week for the next 3-6 months, or 15 for the next 10 months (or any other number of hours a week for any other number of months/weeks), as it wholly depends on you.
You can either dedicate the time and practice, or decide you don't want to do it since your situation does not enable you to do so (e.g. due to kids, family, or simply lack of motivation).
Of course, there are people who do not have to study. It seems you are not one of them. (Neither am I to be honest, this is just an observation, not an offensive remark). What else is there to do other than studying or not passing the interview in such a case?
The interview process for FAANG companies is primarily focused on preventing false positives because of the damage that can be done by individuals when working at scale. Unless you have a really large sample size I wouldn't take any of that personally because for each interview, luck is involved.
Furthermore, the process is partly about how good you are at being able to learn, and partly about how well you are able to keep yourself motivated to grind something out, or a combination of the two. Given enough time, FAANG interviews are 100% something you can study for, and furthermore, it is expected that you spend the time to study for them as that is also a signal of something in itself.
On the job, you'll either have to be smart enough to pick stuff up quickly or spend the time to grind out the work (working overtime, etc). You also can't fuck things up too much because the fallout can be really expensive, so it helps to be able to do things right the first time. I think what is generally tested in the interview correlates with these requirements, and prevents false positives (and probably lots of false negatives too but you can just study more and try again at that point).
I would guess, with some evidence from experience, that all FAANG companies have sufficiently bureaucratic process, checks, and balances, to largely mitigate the risk of a disaster caused by a lone wolf screwing something up. Multiple cross-functional sign-offs whenever you deploy something to production, mandatory code reviews, gatekeeping access to push changes for junior folks, etc. This has got to be a mostly solved problem for companies of that size.
I'm not denying they are primarily focused on preventing false positives, but not for the reason you mentioned.
Yeah there are definitely other reasons but this is one of the biggest in my opinion.
There's always a tradeoff between security/bureaucracy and speed in delivery so as to remain competitive. This does matter even at large scale.
I would agree that if one were purposefully trying to cause as much damage as possible, that impact would be contained by these processes.
But one can still make mistakes or be a drain on the team's energy and focus which increases the chance of mistakes team-wide. At scale, even minor mistakes are costly, not just in terms of direct impact but in terms of the opportunity-cost of developer effort that could be better spent elsewhere.
Of course, my direct knowledge has sample size of n=1 here so it likely does not apply uniformly across all large companies.
I would love to hear contrasting opinions on this topic. I've spent a lot of time thinking about what would help developer teams increase their productivity w/ regards to adding value.
Start or find a company that takes a "value" approach to investing in humans. There are a lot of undervalued people out there, in North America many if not most people's potential is being wasted. SV / FAANG is a land of, in some ways, artificial scarcity. The reason jobs are hard to get is not just that the work is so demanding, it is not true. The rewards are high, and this is part of the reason that not everyone is allowed to partake.
I am oversimplifying it, but the same forces that created the FAANGs can allow you to avoid them and companies like them, avoid SV. The world has become more evenly distributed in some ways, but HN and channels like it can make you think you have to pass through these certain gates.
Yep. Quant finance has a very similar culture to FAANG companies when it comes to interviewing style. Yet practically every one in the field just realises that's how the game works, does some practice and gets on with it. No one likes going through this process, but once you realise that well-paying, prestigious jobs just require you to take a roughly standardised, undergrad-level test, it almost feels like cheating.
And in fairness to the FAANGs, it seems like we actually know the rules: review your fundamental CS algorithms and grind leetcode. Compare this to any other company who is looking for whatever the fuck culture fit means and how to get a job there is anybody's guess.
I have mixed feelings about this. I despise white board and leet code. I hate it when we (at a FAANG) cannot hire some otherwise excellent candidate.
One interesting thing though is that from a market perspective, it still ends up making sense for our org (ML research lab). There are simply so many applicants, that we can afford to pass on anyone. All the candidates hired tend to still be excellent on all other fronts AND they can do these quizzes. And it does result in some hires not being the most credentialed ones with the longest CVs but the ones who outperformed during the interview for whatever reasons.
So..I can see it makes sense for the most prestigious orgs, but I still hate it, and I especially do not see why startups who are struggling to hire feel the need to copy this when they clearly do not have the same options.
Another thing that really irritates me when people in hiring committees actually pretend passing them means something about candidates' innate skill. Like, I get it, these are the rules we made up, but do we have to pretend they are that meaningful?
I said this yesterday and will say it again. We discuss interviewing a lot here. Despite all the proposals things don't really change. FA(A)NG style interviews are just that - whiteboarding solutions to N algorithmic problems in M minutes (or minor variants of this). Either we accept this and move on with solid preparation or modify our priorities such that we're fine with not wanting the money and/or the quality of work (debatable) offered by these companies. At the end of the day, it's a choice and it's still in our hands.
I'm not entirely sure I'm getting what you're conveying here. Are you just reminding everyone that change is slow to come, and to be pragmatic about these applications? (I agree with that.) Are you also claiming it's futile to attempt to change or push back against this interviewing process, at least through discussion about it?
With enough push back, I do think it's possible that those in charge of hiring in the world might reconsider how valuable leetcode tests are to judging potential employees.
These kinds of discussions are futile yes. It's been well over 10 years and the only change in this discussion is the introduction of racial and gender discrimination, whereas 10 years ago the focus was on age discrimination.
I'd be happy to hear alternative approaches to conducting a technical interview, but no one presents any. There are 100 comments in this topic and hardly any discussion of what a good hiring process would look like.
Here's a serious question, does any job paying over 250k have an easier hiring process than FAANG? The thought of going through an investment banking, white-shoe law firm or medical residency pipeline seems utterly terrifying compared to 'show up in jeans and take this algorithms test which has near-infinite practice material available'.
Exactly. I don't like going through these interviews, nobody does, but there does seem a lack of perspective in how this issue gets discussed.
You can really leave a lot of money on the table with this attitude of "oh well, I dodged a bullet, if the interview was hard then the job is probably bad and the whole company too."
"I cannot afford to waste my time making money." - Louis Agassiz
I'm not quite there, but if I leave money on the table to avoid a place that treats people in an abusive way, I'm okay with that. I don't need the extra money that badly - it's too expensive.
"We expect you to study for months, on your own time, unpaid, so that our interviewing process can throw questions at you that are unrelated to the actual job we're hiring you for. Because we can, and because we do it that way, and because we don't care about how it comes down on you." Yes, I find that abusive.
Frankly, I'd rather everyone not study, and just hire the people who don't need months of refresher studying to do figure out some short coding problems...
I have a dangerous thought sometimes that universities, collages and bootcamps should have a much higher failure rate. Some people, despite working incredibly hard, find programming impossibly difficult to learn. I’ve had plenty of students like this - where no matter how much effort they put in to studying, programming just never seems to click.
It breaks my heart a little to say this but the earlier they pick a different career path, the better their lives will be.
Hard to gel that with the "learn to code" wave of the past decade. Software engineering is one of the few remaining middle class white collar professions with significant demand and growth, people are going to be drawn to it as wages collapse in many other industries.
Yes. And yet, everyone glosses over how difficult it is to learn to program. Its a different way of thinking. Learning to program is like learning to write good fiction. Or learning to make art. Lots of folks - for no fault of their own - will never achieve mastery. But by never telling those stories, people end up blaming themselves for not being good enough. The reality is you can't dump a 60yo ex-miner into a coding bootcamp for 3 months and expect him to be employable. And if you try, and he (predictably) fails, failure isn't his burden to carry.
I suspect a lot of people who complain about technical interviews do so as cover for struggling to be good enough at programming to be hireable. I think we need to take the stigma away from that - its ok to find programming hard. Honestly, that makes you a more normal person. It doesn't say anything about your work ethic or your value as a human. And its not a failure to choose another career.
There’s a trope in kids cartoons, where everyday objects becoming scary looming nightmare things at night time. We can play that game with anything! Cars: “a 2 ton metal box we hurl through space in a life ending daily slalom”. Careers: “underhanded slavery - don’t work and you don’t eat. We make you choose your poison so you’re complicit in crafting the chains around your ankles”. Children: “Biologically enforced obligations which destroy the best years of your life...”. The fact that we can tell scary stories doesn’t make the stories true.
With interviews - my claim is this: A well designed interview has a high statistical correlation between passing the interview and being useful on the job. Eg when I was interviewing we gave candidates some buggy code (with failing tests) and asked them to find and fix the problems. The ability to debug unfamiliar code in a job interview is correlated with the ability to do the same thing at work.
If you can’t read code, I don’t want to employ you. Please practice and reapply, or find work elsewhere. This is a reasonable position - and probably the only reasonable position for an employer to hold.
There’s lots of skills other than debugging: coding, profiling, algorithmic analysis, CS fundamentals, architecture, communicating with coworkers, etc. A mediocre interview assesses 1 of these skills. A good interview assesses 5+.
Are there bad interviews out there? Yes, lots. But interviews themselves - even badly designed ones - aren’t abusive. (Unless you think a rejection is abuse).
I get that some people put themselves through leetcode practice hell to get a job because they’re unemployable otherwise. I have sympathy for this but I don’t think this is the fault of the interview process. I suspect any decent assessment process would have the same result - where some people need to improve before they can get hired.
> With interviews - my claim is this: A well designed interview has a high statistical correlation between passing the interview and being useful on the job. Eg when I was interviewing we gave candidates some buggy code (with failing tests) and asked them to find and fix the problems. The ability to debug unfamiliar code in a job interview is correlated with the ability to do the same thing at work.
> If you can’t read code, I don’t want to employ you. Please practice and reapply, or find work elsewhere. This is a reasonable position - and probably the only reasonable position for an employer to hold.
> There’s lots of skills other than debugging: coding, profiling, algorithmic analysis, CS fundamentals, architecture, communicating with coworkers, etc. A mediocre interview assesses 1 of these skills. A good interview assesses 5+.
I agree with every bit of that. I'd be happy to interview at your place, if I were looking. My objection isn't even just to interviews that ask you random stuff that doesn't correlate with being useful on the job. My objection is to interviews that ask you random stuff that doesn't correlate with being useful on the job and that requires months of your time to prepare for. I think that's abusive.
I don't prepare for interviews. I just don't. My preparation is the 35 years of my career. Either that made me into someone you want, or it didn't. Sure, I'll take on your buggy code and failing tests, in an unfamiliar code base. No problem. But if an interviewer throw a bunch of leetcode questions at me, I'll fail (by the interviewer's standards). And I don't care. I'll go work for someone else.
> I don’t prepare for interviews. ... I'll fail (by the interviewer's standards). And I don't care. I'll go work for someone else.
Great. The natural result of a poorly designed job interview should be missing out on good candidates. Thankyou for giving those companies an incentive to improve their processes - by missing out on you.
You study, you learn the algorithms, and in return you get a high-paying job and excellent benefits. It’s a good deal for many.
You complain about studying unpaid, but who gets paid to study? Many pay tens or hundreds of thousands to study law, medicine, business, etc., and it takes years. Spending a couple months studying algorithms may not be easy, the process certainly isn’t perfect, but calling it abusive is really a stretch.
What it comes down to in my opinion is that these jobs are ultimately not really that different, except for how they pay. (Put another way, the main difference between jobs I've had in my career is how much they paid. The other stuff was basically the same; pay radically different.)
And if we're at the point of working tech jobs then guess what, Mr Agassiz, we're already wasting our time. The way we waste less of our time is by making our money and getting the hell out. So we can waste our time however we like.
But if you like, you can instead console yourself with, wow my boss is such a nice guy or whatever
People who are on the IB side of IB, who are making way more than 250k/year, were just born into the right social set and got hired by their dad's pals from Yale. Easier, much easier, but requires more luck.
Do physicians have to perform surgery to demonstrate their knowledge when they change hospitals?
Do executives have to demonstrate their knowledge of acquisitions or something similar?
Also let’s not act like this only applies to FAANG. Every dev job from internships and 50k entry level positions and up require the same testing. How many 70k/year jobs require testing every time you change positions outside of tech? Very few. Law, some medical fields, and a few other highly skilled fields do require licensing, but you only do that once per state at most.
Tech is the only field I’ve ever seen where your experience doesn’t matter and you have to prove your skills with every interview. In other industries, it’s mostly about personality.
> Tech is the only field I’ve ever seen where your experience doesn’t matter and you have to prove your skills with every interview. In other industries, it’s mostly about personality.
This sounds like a good thing to me (for tech). The interview process may suck, but at least everybody has to endure it. And then you're in a meritocracy. That's the theory, anyway.
>Do physicians have to perform surgery to demonstrate their knowledge when they change hospitals?
Not sure how serious you're being but the answer is yes, surgeons seeking to change from hospital A to hospital B have interviews where a surgeon from hospital B will visit hospital A to supervise a surgery or other operation. Depending on how critical the position it may even be a partner from one hospital doing the supervision. In fact nowadays the supervision can be done remotely.
Furthermore surgeons are required to maintain their accreditation by earning credits on a yearly basis through continuing education and/or training and they do so on their own time.
These guys don't mess around and if you think surgeons get hired because of their wonderful personality then you sorely underestimate the medical profession (and overestimate their personality ;P ). It's incredibly competitive, demanding, and prestigious in almost every sense imaginable.
This really just highlights the difference between the artificial coding interview via some web based half-assed IDE, and being watched coding on the job.
The comparison would be more direct if the surgeon was asked to operate on a dummy using a kitchen knife in front of the interviewer.
Then there's the problem that there's no way in hell a software company is going to let another company watch their employee work on proprietary code.
In other industries, it’s mostly about credentials. The reason a surgeon doesn’t have to prove themselves when they switch hospitals is because a medical degree means something. Getting a medical degree is brutal. The failure rate for exams is very high (60+% for specialist exams). The whole process is effective at weeding out anyone who won’t be able to do the job.
In comparison, software has no equivalent credentials. Universities, collages and bootcamps have no incentive to fail anyone. As a result plenty of weak students pass - only to discover that they’re largely unemployable. This does a disservice to lots of people - companies can’t trust degrees, and need expensive interviews. Good candidates have no way to reliably demonstrate their strengths. And weak students waste tens or hundreds of thousands of dollars and years of their lives failing to learn to code.
But the benefit of our system is that we allow programmers to be self taught. If you can’t afford to go to collage, or you are from a poor country, or you just don’t like school, that’s no barrier. You can learn programming in your own time and still get a great job. There’s lots of great programmers with the aptitude to become lawyers or doctors - but who would never be able to get the piece of paper they need to get those jobs. That’s something we as an industry should be proud of.
I'd prefer credentials, honestly. Something like the bar for law (but with no specific academic requirements - a test anyone can take) would be useful. If whiteboarding works, that can be done once and become an accreditation. Repeating the process with every job application makes it harder to change jobs, because you either have to do serious prep before a slew of interviews or keep those interview-specific skills up. It also makes the minimum time to get a new position very high.
Not only that, but isn't law a field where the quality of the jobs you can get is dependent on the prestige of the school you went to? I.e. you wont ever get a job at a top firm with a law degree from University of State
I'd say I'm under-credentialed. I don't have a CS degree.
I'd like a way to prove my skills once, rather than with every interview I have. I bet CS grads would as well. The interview process is just so... tedious. And in a field where you get significantly more money by changing jobs, that's a problem.
It's a market inefficiency imo - people get stuck in jobs where they aren't paid enough for at least some amount of time. People can't hire new employees quickly because the process takes forever. I've been on both sides of the interview process many times and it's extremely inefficient on both sides. We're developers... this should be streamlined and automated.
> Do physicians have to perform surgery to demonstrate their knowledge when they change hospitals?
Most surgical procedures are mostly the same regardless of which hospital they're performed at. It's not like software engineering where the tasks and difficulty vary greatly from company to company.
A surgeon's record at one hospital is their interview for the next job. So yes, every surgery they perform is, in essence, contributing to their interview for any future jobs.
> Do physicians have to perform surgery to demonstrate their knowledge when they change hospitals?
And even that wouldn't be comparable, since they'd be observed on something they actually do every day as part of their real job.
In software the interview drills are about thing nobody ever does as part of the real job, so one won't have any recent experience doing algorithm tricks.
From what I have seen outside of tech a lot of these 250k+ jobs go by track record, references and being able to talk well. You definitely don’t have to study and practice for weeks or months.
The process is quite a lot easier for the hire and the outcomes are frequently better for employer. A key point is that it is a much more substantial process than it is in tech, and the qualitative aspects are understood/accepted/managed.
Tech hires quickly and frequently for the short-term. The algorithms test approach is intended to condense what would be a much more expansive investigation into something straightforward (and supposedly quantifiable.) This discards a significant amount of information which is considered in other high-end jobs.
You’re right, the way that other jobs that pay as much hire is far more biased to people of the right social class who have been trained into the correct expectations of how one is supposed to act. Tech’s hiring process is more open to people without that kind of experience.
While I won't accuse any one person of this exact opinion, I do enjoy that the gestalt of HN appears to believe that for this upper-middle class job from which you'll have the power to easily destroy millions of dollars' worth of value if you screw up hard enough, you should not have to 1. solve problems in front of someone in an interview 2. bring your laptop to your interview 3. have to provide any evidence of your programming ability via open source samples or past work 4. have a take-home work problem 5. be hired to do the job on a trial basis for a period of time 6. put up with the fact that the interviewer has power if for no other reason than you are one of multiple candidates 7. essentially prove your ability to do the job in any manner whatsoever.
I can understand the arguments for many of those, but... uh... somehow you're going to need to prove yourself. We can't just throw everyone who shows up into the position to see how they'd do... and the HN gestalt would presumably complain about how awful that is, too.
Used to play this game where we'd ask the interviewer to "go deeper" on how something worked to see where there limits of their technical understanding was. Depending on the level expected (eg junior vs senior) you could expect certain depth.
Eg: "Tell me what happens when you type an address into your browser bar"
Someone junior might say "You type in the address, it fetches HTML from their server, and your browser shows it" -- "go deeper" -- "Their server uses HTTP or something.." etc..
Someone senior might get to something like "Well when you press the first 'w' key it triggers a hardware interrupt ..."
or more likely something about TCP/IP and the rest of the network stack...
I don't expect to ever have either the chance or the true desire to do this, but I've often wondered if I could, with literally zero additional preparation, spend a full 8 hour day presenting an answer to that question extemporaneously. If I couldn't, I'm not off by much at this point.
A doctor can do a whole lot more damage than the vast majority of software engineers, and yet doctors don't have to start this proving process from the ground up every job change.
A fair point. I would suggest that doctor's decade-long post-high-school educations are much, much more directly connected to what they are doing than a 4-year bachelor's in computer science is to a programming job. A doctor comes out of an internship in which they were actually doing the job for an extended period of time under heavy supervision. If software engineering adopted the same procedures, we could probably also get away without these interview procedures.
My experience with consulting jobs is that while the interviews themselves are still difficult, they do not require nearly as much of this "devote your life to studying and taking practice tests" that the tech industry is enamored with. Consulting interviews are almost all behavioral, and sometimes require a short case presentation, but even the case rarely requires days and days worth of preparation. Yes, there are some who do prepare endlessly (like "Cracking the Case Interview"), but I know far fewer people who go that route and even those that do still spend only a fraction of the time on it compared to leetcoders.
The mindset during consulting recruiting seems to be more of "we want to make sure you have a decent base level of knowledge and problem solving skills, but if you don't know how to code/make a PPT/whatever, that's fine, because we can teach you that stuff". Big tech recruiting seems to be the opposite: even when big tech companies claim "you don't need to know everything, because we'll teach you", they still require you to jump through these leetcode-style hoops to prove your skills.
And this is echoed beyond the hiring process too, in my experience. Consulting companies hire smart people and want to keep them for a long time, so they invest a lot of money into training those people and attempting to keep attrition down. FAANG on the other hand seems to care less about attrition (sometimes even embracing it, eg Amazon) and wants to hire people that require minimal training, and thus wants people that have immediately demonstrable knowledge so they can be immediately productive.
>My experience with consulting jobs is that while the interviews themselves are still difficult, they do not require nearly as much of this "devote your life to studying and taking practice tests" that the tech industry is enamored with.
What type of consulting are you talking about, and are these jobs really paying >$250k? What would someone have to do to get a shot at one of these jobs?
Top management consulting firms (McKinsey, BCG, ec) are insanely competitive and won't consider anyone without elite credentials, i.e. top grads from elite undergraduate programs, MBAs from top schools, Ph.Ds from good research programs, etc. These opportunities are far more scarce and require more effort overall as well. I suspect that some of these firms could hire more or less randomly from those who make it to the interview stage and do nearly as well, since their resume filtering is extremely rigorous, while their skill requirements for most roles aren't that high outside of being smart, analytical and willing to travel and work insane hours. Big Tech is substantially more egalitarian in terms of who they let through to the interview stage, while the actual job demands somewhat esoteric skills that go beyond just being a smart, analytical hard-working person, which necessitates a more meaningful filter.
I suppose Big Tech could do something similar (skip leetcode stuff for people who have credentials such as prior experience at top tech firms and/or tangible research experience at top research institutions) but I suspect that would not go over well with most people that have issues with the current hiring processes.
I keep hearing this but in my country iẗ́s just not true. Yes you needed to go to the right school (most difficult part but not difficult) an maintain a 3.5 (what they advertised) or even a 3.0 GPA (what they ended up accepting) and join a few student clubs (which nobody really cared about).
Are you talking about US-based top global management consulting firms and actual strategy/management consultant roles (since top consulting firms often do other things like technology, tax/accounting, etc)? I guess that's possible but I suspect that in that case, it's largely because roles in these offices aren't quite desirable from a comp or a career track perspective. The reason why management consulting is hard to get into is because it pays well and it promises a career track where you can get to a 7-figure income and potentially go directly into the upper management of F500 companies afterwards without working your way from the bottom. If that's not a realistic path from a satellite office (I have no idea if it is or not), then it wouldn't have the same draw. If it is though, I mean it has to be competitive, right?
Yes, management consulting at the local offices of the "big 4". Starting comp in MC something like 60k/yr (whereas IB is double).
More high end opportunities than other career paths certainly, but it's much less top heavy. 7 figure income, a few CEOs make it but not common.
Kind of make sense though if local offices adopt some of the same rhetoric and marketing (elite selectivity etc) as the US head offices but with really different market conditions.
From what I know from doctors, what FANG does is basically the equivalent of doing your board exams every time you want to change jobs. Which usually gets a reaction of dread & disgust when you couch it in those terms to doctors.
Interviews are significantly easier as far as prep time goes for doctors & psychologists.
BUT, you don't have to go through the entire med school & residency rigamarole as a software engineer either, so as far as total effort goes FANG is probably easier. I posit that software engineering is probably the most egalitarian method of socioeconomic mobility, because the only real barrier is time, a laptop, the internet and motivation, while all the other methods require an upper-middle class background and expensive schooling (law, medicine, finance) or just plain luck (business, celebrity art & sports)
But being an interviewer in FANG, I've actually found it rare to find the self taught type in practice. But we do leave that door open unlike medicine.
> From what I know from doctors, what FANG does is basically the equivalent of doing your board exams every time you want to change jobs. Which usually gets a reaction of dread & disgust when you couch it in those terms to doctors.
If Software Engineers want to get rid of algorithmic interviews, all they have to do is come up with a professional exam and a strict licensing body... just like most professions carrying a tittle (MD, Lawyers...).
But as long as "3 months js bootcamp grad" can advertise himself as a software engineer just as much as a guy from Stanford CS then we'll keep having these interviews.
> But as long as "3 months js bootcamp grad" can advertise himself as a software engineer just as much as a guy from Stanford CS then we'll keep having these interviews.
The fact that a bootcamp grad can compete for the same software engineering jobs as a Stanford CS grad is one of the very best parts of the hiring process in our industry. Are you proposing that we start using credentials as gatekeeping?
The filter is usually a 15 minute test, while later you have multiple-hour interviews, sometimes even whole day in the office just doing interviews.
So you're not even getting that much, unless you somehow fear failing the first test, while being confident in the multi-hour interview skills?
Ironically, that article was written in a era where there weren't really boot camps, only CS Grads from actual universities, and in that article it specifically calls out many CS grads cannot code.
> The fact that a bootcamp grad can compete for the same software engineering jobs as a Stanford CS grad is one of the very best parts of the hiring process in our industry. Are you proposing that we start using credentials as gatekeeping?
But we already do use credentials as gatekeeping. There's a lot of talk about bootcamps and whatnot, but how many of these people actually get passed the resume screen when compared to a Stanford CS grad? FAANGs famously recruit from same 20 universities, and then complain about "lowering the bar" if they branch out anywhere else.
> But we already do use credentials as gatekeeping. There's a lot of talk about bootcamps and whatnot, but how many of these people actually get passed the resume screen when compared to a Stanford CS grad?
At some point there's a signal to noise ratio issue here as well.
Companies don’t examine their efforts. They copy off of each other. How many processes are simply aped with the excuse, “Well, BigCo does this, so it must be right”?
There’s plenty of excuses for gatekeeping, but the real reason is laziness. Of course, we don’t call it that, we call it a meritocracy and apply our biases as “common knowledge”, “proven”, or if we’re feeling particularly full of ourselves, a “sufficient statistic”, but never what it is: a bias, a blanket assumption, a gate.
As soon as you’re relying on assumptions, it’s not a meritocracy. It’s bias promotion, ie gatekeeping.
I have been doing this for 20 years. I used to be good at algorithmic challenges 20 years ago straight out of university - because that is a ,lot of what we did.
I have these I have used "challenging" algorithmic stuff a handful of times in my careerer. Same with recursion, I have used it, but not too many times.
If I do hackerrank or leetcode or something similar these days, it's pretty much luck if I will get it. If I sat down long enough I could work it out, but with a 2 hour time limit, its usually 50/50 whether the answer appears in my head in that time frame.
And here's the thing. I write a lot better code than I used to. I know what is important, and it isn't clever algorithms, it's choosing the right abstraction, and keeping things maintainable. Making the code easy for the next developer to follow. For the vast majority of software roles out there this will be so much more valuable than algorithmic knowledge. Sure knowledge of computer science fundamentals is important, but I think we give it too much emphasis over what really counts.
Basically these are testing for a computer scientist when the job is for a software engineer.
We need a compromise where proven, experienced engineers can stop having to go through everyone's homebrewed technical interview and new candidates still have a shot if they don't have that credential yet. It should be up to companies to decide if they want to use those credentials, and I suspect companies would switch if it maintained a good reputation because why bother with a job that requires a technical interview?
Neither leetcode nor homebrewed are what we want anyway. But homebrewed is IMO worse because it could be a weird format and people have issues with surprises during technical interviews, least of all anxiety. And when there's a bunch of different flavors and formats, candidates either prepare for them all or accept that they won't do well at some formats and forgo those jobs.
IME candidates are spooked way more by leetcode than homebrewed tests that mimic the job they do every day.
I'd estimate (from browsing graduate boards) it's probably among the top 5 most hated aspects of the industry. #1 for many - because it's so anxiety inducing.
Your experience must be different than mine then, which, it's a large field so it's totally possible. Dunno, it'd be great to not have to repeat any kind of technical test, regardless of the format preferred.
This is absolutely the worst thing about hiring in our industry. The reason interviews are so abusive is that there is no way to effectively filter candidates. There's no reason to say a four year degree is the requirement, mostly because such a degree does not predict ability very well. But on the other hand, it is possible to design a credentialing system that would be effective. If we, as an industry, want self taught people to be able to get jobs we can design the system so that it the credential is obtainable by someone who is self taught. Personally, I'd like to see a system that combines testing, a practical exam, and then a further credential that you can get after you have some work experience.
That's also why there is so much shit software out these. Small companies saving money initially by using inexperienced developers. Then once it is making money they need to hire a load of seniors to clean up the mess. (Though plenty of seniors are capable of overengineering a mess as well)
Another way of reading your statement: That's also why there is SO MUCH shit software out there.
If small companies weren't able to use inexperienced developers to spin up half-assed MVPs, we'd be at the mercy of whatever large companies are interested in developing, and time has shown that as companies get bigger, they lose interest in niches in favor of products that will be massive successes.
You're not wrong, but I also don't think the world you are describing is a problem.
> If small companies weren't able to use inexperienced developers to spin up half-assed MVPs, we'd be at the mercy of whatever large companies are interested in developing
That's an interesting perspective. I would say there is some truth in it, but a lot of small companies get plenty of investment money.
But then you just ignored the whole micro-ISV market which is cranking out tons of software solving interesting problems.
And investment money has its own issues. VCs view their companies as a portfolio, they are only interested in ideas that have the potential to be huge. There are plenty of software products that should exist but are not interesting to investors because they are not potential unicorns, but interesting to smaller software shops since that revenue will provide a nice living for them.
Yea, but I also think it's more complicated than that. I would think that if you already work for a FAANG or other well-respected tech company, that would de facto serve as your "professional certification" and help avoid these ridiculous interview processes. If you work at Google as a SWE, then you've already passed a pretty high bar to become a SWE and when you apply somewhere else, ideally they would see you can pass that bar and not ask you to leetcode your way over the bar again. But IME, that's not the case. I know some FAANGs that, even when doing an internal transfer within the company, still require you to go through the full leetcode interview process.
There seems to be some kind of inherent or cultural distrust amongst tech interviewing, where nobody trusts that anyone has tech skills unless they personally verify it. I don't think a professional exam/certification would solve this distrust.
Back in the day I remember stories about candidates who would get an offer from Amazon and then Google/MS would just automatically counter-offer without interviewing as it was assumed that if they passed the Amazon interview then it was good enough for Google/MS.
> "I would think that if you already work for a FAANG or other well-respected tech company, that would de facto serve as your "professional certification" and help avoid these ridiculous interview processes"
Nope, not at all. Despite their rigorous hiring process, even the FAANGs have bad hires, burn outs, or people who simply can't keep up with the pace. Some FAANGs require an interview loop even for internal transfers to guard against a bad hire.
I highly doubt there are even a few software firms who would offer you a job sight unseen purely because you have a prestigious company on your resume. It might help you get your resume to the top of the stack but you’ll still unfortunately be leetcode grinding and whiteboard hazing.
> you've already passed a pretty high bar to become a SWE
The problem with the algorithm/leetcode style is that you can run it at a very high bar and you end up selecting people extremely skilled at that one thing, but which has very little to none correlation with shipping reliable & maintainable production code.
I've never needed to hire (and surely never will) people who can reverse binary trees with a hand tied behind their back, so that style of interview is not a meaningful signal.
Fwiw, Triplebyte has a fast track program which allows candidates to do a 2 hour proctored pairing session. Companies can use that as a way to filter and take over at least part of their hiring process - it’s a one and done thing for a candidate dealing with any companies through the platform. We’re currently experimenting with it.
It would be nice to have something like this completely divorced from a recruiting engine though.
I was very excited about Triplebyte when I first saw it. I did very well on the test (>80th percentile straight out of school, as high as their scale goes) and was looking for junior positions. I didn't get a single interview and didn't get any feedback from a human after the exam was over.
Perhaps other parts of my profile were unappealing, perhaps I applied to the wrong positions, or perhaps Triplebyte doesn't have many contacts outside of California. Whatever the reason, I was not impressed with the results. Their entire business is designed for people like me and it achieved nothing.
I’m genuinely confused by this comment and any downvotes. No candidate is doing unpaid work for us or for this service (ie. building out their platform). It's a way to validate a skillset, pure and simple, and that's how this platform makes its money. The output from a candidate has no business value aside from this.
I can understand distaste about having a time imbalance (ie. a candidate is not investing the same # of ours as our staff), but like I said, this is a one and done thing and can be used w/ a way to cut down time working with any other companies using the platform.
For us it means going directly to the final rounds, whether they took it at our suggestion, for another company, or just did it for themselves. If they do it for us and they don't end up with an offer, they are not left empty-handed from the process.
In sum, it moves toward some sort of accreditation system, that’s the reason I mentioned it. It's a shame my comment is at the bottom of the pile as I too would love a future where the only time spent interviewing is just a couple hours getting to know my future teammates, and I truly feel platforms like this may eventually get us there.
All the same I'd appreciate feedback on why they're disliked. I've seen them mentioned in other HN threads without any vitriol.
Ok, so why not pay devs for their time? Because you prefer to use that time as profit, no?
The system encourages the default distrust of developers resumes. That most of them out there are lying, and we need a test to be sure that they can actually code. How many people have actually hired the mythical devloper that can talk well in an interview and not code?
ONE MORE TIME - NO ONE IS PROFITING FROM INTERVIEW OUTPUT - THIS IS TO ASSESS ABILITY AND ONLY THAT. Forward, backward, sideways, up and down.
If you're doing work that benefits the company that is another matter, but that's not what's happening here (or anywhere I've ever worked) and is ethically dubious regardless. That's not the point of an interview. I can't believe I'm having to explain this.
You don't pay a dev for their time during the interview process for the same reason no one pays anyone for their time to interview in any industry.
To hire straight off a resume is beyond wild. I'm in the process of hiring a dozen developers for my team, and have had 3 people who had great resumes fail a basic pairing session - they couldn't code. In the 24 years I've been in this industry, probably had at least a few dozen encounters like this. Sure, 90% of the time this isn't true, but it's true enough that it's insane to do it.
"How many people have actually hired the mythical devloper that can talk well in an interview and not code?" I actually have. Twice. Earlier in my career when I believed these sorts of things. And was on hook for cleaning up the mess. Never again. The harm to the team's morale is not worth it.
>If Software Engineers want to get rid of algorithmic interviews, all they have to do is come up with a professional exam and a strict licensing body... just like most professions carrying a tittle (MD, Lawyers...).
By the time the exam is designed - not complete, designed - it will be obsolete. By the time the exam is completed, there will be 3 new languages invented.
This would be like changing what animal you have to study as a doctor every six months for the test.
Definitely not. The vast majority of computer science and software engineering practice needed for successful product delivery was developed back in the 50s to the 70s and has not substantially changed since.
The library and framework of the week is not fundamental experience.
I always advocate computer science training really needs more history of the discipline. So many new languages and libraries turn out to be a rediscovery of ideas thoroughly explored in decades prior, just that the creator didn't know.
An orthopedic surgeon gets new types of tools and implants in their toolbox through their career, but the structure of the bones they operate on is the same forever. It's the same with software.
The IEEE has taken the first step toward professional software engineer licensing with the "Software Engineering Body of Knowledge" and associated certification program. So any company that wants to could accept that certification as a substitute for their own algorithmic interviews. (I am not necessarily recommending that, just pointing out that the option exists.)
My colleague just left after doing a load of AWS exams. I am left to fix his mess. He will create another over engineered over complex mess. He values clever over maintainable. I am not sure exams are the answer, but I don't have a better suggestion.
For what it's worth, I worked with a talented self-taught engineer. He stated he hit a ceiling and needed to get a degree and so he did through a remote learning program. In the event that this is common, it may explain why they're rare. The resumes of the ones that don't hit that ceiling probably don't make it to your desk.
I don't know if there's a ceiling for degree-less software engineers in the Bay Area. Speaking as someone who dropped out of college and is now a "senior" software engineer at Google, I've worked with a couple folks who are much more senior than I am without a degree.
That said, it's much harder to get your foot in the door without a degree, even in the Bay Area. I had to go above-and-beyond to get my first job at a small startup (I created a program that used their API and was useful enough that I ended up continuing the work when they hired me). With my second job at Dropbox, the recruiter told me that they only reason they interviewed me was because I went to Recurse Center (which is a free programming retreat for programmers that also acts as a recruiting firm). Multiple companies have grilled me during interviews about why I dropped out, including Google.
It seems kind of strange that you would go to university to progress. I feel the opposite, university was a good starting block but the vast majority of my knowledge is from on the job.
> I posit that software engineering is probably the most egalitarian method of socioeconomic mobility, because the only real barrier is time, a laptop, the internet and motivation, while all the other methods require an upper-middle class background and expensive schooling (law, medicine, finance) or just plain luck (business, celebrity art & sports)
As much as we all hate the tech interview process, it's a relatively level playing field as far as hiring goes. It's not perfect, of course, but we have to select on something.
As engineers we have a level of free access to study tools and material that my friends in other professions envy.
The alternative to skills testing is to rely more on credentials, references, and background. People who come from elite universities or lucked into prestigious jobs early in their career tend to prefer this type of interview process because it benefits them the most while excluding those who are trying to break into the industry.
The benefit of skills-based testing, however imperfect, is that it opens the door for people who have skills but not the right background or credentials to skip through the ranks and get a foot in the door.
> it's a relatively level playing field as far as hiring goes
I am not sure that is true at all. People with family or basically any commitments outside of work don't have anywhere near as much time to practice for this sort of thing and why should they need to practice for an interview? You do the job every day, if that isn't enough then the interview is clearly testing for the wrong thing.
You go to med school or law school generally before you have had children. After you've done those things, you don't study for weeks leading up to an interview. Instead, you have a piece of paper that proves what you know and the interviews are more a decision of "do we want to work together" rather than "is this personal qualified".
I see, so among the audience which has been prescreened, life is good. I can see that being nice, if you're in that class of people.
However as someone without a CS degree who is nonetheless able to get jobs as a software engineer because there isn't a process of credentialing, I am glad much of the industry works the way it does.
>People with family or basically any commitments outside of work don't have anywhere near as much time to practice for this sort of thing and why should they need to practice for an interview?
I've done this rodeo in my thirties and forties, complete with a very busy existing job, family, long commute, etc. The bottom line is that the time investment wasn't terribly large as it was more refreshing than learning things from scratch.
Putting the 20 hours in over a couple weeks for a 2x raise felt like a worthwhile expenditure of my free time, and worth prioritizing over some of my every day commitments.
My partner is a lawyer and I am a software developer. We've both been in these fields for about a decade.
The key difference between our professional experiences is that the legal profession is self-regulating, whereas software devs/qa/pms are totally socially atomized.
Lawyers have their own organizations, which give them some independence from their clients. Society accepts that this is desirable for the maintenance of the legal order.
Software occupations should move in this direction, for the good of practitioners (wages, working conditions, fairness in promotions and hiring) and the wider society (complement to government regulation around security, privacy, fairness in hiring and promotion).
The bar association defines the examination that lawyers must pass to practice. Employer/client interviews focus more on "culture fit" and familiarity with specific practice areas than on certifying basic competence. The bar also administers "continuing education" to ensure that a lawyer who passed the bar decades ago isn't totally out of the loop on recent developments.
I would love to see the software sector move toward this kind of self-regulation through unionization. We have the power, we just need to coordinate.
Instead of a high-stakes and all-too-often arbitrary interview every single time you want to change jobs, you could prove your basic competence to practice through an exam, and elect to fulfill your continuing education requirements however makes sense for you, within a framework decided upon by workers themselves.
Such a system would not be perfect. No set of examinations is ever going to perfectly capture ever-shifting real world requirements, for example. But we can hardly do worse that the sector is doing now.
We have to stop letting recruiters (i.e. middlemen) and employers (i.e. counter-parties in the employment relation) dictate terms to software workers arbitrarily. The wider society should support tech worker organization in unions because these organizations would provide a check on executive and investor power. Without such checks and balances, we can only expect more of the same short-term thinking and ethical corner cutting.
The problem with this approach is that it creates serious barriers to entry.
I'm an immigrant who finished a pure-math PhD and went into software engineering afterwards by building up a portfolio and leetcoding in my spare time. With your system there is no chance I could have done that. Passing all of the exams would not have been possible without a strictly CS education, and I couldn't have studied for the exams after my PhD finished because my visa status at the time was tied to being actively employed.
So many people nowadays are becoming productive software engineers from slightly unconventional backgrounds (pure math, physics, boot camps) and this would stop immediately if CS certification became part of the job requirements.
I did not mean to imply that a CS degree would be necessary for all work in software. I would oppose such a system as obviously irrational and serving only a subset of incumbents. With your background, you would if anything have found it much easier to enter the field, as you would have known exactly what to study for and, once certified, had more bargaining power with specific employers.
Barriers to entry exist today, and will always exist in some form. The question is who gets to define them. I am arguing that the workers themselves should have more of a say than they do at present.
One union certification could literally be passing some randomly selected leetcode problems. Ideally, there would be a variety of certifications to reflect the variety of niches in software (someone doing TLA+ for embedded applications shouldn't need to know anything about web app architecture, necessarily).
The difference is that you wouldn't have to do it for every new employer, and workers would have more say in defining the body of knowledge considered relevant.
I don't think anyone would advocate for university credentials to be a hard requirement. I personally have no relevant university credentials except some math courses from a community college.
That said, I think it would be fine for someone to submit a transcript from a CS degree to be certified for basic algorithms knowledge in lieu of sitting an exam on that topic.
Depending on how it's implemented, it could actually work to the benefit of non-degree holders. A certification reflecting your ability to leetcode and a review of your portfolio, could put you in the same place as graduates of elite CS degree programs.
> Instead of a high-stakes and all-too-often arbitrary interview every single time you want to change jobs, you could prove your basic competence to practice through an exam, and elect to fulfill your continuing education requirements however makes sense for you, within a framework decided upon by workers themselves.
with how the barriers to medicine/law actually work. A single Amazon interview is not particularly high-stakes - if you bomb it you have a dozen+ companies that can offer similiar comp, and you can always re-interview after a year.
If you bomb the LSAT, or the MCAT, or STEP 1, you will effectively be branded for life. All your future applications to school/residency will include this information. How is emulating that going to get us closer to your stated goals?
> If you bomb the LSAT, or the MCAT, or STEP 1, you will effectively be branded for life.
I don't think this is true. I've heard anecdotally of people bombing the LSAT/MCAT, retaking, and entering elite universities.
But in any case, the analogy is not with exams to _enter_ post-secondary school training, but with exams to certify vocational skills _after_ such training and/or real world experience (e.g the bar exam, the F.E./P.E. in engineering, "masterpiece" evaluations in the skilled trades).
Private enterprises like TripleByte/codility try to perform a certification function of the kind I want to see workers handle through their unions. In fact, it might make sense for a union to simply contract with TripleByte/leetcode/codility to implement examinations. TripleByte has no real incentive to make its examinations a single-shot affair. Why would a worker controlled equivalent have such an incentive? There might even be a perverse incentive to encourage people to take the exam multiple times (as, for instance, the College Board does) that would have to be guarded against.
> exams to certify vocational skills _after_ such training and/or real world experience (e.g the bar exam, the F.E./P.E. in engineering, "masterpiece" evaluations in the skilled trades).
I think what needs to be considered with this is three things:
1. Tiered credentialing & scope of credentials
2. On-boarding / grand-parenting those who are already practicing
3. Studies on what interviewing in non-software related technical fields looks like. I see lots of anecdotes (probably data now) on what software interviewing is like, but mech / civil / elec, actuary, etc. interviewing isn’t something I’ve seen discussed as openly.
I hope I’m not misrepresenting or coming across as negative here or in what follows.
- - -
1. The F.E. and P.E. exams seem to be aimed at people with engineering degrees, so it’s the interaction of both education and practical experience being certified.
For the F.E. exams from [1], “It is designed for recent graduates and students who are close to finishing an undergraduate engineering degree from an EAC/ABET-accredited program.”
For the P.E. exam from [2], “It is designed for engineers who have gained a minimum of four years’ post-college work experience in their chosen engineering discipline.”
Even after passing those exams, there is still annual education and training requirements to maintain certification. Yes, it’s not nearly as rigorous as whiteboard coding that people are currently subjected to, but it’s not a one time activity either.
In both cases there is emphasis on college.
I’m Canadian and it’s pretty similar for P.Eng. There are some exceptions, but they do require a college education.
This leads to tiered credentialing in the Canadian system. There are:
- technicians (1 year education)
- technologists (2 years of education)
- engineers (4+ years of education)
There is a defined scope of work for each of these professionals. To move up the tier requires education, exams, and apprenticeship. To switch between specialties, I’m not sure if it’s possible.
Not everyone in the engineering profession needs to be an engineer. It is entirely okay to have tiers. However, tiers become very restrictive and could be perceived as gatekeeping, among other things.
2. I think there will have to be a dividing line of some sort to keep those who have valuable experience without an CS education in the field.
Something like: All people who can prove work experience and practical experience are under this one assessment and credentialing method. All others after follow a different credential evaluation method. Or the tiers allow math, physics, self-taught, etc. to be credentialed as such.
3. Technologist interview anecdote. When I was interviewing as a manufacturing engineering technologist the assessment has been:
- read a shop drawing and tell me what these symbols mean
- jump on a computer and start producing a 3D model in the software used by the company. Produce a 2d shop drawing from that model
- explain how you would come up with an inspection plan to show the product has been manufactured correctly
- solve statistics problems. Set up a control chart. Interpret what the points mean and explain the next steps. Design an experiment. Tell me the hypotheses, tell me how you would calculate sample size, how do you know that’s a good sample size?
- go on the shop floor be handed an inspection sheet and inspection tools. Check if this part conforms to standard
- whiteboard ladder logic for PLC
- handed some print outs of CNC code and asked to explain what the lines meant
Those are technical questions I’ve been asked in a series of interviews for manufacturing technologist jobs. It’s not one 8 hour day of interviews like some tech companies. It’s usually 2-3 sessions x 2-4 hours each session. That line of technical questioning is not a substitute for education. It’s on top of having education and certification in the field.
I've got two doctors in my family, and from how they describe it getting into med school is easier than FAANG. Once you're in you're practically guaranteed 250k after 7 years of training and 500k debt. Residency definitely sounds like a pain in the ass, but if you graduate from a reputable American med school it's very unlikely that you don't match. I guess it depends on how you define easy. Some may define it as amount of work required, I tend to think as chance of success.
Getting into any US med school is definitely harder than getting into FAANG. [0]
Part of it is things like the MCAT and organic chemistry are hard, part of it is there's a whole "hidden" component of med school applications related to volunteering, shadowing, research etc, that is opaque to most. This is part of the reason 50% of med school students already have a parent working in medicine.
> Some may define it as amount of work required, I tend to think as chance of success.
I don't understand how anyone can think that 7 or more years of med school and grueling residency is somehow easier than studying Leetcode for a few weeks or months.
Med school has a very different selection bias than FAANG interviews. No one seriously attempts to attend medical school unless they've committed to 7 years of grueling training. A FAANG interview, on the other hand, is barely a blip on the radar over the course of an engineering career. A lot of people apply to FAANG jobs just to try their chances at the application process. Not so for medical school.
> I don't understand how anyone can think that 7 or more years of med school and grueling residency is somehow easier than studying Leetcode for a few weeks or months.
It's obviously easier if done only once.
But doctors go through education & residency once and then start their careers.
Software engineers need to repeat this every job change for no reason.
> I guess it depends on how you define easy. Some may define it as amount of work required, I tend to think as chance of success.
I'm not sure if the chances of success are any higher for getting into a medical school in the US. As a one-shot thing, a FAANG interview loop may be tougher, but there are a lot of big tech companies and you can keep trying your luck. I think Amazon alone has like 50K software engineers, they churn engineers like crazy and the hiring bar isn't quite as high as some of the others. Whereas if your undergraduate credentials aren't good enough or you simply don't do well on standardized exams, you're kind of out of luck in terms of getting into a US medical school. I could be overestimating the difficulty of getting into the least competitive medical school in the US, but my understanding is that they are all pretty difficult, leading many people to go to a medical school in the Caribbean.
I think that's exactly what I said? This contrasts with the medical school where I guess in theory you could reapply, but large parts of your application are going to remain the same.
From what I’ve been told instead of an obnoxious interview process, they require expensive credentials and are siloed by the prestige of their schools.
I sure don’t think leetcode interviews are great, but I’ll take it compared to that.
This isn’t a serious question if you consider that the people who struggle with them have spent their time optimizing for delivering real value and the problems don’t demonstrate or even provide entry from that.
Doctors and lawyers certainly have a much easier hiring process, from all the ones I know. And in both fields experience is respected, the opposite of software development.
Doctors in particular (with residency) and lawers to a lesser degree (bar exams) have a more difficult path into the profession. But they don't have to prep and go through the bar exam for every single interview after that.
It would be unthinkable to make an established surgeon balance chemical reaction equations or something obscure like that from their undergrad days as part of the interview! But that's what software engineers must deal with.
I wonder what percentage of people at their current job would pass if they had to re-interview without preparation.
In general, companies with more money than they know what to do with can offer increasingly larger wages to make people jump through arbitrary hoops. I know people get frustrated with this, but it's really the rational thing to do.
When you consider the expected value, siphoning up 10 to 25% of your employers time to practice leetcode at work will benefit you more than doing most things at work.
I'm joking that because I skipped half the process (which I can't take any credit for, it was an accidental mixup on their end not because I am that impressive) it was a very easy interview.
Didn't have to do a code test or defend my code or anything like that.
A big reason we use leetcode style challenges is because they can be automatically scored, while take-homes take a lot more to review.
I'm building a developer screens sharing app that, among other things, automates non-whiteboard interviews. Typically we can review a 60 minute take-home in 10 minutes, without cloning the repo. http://paircast.io
If you're an engineering manager that wants to move away from the leetcode challenges, please get in touch with me. ian@haxor.sh
This is an almost inextricably linked effect of allowing anyone who thinks (or wishes) they have the skills to compete for a $250K/yr job.
If you put a grand prize out there, lots of people are motivated to go after it, including the ultra-long shots.
On of my favorite interviews was for Acclaim in the mid-90s. Take home (download a zip file with a skeleton app, read the code, write the strategy element that’s stubbed out). I don’t recall how much time they allowed but it was at least 24 hours. Mine was “navigate an airplane from left of screen to right of screen against a fixed set of blocked squares[mountains]”
Probably spent a little over an hour on it, enjoyed doing it, and remember it 25 years later. They can score such a test (at least initially) totally mechanically, weeding out the “couldn’t get anything to work” subset of the population in zero minutes of engineer time per new application. It tests something quite close to what you’d do as a game programmer for them. You can do it at home, at your own pace, in your normal environment. If you pass, then you might have to get an airplane and travel to interview, which is a multi-day disruption to your life.
I’m on the employer side now; I see the value in asymmetric tests at the initial filtering stage for entry-level, because I don’t see any workable alternatives that don’t introduce other, likely worse, forms of credential-checking.
I’m sure we miss some good candidates this way; false negatives are bad but less costly than false positives.
I don't see that the benefit exceeding the paperwork required to create and pay 0.75-1.5 hr contracts in the 51 different states plus District of Columbia plus many local taxing jurisdictions for just the United States, to say nothing of the hundreds of other countries that may each have their own requirements, filing requirements, or other traps.
What do you think of asking applicants to compensate the company for the time spent reviewing their application? (Many colleges have application fees as an analog.) I would be opposed to this type of friction-introduction as well.
Applicants cover their costs (including time) and company covers their costs (including time) seems to be working reasonably and gives both actors choice about how to balance their inputs and expected returns. If either side demands too much, the market moves away from them.
> A big reason we use leetcode style challenges is because they can be automatically scored, while take-homes take a lot more to review.
Literally this. You can pretty much do all of the interviews required for FANG without talking to a human being, which from the FANG perspective, is absolutely GREAT, because it takes all of the existing social biases (e.g preferring a certain race, preferring a certain gender, etc.) out of the window and focuses ONLY on the algorithmic knowledge of the applicant.
Of course, there might be some interview here and there about soft questions, but for the most part, they don't really give a shit about that, and it's unlikely that you'd be rejected based on that, unless you _really_ suck at bull-shitting success/failure stories (which I am - can't stand doing it).
I think the last time I applied to Amazon (over a year ago at this point) I didn't even get phone screened. It was just a link to 2 graph algorithm problems that were the equivalent of a medium difficultly on Leetcode, and I was immediately graded. It's so fricking easy for FANG nowadays.
The issue with take homes is they tend to be time unbounded for the interviewee, not the amount of time it take to review them AND there is still a whiteboard algo interview to do.
When your doing whiteboard interviews the interviewer is there the entire time interacting with you, so it's taking up 1.5hrs of engineer time at least for every 1hr interacting with the interviewee. Reviewing a take home takes less time.
>A big reason we use leetcode style challenges is because they can be automatically scored
but they're not? every screen i've been through has been on something that doesn't even compile the code (e.g. coderpad.io for FB or docs at G) and the interviewer then writes a summary afterwards (ala hiring packet at G) with ratings along some axes.
> A big reason we use leetcode style challenges is because they can be automatically scored, while take-homes take a lot more to review.
Take-home problems are automatically scored as well. The company defines an API or interface to the code and creates a test suite to run against it.
The benefit of take-home problems is that you have the option of reviewing the code in-depth if you need more perspective. If a candidate only passes 7/10 tests, I'll still dive into the code to see what went wrong. If it's an honest mistake, I ignore the failure and amend the instructions to make it more clear for the next candidate.
These posts are getting tiresome. There's way too much focus on FAANGs and SV in general.
Most of us work in hum-drum industries for companies no one's heard of, in towns no one's heard of, and have reasonable hours, good enough pay, and have never logged onto leetcode for anything other than to briefly see what all the fuss is about.
I will guarantee that at least half the developers I work with have never logged onto leetcode and many have not even heard of it. They're too busy working, raising kids, and coaching little league to be wringing their hands about the latest nonsense in SV.
As a lucratively employed Silicon Valley engineer, I’ve never seen leetcode. Not even sure what it looks like or how it works.
And that’s with being an immigrant from eastern-ish europe.
But it sure is fun to flog on it as a meme. I doubt more than 30% of engineers working in SV startups ever actually used leetcode. And I certainly wouldn’t hire anyone above absolute junior based on their leeting skillz.
Have you worked at a publicly traded SV company that pays comparable to MSFT, Amazon, FB, Google or Apple with good stock growth? Nowadays there are startups that don't do algo interviews, so if you've been lucky, then you've never encountered that interview type.
Leetcode is shorthand for algo interview prep, there are many alternatives to leetcode itself.
No, he's only worked at Yup in SV AFAICT. Maybe he's making $400K+/yr there but I'm somewhat skeptical. It could be his perspective on what is lucrative is very different having come from eastern europe and maybe comparing to there rather than to FAANG TC or what a soon-to-IPO company TC would be. (e.g. Instacart)
I've interviewed with 100+ companies in the bay. His experience is not representative of the industry at all, IMO... 90% of companies use leetcode here. Again, I need to emphasize, I've interviewed with way more companies than most people and most of my peers interview with dozens as well and they all have to grind leetcode.
Fair. And no, I haven't worked at a publicly traded company nor would I really want to. The optionality makes for good leverage in salary negotiation though.
From what I can tell when interviewing engineers, most over-index on the algorithms. Sure we all ask an algorithms question, but it's more of a checkbox. It's the other 6 interviews that tell us way way more about the candidate.
And yes, I could get more at Facebook, Google, or Apple, but then I'd have to work for FB, Goog, or App.
I think you should try to interview at a few of those places, then you'll understand why everyone focuses on the algo parts. If you fail one interview type, it's very rare that you will get an offer, and it pisses you off that you failed one interview because it was some left field random algo question that you haven't encountered before.
The rest of the interview types are fairly easy to prepare for, you almost do not have to, just do a few interview loops with your lower priority companies and your mostly good.
I also would reconsider not working at a pubicly traded company. I used to work in a startup for years, and I regret not switching sooner. Dan luu summarizes my thoughts on it: https://danluu.com/startup-tradeoffs/
I've never had a startup offer to pay close to what FAANG gives in terms of compensation. And no the equity worth as much as pre-COVID toilet paper doesn't count.
edit: And I've never seen a startup offer enough equity to offset the average risk of that equity being worth nothing (and things like not being able to invest the money). It's fine to take a gamble, the payout can be nice, but in terms of average expected money after X years startups are light years away from FAANG in my experience.
I can understand your annoyance at the FAANG obsession, but when the total comp is literally 2-3 times that of the hum drum industries, doing roughly the same work, it makes sense that people would want to consider them.
A significant portion of developers (and especially developers on this website) have experience with, or desire experience with, these FAANGs and SV companies, and these posts are relevant to them. If you feel like you aren't the target audience, then you are welcome to ignore the post and click on something else. But it's a bit absurd to condescend others just because they have different experiences than you.
And with that said, you too should care, because I guarantee it's only a matter of time before those "hum-drum industries" take a look at the way SV does things and says "hey, we should do that too". This is already happening in many places. Your company could be next. You should be interested, if only to learn to spot the warning signs and nip it in the bud when you can.
When there is a cottage industry focused on training people to pass your interview then you have a problem.
I think Allen Iverson said it well:
"We're talking about practice, man. [laughter from the media crowd] We're talking about practice. We're talking about practice. We ain't talking about the game. [more laughter] We're talking about practice, man."
Fun fact:
I had a recruiter reach out about interviewing at a non-FAANG company that is private. Being private there are no RSUs on offer but instead some kind of Company Funny Bucks doled out based on "performance" etc. Whatever, all well and good so far. Competitive salary but TC wont be anywhere in the same solar system as some of the FAANG total comps Im aware of for a position of similar level.
Then the kicker comes - I get an email about "interview preparation" and I kid you not it was every bit as intensive as AMZN. Do they really expect me to put up with this hazing for the same money I can go make without it? For Company Funny Bucks (told to expect 10-15% of my salary at best with a whole lot of qualifying "if's" in there indicating this was mostly fiction). Needless to say I performed a quick analysis of the value of my time and opted to politely pass on the interview.
> When there is a cottage industry focused on training people to pass your interview then you have a problem.
Doctors have board exams. Lawyers have bar exams. Financial professionals have their own set of exams. Electrical and mechanical engineers have professional engineer exams.
The difference is that they're standardized, so the prep industry caters to passing those exams more so than passing the interviews.
Software engineering is far from standardized because the subject matter is far too varied, so instead companies handle their own type of exams customized to their needs.
There is also a cottage industry around interview prep for lawyers, doctors, and other professions. It's just not well known because it's extremely expensive relative to spending a couple hundred bucks (if that) on Leetcode. It often takes the form of expensive 1:1 coaching that starts in the hundreds of dollars and can easily enter five figures. Students from wealthy families frequently have private coaches for this.
Yep. I hate interviews as much as everyone else but I'll take grinding Leetcode or Interview Cake for a month or two over having to deal with law school and the bar, for example.
I guess it depends on how often you plan to change jobs. I don't like the idea, and kind of hate the concept of gatekeeping, BUT at this point, I'd be willing to go pass a single "programming bar exam" if it meant I would not have to grind for months before every. damn. time. I. job. hunt.
The problem is nowadays a lot of companies don't reward loyalty. In the US coastal markets, you are hurting yourself by staying at once place for 5+ years (FAANG and some big corps excluded).
This blog post is selling an agenda (as is what i'm about to say :) ), and that agenda is that you should pay Interviewing.io to help you get through interviews.
I think the bigger problem is that technical interviews are broken. I ask everyone to bring their own project to work on, since I hate the traditional tech interview process so much. And it goes incredibly well.
It could be adding a feature to a side project, starting something new, or contributing to open source. (Or, we have some stock ideas if people need inspiration.) Rather than asking them to solve a problem they had never heard of before or use a codebase they're not familiar with, I get so much more out of watching them work in their own environment.
I can ask them questions about why they're doing something, and they tend to have much more detailed answers because they've been thinking about it for weeks. They're solving a problem they care about in a codebase they know, which mimics how working with them will be a few months in.
We could all just buy into this notion that tech interviews suck but we have to deal with them. And then, like SAT Prep classes, there's a whole industry around how to pass them. Or, we can spend more time talking about how there's definitely a better way.
I know this is controversial around here, but I think technical interviews are a fine tool when done well. I interviewed for triplebyte for a year (interviewing about 400 candidates). The triplebyte interview has a series of different parts assessing different skills (live coding, knowledge, debugging, etc). There’s plenty of room for candidates to be weak in some sections of the test but still pass with flying colours.
We had a hypothesis internally that some parts of the interview were redundant. The interview was certainly tweaked over time, but the data science team found otherwise. All scores are positively correlated. And removing any major part of our interview would have made the interview worse. Given all my experience with it, I believe the triplebyte interview to be a fair assessment of candidates, and respectful to everyone involved. (Though I’d be very interested to know how much 5+ practice interviews would move the needle on scores, as this article claims.)
The hardest part of my job was nervous candidates. Stress is designed to help us survive running away from a lion. When we get stressed, we shut down our ability for creative thought and our memory gets weaker - which is literally the opposite of what you want in a job interview. Most of my energy as an interviewer went into helping candidates stay calm throughout the process, and I wasn’t always successful.
I don’t think there’s anything fundamentally wrong with whiteboard interviews. You’re right - we could probably rearrange the professional world to avoid all stressful assessments but I tend to agree with this article. Just do a bunch of them and you’ll get used to them. Being interviewed is just talking for an hour or two with someone smart about something you care about. Usually you get to talk to someone you would have no access to in your daily life. If you can get past your terror of being judged, they can be a lot of fun.
Well, it's easier to say when you're doing the one interviewing, right? I think you'd have a different opinion if you were on the other side of the table for those 400 interviews.
After 400 interviews? I highly doubt it. The discomfort you feel in an interview isn’t part of the interview. It’s something you’re generating and bringing into the room with you.
Anxiety before a job interview (or exam) is your body believing that if you do badly, you might die. It doesn’t take 400 job interviews to notice you don’t actually die. The article suggests it takes about 5 practices. I also liked what they said about the collage experience. Seeing a lot of my fellow students succeed and fail job interviews seemingly randomly probably helped more than I think. It made failing an interview feel like just a normal uncomfortable thing.
Sure, at 400 interviews, you'd get decent. But that's my point! Do you want to hire people who are good at the job, or do you want people who are good at interviewing?
Sure, I want to hire people who are good. But honestly a well designed interview is a pretty good way to find them. You get some false negatives (people who are good, but interviewed poorly because of stress). But I suspect most people I passed on (90%+) were true negatives - they didn’t pass the interview simply because their programming skills aren’t as strong as I’d like to see. And (I hope) most people who struggle with interviews can figure that out with a bit of practice. If it takes you 5 bad interviews before you do a good one (and land the 6th job you apply for), that’s great. Nothing is harmed in the process but your ego, and a bit of time.
Every time there’s an article like this on HN there’s people whinging about the interview process. But for most developers, interviews work fine. I stand by my claim that a well designed interview with a balance of content (see my other comments in this thread) is a fair and accurate way to assess a candidate’s programming skills.
Forget for a minute who won't get through the "broken tech interviews" and instead consider the types of bad hires that could get through these filters:
- Take-home LeetCode: poor communication skills, bad at workflows, unpleasant personality, poor architecture, write-only, cheaters.
- Live LeetCode: same as take-home LeetCode but at least they have communication skills and aren't cheating so you know they can write efficient functions.
- Resume: all the issues with take-home LeetCode.
- Culture fit/behavioral: all the issues of take-home LeetCode, but at least they're good at communication and have a good personality.
- Take-home project: same as take-home Leetcode but instead of efficient functions you know they can at least architect and implement a small, standard application (if they didn't cheat).
- Show me your side project: Same as take-home project, plus they might work extremely slowly, and might only be passionate about that one side project, but you know they have communication skills.
- Architecture whiteboarding: can't actually code to implement the systems they're drawing, but you know they have communication skills.
So it's no surprise that companies wanting to reduce the risk of a costly bad hire (a bad fit, not necessarily a bad person) evaluate the candidate from different angles to check for red flags.
I sympathize with the frustration of those who present false negatives and are filtered out despite actually being a good fit, for example working parents who can't spend a whole weekend polishing a take-home project.
with take-home there's also the fact that the great candidates will probably have an offer before they even get to start working on your take-home, unless you are Google/SpaceX or pays extremely well.
Students sort companies they are interested in in descending order so your take-home will get done whenever they have some time available.
> with take-home there's also the fact that the great candidates will probably have an offer before they even get to start working on your take-home
Are you seeing excessively demanding take-home projects? I've only ever seen take-home challenges in the 1-4 hour range.
On the hiring side, I gave candidates a choice between our take-home problem or an on-site interview. Everyone gladly chose the take-home problem.
I don't understand why so many people are loathe to spend a few hours in the comfort of their home working on a take-home challenge in their preferred dev environment, when the alternative is to take time off work to handle a mid-day interview with a live person.
As much as HN hates take-home problems, I've received near universal approval from candidates on the hiring the side relative to having people do live, in-person tech interviews.
> I've only ever seen take-home challenges in the 1-4 hour range.
For college hiring, that's on top of a busy schedule (and everyone interviews roughly at the same time). So the take-homes add up.
And it's a long time commitment from the candidate but a potentially very short one from the employer (run some automatic grading/testing then ghost the candidate). Going to an on-site and meeting engineers shows more commitment on the employer's side (talking to the candidate is worth 2 hours of an engineer's time).
But if you have a good completion rate for your take-home, that's great.
Problem with take home test is that it’s asymmetric time commitment - candidate spends time but company does not have to. You can send take home test to 100 people competing for 1 open position because take home takes candidate 4 hours to do but only 10 minutes to check by company engineer (or even recruiter or automated tool).
Easy to waste candidate time.
With in person interview time commitment is the same for both company and engineer so no sane company will waste candidates time (at least on purpose). Feels much more fair.
> I won’t name any specific companies here, but tech giants (many with good intentions and with marching orders to boost their diversity numbers) often do a considerable amount of outreach and pre-interview engagement with candidates from underrepresented backgrounds. This outreach is usually an info session where one engineer speaks to a virtual room of candidates from underrepresented backgrounds. The engineer tells them what to expect in technical interviews, encourages them to learn how to articulate their thought process out loud while solving a problem, and recommends resources like Cracking the Coding Interview. Some companies even go so far as to offer their underrepresented candidates a mock interview or two. [...] Unfortunately, for candidates who are unfamiliar with the process, neither of these interventions is nearly enough.
At some point how much hand-holding is enough?
They pretty much told candidates where to get sample problems, gave a session showing what the interview is like, did one mock interview... Pretty much all what prospective applicants have to do is pair up and do a few more practice rounds.
How is it the evil tech company's fault? They gave them the toolbox with all the tools in it and instruction on what to do. And the material to practice building whatever they said they will test them on.
I haven't participated in too many FAANG interviews and even with the recruiter handholding it's still super confusing if you're not familiar with the scene:
What difficulty of questions will be asked? Easy? Hard? Do people actually want to "hear the thinking process" or do they just want an optimum answer regurgitated quickly? Do I need to practice "regular" interview questions also ("What's your greatest weakness?")?
All of this with a life-changing, potential millionaire amount of money at stake, which isn't great for the nerves.
> What difficulty of questions will be asked? Easy? Hard? Do people actually want to "hear the thinking process" or do they just want an optimum answer regurgitated quickly? Do I need to practice "regular" interview questions also ("What's your greatest weakness?")?
Isn't it what they talk about in the outreach session described above?
Some of them do but every interviewer you encounter has their own methodology.
It is exceptional to be at a company and all the interviewers are on the same page about how to interview. This is true even at FAANG where they’re all supposedly trained on how to interview ... but still end up all acting differently.
> What difficulty of questions will be asked? Easy? Hard?
Easy to medium depending on the position or any number of factors. MAYBE hard if you've done really well and solved the questions quickly.
> Do people actually want to "hear the thinking process" or do they just want an optimum answer regurgitated quickly?
Thinking process is far more important than getting the optimum answer. You have to talk your thought process out loud. Think less "find the best answer" and more "gather requirements and optimize within the given time window". It's far better if you treat questions as applicable to real world scenarios where you only care asymptotic complexity as a tool, because you have real resource/network constraints. It is still important to know how to analyze asymptotic complexity. It is not important to get the most optimal answer, but it is important to be able to optimize on the trivial (brute-force) answer which you should always state to begin with. Depending on the interviewer, they'll ask you go further and maybe prod you with hints. It's really really important to communicate and make sure you're solving the right problem and that the interviewer is on board; this is also a skill that you pick up. It also very much applies on-the-job "I did exactly what was asked" is probably the wrong thing to say if you're not taking ownership to clarify the issue and solve the root problem, because that's what's ultimately important. All of this can be learned with practice, and it is 100% expected that you study and practice.
> Do I need to practice "regular" interview questions also ("What's your greatest weakness?")?
Yes, behavioral questions are also important as long as you can pass the technical portion. The idea here is to understand how you would deal with situations. You answer these in a STAR (Situation, Task, Action, Result) or SAR format, and you should have these STAR format answers prepared for any types of questions they would ask. Depending on the company's guiding principles you would formulate your answers to display how you exhibited a particular principle in each of your stories. Don't be humble -- use "I" language rather than "we" language here (I had to practice this). Data based answers are best here ("grew user engagement as measured by replies by X%" vs "grew user base"). Impact is important but unfortunately that's not always within your control. The end-result isn't necessarily important but your learning is (e.g. if the project flopped, what important things did you learn that you'll never make the mistake of repeating again, and how can you pass that knowledge on to your team).
Lastly, these interviews are designed to weed out false positives so even if you're more than qualified luck still plays a part and it can be a numbers game, so keep trying.
This advice is spot-on and generally how I approach things when I'm looking for a job. For the "regular" parts, it's very important to be specific. Don't say you "worked on" something, say exactly what you did. Did you "work" on optimizing performance, or did you dig in with profiling tools to identify expensive or highly used code loops, etc.
I interviewed with Google last summer, and the recruiter personally did all of this (aside from a mock, but did mention interviewing.io) and included a pretty lengthy email with resources. I’m a white male.
Still, the vast majority of applicants aren’t going to pass. It’s not like it’s just some minor brushing up for most - it takes real work and dedication, for some that could do the job well over 100 hours... an infinite amount of time probably won’t be enough for those who can’t.
For most people, not really. You don't study how to solve leetcode questions on a whiteboard during a typical DS & algo class. The more serious and advanced the class, the farther it'll be from interview questions really. And even if you prepared well at some point, how long can you be good at it without regular practice? The day job of a software developer rarely requires reaching for clever algorithms.
Predicting future productivity is hard and there is no magic set of questions that will predict it. It seems tech companies worry too much about the questions they ask rather than interpreting the answers that they were given. The solution seems to be to not worry about it too much and just hire (and fire) liberally.
So wrong because it equates passing the interview with being good at the job. These two things have almost nothing in common.
So right because practicing jumping though artificial hoops is exactly what you need to do to succeed at a large corporate. This skill is orthogonal to contributing actual value.
I went to a bootcamp (one of the more reputable ones at the the at least - they didn't charge the attendees) and it was basically 75% interview prep, 20% working on a project designed for the job search (highest possible ratio of buzzwords/effort) and 5% everything else. If bootcamps aren't doing a good job of interview prep I doubt it's for a lack of trying.
When they started paying well above what startups pay. Ever since FAANG started paying senior engineers $250k+/yr and now closer to $350k+, it quickly became a go to place to work. The TC is unmatched by startups and other firms unless you’re on a rocketship or similar company as FAANG.
After numerous attempts at these software engineer interviews, I added the following disclaimer to my LinkedIn https://www.linkedin.com/in/mtodor/ and cover letters:
"I have a personal policy against any type of live coding or online coding tests during interviews and I don't enjoy or engage in any form of competitive programming. Otherwise, I am happy to work offline on coding assignments with reasonable goals and deadlines and to have in-depth technical discussions about software architecture and design as well as relevant technologies."
I'm still perfectly able to find suitable jobs with good pay as a software engineer and being upfront about the above policy prevents a lot of frustration and wasted time on my side. Yes, I do have to invest a lot more effort into looking for a suitable job, but, then again, I'd very much rather spend my free time doing that than going again through one of these interviews.
PS: I have 14 years of work experience, currently working as a senior engineer / tech lead on cloud infrastructure and this is my 8th job.
Very clever post encouraging companies to spend more on this trite style of interviewing perpetuated by Aline, Gayle and the leetcode gang. Who offers said mock interviews at $100 a pop? Well interviewing.io of course!
I don't buy this explanation. I fall into the category the author is talking about but I'm not in an underrepresented group unless you consider enlisted war time veterans one.
Some background so you understand context: I dropped out in 2009 because I lost the programming job I used to pay the bills. At the time I mostly worked on PHP web apps and did some microcontroller testing for a local business. I joined the military shortly after, served my time, and worked my way from desktop support to network engineering, to "DevOps" (in it's early stages), to being an SRE-SE, to a SWE again over the course of six years. I never did go back to school, I can go into the myriad of reasons that affect the statistics that the DOD and VA will happily show you on the way out the door but don't seem to post publicly, but I think that's for another post. I could not get a job programming again. Logically, no one wanted a programmer four years out of practice, but I quickly learned that big tech has a major shortage of Systems Engineers and an even much more major shortage of Systems Engineers that can write full applications as opposed to scripting.
Large firms tend to focus on one skillset and that is mathematics. The reason for this isn't very illusive, they hire mostly people with mathematics degrees (CS and CE) and interview based on the skillset they know best. The problem is that the people who dominate this group know nothing to very little about systems. I have been on countless interview panels and often I find that people will pass abstract systems design but when you make them directly apply this theoretical knowledge to an OS they will fall flat on their faces. Ask them questions about network sizing and you'll get networks that are incredibly huge or don't make sense at all.
The problem is that the reverse is true too, when you take a Systems Engineer who could walk you through kernel process scheduling, the order of operations in calling execve on a binary, etc they often struggle in algorithm application. They may pass your algorithm test if it is pretty plain to see what algorithm needs to be applied and it requires pretty straight forward implementation but if you tweak the process a bit, they fall flat on their faces. This doesn't disambiguate from Systems Engineers that can't code, I'm purposefully excluding these folks because we're talking about variants of programmers. I have spent years trying to get myself up to the level that college graduates have with algorithm recognition and application.
I'll stop here and say if you find yourself in the same boat, frustrated and upset over interviews, I see you. Cracking the Coding Interview and Leetcode are okay for practice, but if you're struggling to identify less-common data structures and algorithms or how they relate to one another there are two books that helped me infinitely: Introduction to Algorithms by Cormen, Leiserson, Rivest, and Stein and Algorithm Design by Skiena. Python and Java are good for playing with most of these. It took me about two years to get up to par with college graduates.
What people from bootcamps struggle with, in my experience, is the same thing that systems engineers who can code struggle with. Algorithm recognition, selection, and application skills are not on par with that of a newly minted mathematician.
Do you want to solve this? Teach. I teach programmers about systems all the time, mainly because if programmers want to learn about systems there's a myriad of books like The Linux Programming Interface to Linux Kernel Development that are all very indicative of how nix systems and kernels work. These assume a pretty cushiony set of knowledge to begin with, so their foundational knowledge has to be increased first. Unfortunately, there's not a lot of material on the internet for this beyond shallow tutorials on Linux and Unix commands, some StackOverflow answers, etc that will inevitably guide a trainee ...
This article (whether we like the current practises or not) highlights the value of practice. What is interesting is the (anecdotal) trend of "reverse abuse"? I know several folks who routinely take time out of their schedule each month to go through one or two interviews with real companies just to not get rusty. This way when the faang time comes they are ready and don't have to block out 2-3 months leetcoding again. Clearly if you cannot beat them take advantage of them!
225 comments
[ 2.3 ms ] story [ 242 ms ] threadMy past experiences have been terrible, not a single person who interviewed me wanted to know what I worked on or what I have achieved or how I solved a given problem. Few introductory questions and jump into coding questions. Some of them are medium and few of them were hard. But at most I was able to find a way to solve(not completely code a solution).
It seems lot easier when you are in college and are surround by students who are practicing coding interviews. You can talk, discuss and gain more experience. I don't know how I can do that, when I'm busy maintaining and coding for my current job. Its just so demotivating.
Curious: what did you switch to?
That does probably depend on whether you're doing greenfield work or not, but even then these costs are there but just not immediately visible.
There's a lot luck involved because there are so many candidates, most of whom cannot come up with an approach to solve a problem (let alone to solve it well enough to serve billions of users well). So even most candidates who are qualified can't convincingly demonstrate that given the time constraints and pressure etc.
It is hard to get into FANG for college new grads, it is even harder if you're trying to break into the tech industry from outside without the schedule flexibility and focused community support of a top tier university. It is possible but you need a combination of high ability, strong drive, and luck.
At my FANG, we've made some interviewing changes over the past 5 years such that these days you'd spend at least 20% of your day interviewing talking about what you worked on and achieved and how you solved problems, whereas in the past it would be entirely at your interviewer's discretion and typically only be a few minutes of unscored small talk.
FANG is an interesting life experience and it pays well, but plenty of people find it is not all it is cracked up to be. Just as in every job, a lot depends on the particular people you work with and whether you enjoy the particular problems you are solving. So maybe also consider whether you really need to go FANG (right now) or whether you could be just as happy at a place that's willing to take a more individual approach on hiring. That place could even be a stepping stone to reach FANG later on if that's what you want to do later.
You can either dedicate the time and practice, or decide you don't want to do it since your situation does not enable you to do so (e.g. due to kids, family, or simply lack of motivation).
Of course, there are people who do not have to study. It seems you are not one of them. (Neither am I to be honest, this is just an observation, not an offensive remark). What else is there to do other than studying or not passing the interview in such a case?
Furthermore, the process is partly about how good you are at being able to learn, and partly about how well you are able to keep yourself motivated to grind something out, or a combination of the two. Given enough time, FAANG interviews are 100% something you can study for, and furthermore, it is expected that you spend the time to study for them as that is also a signal of something in itself.
On the job, you'll either have to be smart enough to pick stuff up quickly or spend the time to grind out the work (working overtime, etc). You also can't fuck things up too much because the fallout can be really expensive, so it helps to be able to do things right the first time. I think what is generally tested in the interview correlates with these requirements, and prevents false positives (and probably lots of false negatives too but you can just study more and try again at that point).
I'm not denying they are primarily focused on preventing false positives, but not for the reason you mentioned.
There's always a tradeoff between security/bureaucracy and speed in delivery so as to remain competitive. This does matter even at large scale.
I would agree that if one were purposefully trying to cause as much damage as possible, that impact would be contained by these processes.
But one can still make mistakes or be a drain on the team's energy and focus which increases the chance of mistakes team-wide. At scale, even minor mistakes are costly, not just in terms of direct impact but in terms of the opportunity-cost of developer effort that could be better spent elsewhere.
Of course, my direct knowledge has sample size of n=1 here so it likely does not apply uniformly across all large companies.
I would love to hear contrasting opinions on this topic. I've spent a lot of time thinking about what would help developer teams increase their productivity w/ regards to adding value.
I am oversimplifying it, but the same forces that created the FAANGs can allow you to avoid them and companies like them, avoid SV. The world has become more evenly distributed in some ways, but HN and channels like it can make you think you have to pass through these certain gates.
Everything in life is a game. You can choose to learn the rules, and play to win it, or you can call foul and take what's given to you easily.
Either one is valid. But don't act entitled to the gold medal if you choose to prioritize other things over practice.
One interesting thing though is that from a market perspective, it still ends up making sense for our org (ML research lab). There are simply so many applicants, that we can afford to pass on anyone. All the candidates hired tend to still be excellent on all other fronts AND they can do these quizzes. And it does result in some hires not being the most credentialed ones with the longest CVs but the ones who outperformed during the interview for whatever reasons.
So..I can see it makes sense for the most prestigious orgs, but I still hate it, and I especially do not see why startups who are struggling to hire feel the need to copy this when they clearly do not have the same options.
Another thing that really irritates me when people in hiring committees actually pretend passing them means something about candidates' innate skill. Like, I get it, these are the rules we made up, but do we have to pretend they are that meaningful?
With enough push back, I do think it's possible that those in charge of hiring in the world might reconsider how valuable leetcode tests are to judging potential employees.
I'd be happy to hear alternative approaches to conducting a technical interview, but no one presents any. There are 100 comments in this topic and hardly any discussion of what a good hiring process would look like.
You can really leave a lot of money on the table with this attitude of "oh well, I dodged a bullet, if the interview was hard then the job is probably bad and the whole company too."
I'm not quite there, but if I leave money on the table to avoid a place that treats people in an abusive way, I'm okay with that. I don't need the extra money that badly - it's too expensive.
It breaks my heart a little to say this but the earlier they pick a different career path, the better their lives will be.
I suspect a lot of people who complain about technical interviews do so as cover for struggling to be good enough at programming to be hireable. I think we need to take the stigma away from that - its ok to find programming hard. Honestly, that makes you a more normal person. It doesn't say anything about your work ethic or your value as a human. And its not a failure to choose another career.
With interviews - my claim is this: A well designed interview has a high statistical correlation between passing the interview and being useful on the job. Eg when I was interviewing we gave candidates some buggy code (with failing tests) and asked them to find and fix the problems. The ability to debug unfamiliar code in a job interview is correlated with the ability to do the same thing at work.
If you can’t read code, I don’t want to employ you. Please practice and reapply, or find work elsewhere. This is a reasonable position - and probably the only reasonable position for an employer to hold.
There’s lots of skills other than debugging: coding, profiling, algorithmic analysis, CS fundamentals, architecture, communicating with coworkers, etc. A mediocre interview assesses 1 of these skills. A good interview assesses 5+.
Are there bad interviews out there? Yes, lots. But interviews themselves - even badly designed ones - aren’t abusive. (Unless you think a rejection is abuse).
I get that some people put themselves through leetcode practice hell to get a job because they’re unemployable otherwise. I have sympathy for this but I don’t think this is the fault of the interview process. I suspect any decent assessment process would have the same result - where some people need to improve before they can get hired.
> If you can’t read code, I don’t want to employ you. Please practice and reapply, or find work elsewhere. This is a reasonable position - and probably the only reasonable position for an employer to hold.
> There’s lots of skills other than debugging: coding, profiling, algorithmic analysis, CS fundamentals, architecture, communicating with coworkers, etc. A mediocre interview assesses 1 of these skills. A good interview assesses 5+.
I agree with every bit of that. I'd be happy to interview at your place, if I were looking. My objection isn't even just to interviews that ask you random stuff that doesn't correlate with being useful on the job. My objection is to interviews that ask you random stuff that doesn't correlate with being useful on the job and that requires months of your time to prepare for. I think that's abusive.
I don't prepare for interviews. I just don't. My preparation is the 35 years of my career. Either that made me into someone you want, or it didn't. Sure, I'll take on your buggy code and failing tests, in an unfamiliar code base. No problem. But if an interviewer throw a bunch of leetcode questions at me, I'll fail (by the interviewer's standards). And I don't care. I'll go work for someone else.
Great. The natural result of a poorly designed job interview should be missing out on good candidates. Thankyou for giving those companies an incentive to improve their processes - by missing out on you.
You complain about studying unpaid, but who gets paid to study? Many pay tens or hundreds of thousands to study law, medicine, business, etc., and it takes years. Spending a couple months studying algorithms may not be easy, the process certainly isn’t perfect, but calling it abusive is really a stretch.
What it comes down to in my opinion is that these jobs are ultimately not really that different, except for how they pay. (Put another way, the main difference between jobs I've had in my career is how much they paid. The other stuff was basically the same; pay radically different.)
And if we're at the point of working tech jobs then guess what, Mr Agassiz, we're already wasting our time. The way we waste less of our time is by making our money and getting the hell out. So we can waste our time however we like.
But if you like, you can instead console yourself with, wow my boss is such a nice guy or whatever
Do executives have to demonstrate their knowledge of acquisitions or something similar?
Also let’s not act like this only applies to FAANG. Every dev job from internships and 50k entry level positions and up require the same testing. How many 70k/year jobs require testing every time you change positions outside of tech? Very few. Law, some medical fields, and a few other highly skilled fields do require licensing, but you only do that once per state at most.
Tech is the only field I’ve ever seen where your experience doesn’t matter and you have to prove your skills with every interview. In other industries, it’s mostly about personality.
This sounds like a good thing to me (for tech). The interview process may suck, but at least everybody has to endure it. And then you're in a meritocracy. That's the theory, anyway.
Not sure how serious you're being but the answer is yes, surgeons seeking to change from hospital A to hospital B have interviews where a surgeon from hospital B will visit hospital A to supervise a surgery or other operation. Depending on how critical the position it may even be a partner from one hospital doing the supervision. In fact nowadays the supervision can be done remotely.
Furthermore surgeons are required to maintain their accreditation by earning credits on a yearly basis through continuing education and/or training and they do so on their own time.
These guys don't mess around and if you think surgeons get hired because of their wonderful personality then you sorely underestimate the medical profession (and overestimate their personality ;P ). It's incredibly competitive, demanding, and prestigious in almost every sense imaginable.
The comparison would be more direct if the surgeon was asked to operate on a dummy using a kitchen knife in front of the interviewer.
Then there's the problem that there's no way in hell a software company is going to let another company watch their employee work on proprietary code.
In comparison, software has no equivalent credentials. Universities, collages and bootcamps have no incentive to fail anyone. As a result plenty of weak students pass - only to discover that they’re largely unemployable. This does a disservice to lots of people - companies can’t trust degrees, and need expensive interviews. Good candidates have no way to reliably demonstrate their strengths. And weak students waste tens or hundreds of thousands of dollars and years of their lives failing to learn to code.
But the benefit of our system is that we allow programmers to be self taught. If you can’t afford to go to collage, or you are from a poor country, or you just don’t like school, that’s no barrier. You can learn programming in your own time and still get a great job. There’s lots of great programmers with the aptitude to become lawyers or doctors - but who would never be able to get the piece of paper they need to get those jobs. That’s something we as an industry should be proud of.
Most well-credentialed people would.
Most under-credentialed people are thankful for skills-based testing because it levels the playing field.
I'd like a way to prove my skills once, rather than with every interview I have. I bet CS grads would as well. The interview process is just so... tedious. And in a field where you get significantly more money by changing jobs, that's a problem.
It's a market inefficiency imo - people get stuck in jobs where they aren't paid enough for at least some amount of time. People can't hire new employees quickly because the process takes forever. I've been on both sides of the interview process many times and it's extremely inefficient on both sides. We're developers... this should be streamlined and automated.
Most surgical procedures are mostly the same regardless of which hospital they're performed at. It's not like software engineering where the tasks and difficulty vary greatly from company to company.
A surgeon's record at one hospital is their interview for the next job. So yes, every surgery they perform is, in essence, contributing to their interview for any future jobs.
And even that wouldn't be comparable, since they'd be observed on something they actually do every day as part of their real job.
In software the interview drills are about thing nobody ever does as part of the real job, so one won't have any recent experience doing algorithm tricks.
Plenty of easier process exist but they are not jobs you can apply for. A baseball special assistant hired by an owner can be hired after drinks.
In terms of regular jobs a sales staff working on commission could be easier.
Tech hires quickly and frequently for the short-term. The algorithms test approach is intended to condense what would be a much more expansive investigation into something straightforward (and supposedly quantifiable.) This discards a significant amount of information which is considered in other high-end jobs.
I can understand the arguments for many of those, but... uh... somehow you're going to need to prove yourself. We can't just throw everyone who shows up into the position to see how they'd do... and the HN gestalt would presumably complain about how awful that is, too.
You could just, like, ask me! Talk to me like a human being. You'll quickly see I'm all the things I claim to be on my resume. /s
Eg: "Tell me what happens when you type an address into your browser bar"
Someone junior might say "You type in the address, it fetches HTML from their server, and your browser shows it" -- "go deeper" -- "Their server uses HTTP or something.." etc..
Someone senior might get to something like "Well when you press the first 'w' key it triggers a hardware interrupt ..." or more likely something about TCP/IP and the rest of the network stack...
you get a very interesting range of answers
A doctor can do a whole lot more damage than the vast majority of software engineers, and yet doctors don't have to start this proving process from the ground up every job change.
The mindset during consulting recruiting seems to be more of "we want to make sure you have a decent base level of knowledge and problem solving skills, but if you don't know how to code/make a PPT/whatever, that's fine, because we can teach you that stuff". Big tech recruiting seems to be the opposite: even when big tech companies claim "you don't need to know everything, because we'll teach you", they still require you to jump through these leetcode-style hoops to prove your skills.
And this is echoed beyond the hiring process too, in my experience. Consulting companies hire smart people and want to keep them for a long time, so they invest a lot of money into training those people and attempting to keep attrition down. FAANG on the other hand seems to care less about attrition (sometimes even embracing it, eg Amazon) and wants to hire people that require minimal training, and thus wants people that have immediately demonstrable knowledge so they can be immediately productive.
What type of consulting are you talking about, and are these jobs really paying >$250k? What would someone have to do to get a shot at one of these jobs?
I suppose Big Tech could do something similar (skip leetcode stuff for people who have credentials such as prior experience at top tech firms and/or tangible research experience at top research institutions) but I suspect that would not go over well with most people that have issues with the current hiring processes.
That’s why they are failing. Broken hiring processes. Big Tech is eating their fruits.
Maybe the bar is higher in the US.
More high end opportunities than other career paths certainly, but it's much less top heavy. 7 figure income, a few CEOs make it but not common.
Kind of make sense though if local offices adopt some of the same rhetoric and marketing (elite selectivity etc) as the US head offices but with really different market conditions.
Interviews are significantly easier as far as prep time goes for doctors & psychologists.
BUT, you don't have to go through the entire med school & residency rigamarole as a software engineer either, so as far as total effort goes FANG is probably easier. I posit that software engineering is probably the most egalitarian method of socioeconomic mobility, because the only real barrier is time, a laptop, the internet and motivation, while all the other methods require an upper-middle class background and expensive schooling (law, medicine, finance) or just plain luck (business, celebrity art & sports)
But being an interviewer in FANG, I've actually found it rare to find the self taught type in practice. But we do leave that door open unlike medicine.
If Software Engineers want to get rid of algorithmic interviews, all they have to do is come up with a professional exam and a strict licensing body... just like most professions carrying a tittle (MD, Lawyers...).
But as long as "3 months js bootcamp grad" can advertise himself as a software engineer just as much as a guy from Stanford CS then we'll keep having these interviews.
The fact that a bootcamp grad can compete for the same software engineering jobs as a Stanford CS grad is one of the very best parts of the hiring process in our industry. Are you proposing that we start using credentials as gatekeeping?
But it has this side effect that you need to test every candidates.
> Are you proposing that we start using credentials as gatekeeping?
No. As a fast-track sure. So you don't have to start every interview with a FizzBuzz [0].
[0] https://blog.codinghorror.com/why-cant-programmers-program/
But we already do use credentials as gatekeeping. There's a lot of talk about bootcamps and whatnot, but how many of these people actually get passed the resume screen when compared to a Stanford CS grad? FAANGs famously recruit from same 20 universities, and then complain about "lowering the bar" if they branch out anywhere else.
We could stop gatekeeping, but it still happens.
At some point there's a signal to noise ratio issue here as well.
If companies are passing on specific pockets, it’s likely from a belief that the conversion from top of funnel to successful hire is low.
There’s plenty of excuses for gatekeeping, but the real reason is laziness. Of course, we don’t call it that, we call it a meritocracy and apply our biases as “common knowledge”, “proven”, or if we’re feeling particularly full of ourselves, a “sufficient statistic”, but never what it is: a bias, a blanket assumption, a gate.
As soon as you’re relying on assumptions, it’s not a meritocracy. It’s bias promotion, ie gatekeeping.
I have these I have used "challenging" algorithmic stuff a handful of times in my careerer. Same with recursion, I have used it, but not too many times.
If I do hackerrank or leetcode or something similar these days, it's pretty much luck if I will get it. If I sat down long enough I could work it out, but with a 2 hour time limit, its usually 50/50 whether the answer appears in my head in that time frame.
And here's the thing. I write a lot better code than I used to. I know what is important, and it isn't clever algorithms, it's choosing the right abstraction, and keeping things maintainable. Making the code easy for the next developer to follow. For the vast majority of software roles out there this will be so much more valuable than algorithmic knowledge. Sure knowledge of computer science fundamentals is important, but I think we give it too much emphasis over what really counts.
Basically these are testing for a computer scientist when the job is for a software engineer.
It would be interesting to look at the correlations between the two, as I'm not sure if that's every been done.
Treating engineering as an undifferentiated commodity measured by leetcode performance is partly why this charade exists.
I'd estimate (from browsing graduate boards) it's probably among the top 5 most hated aspects of the industry. #1 for many - because it's so anxiety inducing.
If small companies weren't able to use inexperienced developers to spin up half-assed MVPs, we'd be at the mercy of whatever large companies are interested in developing, and time has shown that as companies get bigger, they lose interest in niches in favor of products that will be massive successes.
You're not wrong, but I also don't think the world you are describing is a problem.
That's an interesting perspective. I would say there is some truth in it, but a lot of small companies get plenty of investment money.
There seems to be some kind of inherent or cultural distrust amongst tech interviewing, where nobody trusts that anyone has tech skills unless they personally verify it. I don't think a professional exam/certification would solve this distrust.
Or maybe that was just an urban legend...
Nope, not at all. Despite their rigorous hiring process, even the FAANGs have bad hires, burn outs, or people who simply can't keep up with the pace. Some FAANGs require an interview loop even for internal transfers to guard against a bad hire.
The problem with the algorithm/leetcode style is that you can run it at a very high bar and you end up selecting people extremely skilled at that one thing, but which has very little to none correlation with shipping reliable & maintainable production code.
I've never needed to hire (and surely never will) people who can reverse binary trees with a hand tied behind their back, so that style of interview is not a meaningful signal.
It would be nice to have something like this completely divorced from a recruiting engine though.
Perhaps other parts of my profile were unappealing, perhaps I applied to the wrong positions, or perhaps Triplebyte doesn't have many contacts outside of California. Whatever the reason, I was not impressed with the results. Their entire business is designed for people like me and it achieved nothing.
Do with my anecdote what you will.
I can understand distaste about having a time imbalance (ie. a candidate is not investing the same # of ours as our staff), but like I said, this is a one and done thing and can be used w/ a way to cut down time working with any other companies using the platform.
For us it means going directly to the final rounds, whether they took it at our suggestion, for another company, or just did it for themselves. If they do it for us and they don't end up with an offer, they are not left empty-handed from the process.
In sum, it moves toward some sort of accreditation system, that’s the reason I mentioned it. It's a shame my comment is at the bottom of the pile as I too would love a future where the only time spent interviewing is just a couple hours getting to know my future teammates, and I truly feel platforms like this may eventually get us there.
All the same I'd appreciate feedback on why they're disliked. I've seen them mentioned in other HN threads without any vitriol.
The system encourages the default distrust of developers resumes. That most of them out there are lying, and we need a test to be sure that they can actually code. How many people have actually hired the mythical devloper that can talk well in an interview and not code?
If you're doing work that benefits the company that is another matter, but that's not what's happening here (or anywhere I've ever worked) and is ethically dubious regardless. That's not the point of an interview. I can't believe I'm having to explain this.
You don't pay a dev for their time during the interview process for the same reason no one pays anyone for their time to interview in any industry.
To hire straight off a resume is beyond wild. I'm in the process of hiring a dozen developers for my team, and have had 3 people who had great resumes fail a basic pairing session - they couldn't code. In the 24 years I've been in this industry, probably had at least a few dozen encounters like this. Sure, 90% of the time this isn't true, but it's true enough that it's insane to do it.
"How many people have actually hired the mythical devloper that can talk well in an interview and not code?" I actually have. Twice. Earlier in my career when I believed these sorts of things. And was on hook for cleaning up the mess. Never again. The harm to the team's morale is not worth it.
By the time the exam is designed - not complete, designed - it will be obsolete. By the time the exam is completed, there will be 3 new languages invented.
This would be like changing what animal you have to study as a doctor every six months for the test.
The library and framework of the week is not fundamental experience.
I always advocate computer science training really needs more history of the discipline. So many new languages and libraries turn out to be a rediscovery of ideas thoroughly explored in decades prior, just that the creator didn't know.
An orthopedic surgeon gets new types of tools and implants in their toolbox through their career, but the structure of the bones they operate on is the same forever. It's the same with software.
https://www.computer.org/education/bodies-of-knowledge/softw...
https://www.computer.org/product/education/professional-soft...
That said, it's much harder to get your foot in the door without a degree, even in the Bay Area. I had to go above-and-beyond to get my first job at a small startup (I created a program that used their API and was useful enough that I ended up continuing the work when they hired me). With my second job at Dropbox, the recruiter told me that they only reason they interviewed me was because I went to Recurse Center (which is a free programming retreat for programmers that also acts as a recruiting firm). Multiple companies have grilled me during interviews about why I dropped out, including Google.
As much as we all hate the tech interview process, it's a relatively level playing field as far as hiring goes. It's not perfect, of course, but we have to select on something.
As engineers we have a level of free access to study tools and material that my friends in other professions envy.
The alternative to skills testing is to rely more on credentials, references, and background. People who come from elite universities or lucked into prestigious jobs early in their career tend to prefer this type of interview process because it benefits them the most while excluding those who are trying to break into the industry.
The benefit of skills-based testing, however imperfect, is that it opens the door for people who have skills but not the right background or credentials to skip through the ranks and get a foot in the door.
I am not sure that is true at all. People with family or basically any commitments outside of work don't have anywhere near as much time to practice for this sort of thing and why should they need to practice for an interview? You do the job every day, if that isn't enough then the interview is clearly testing for the wrong thing.
However as someone without a CS degree who is nonetheless able to get jobs as a software engineer because there isn't a process of credentialing, I am glad much of the industry works the way it does.
I've done this rodeo in my thirties and forties, complete with a very busy existing job, family, long commute, etc. The bottom line is that the time investment wasn't terribly large as it was more refreshing than learning things from scratch.
Putting the 20 hours in over a couple weeks for a 2x raise felt like a worthwhile expenditure of my free time, and worth prioritizing over some of my every day commitments.
The key difference between our professional experiences is that the legal profession is self-regulating, whereas software devs/qa/pms are totally socially atomized.
Lawyers have their own organizations, which give them some independence from their clients. Society accepts that this is desirable for the maintenance of the legal order.
Software occupations should move in this direction, for the good of practitioners (wages, working conditions, fairness in promotions and hiring) and the wider society (complement to government regulation around security, privacy, fairness in hiring and promotion).
The bar association defines the examination that lawyers must pass to practice. Employer/client interviews focus more on "culture fit" and familiarity with specific practice areas than on certifying basic competence. The bar also administers "continuing education" to ensure that a lawyer who passed the bar decades ago isn't totally out of the loop on recent developments.
I would love to see the software sector move toward this kind of self-regulation through unionization. We have the power, we just need to coordinate.
Instead of a high-stakes and all-too-often arbitrary interview every single time you want to change jobs, you could prove your basic competence to practice through an exam, and elect to fulfill your continuing education requirements however makes sense for you, within a framework decided upon by workers themselves.
Such a system would not be perfect. No set of examinations is ever going to perfectly capture ever-shifting real world requirements, for example. But we can hardly do worse that the sector is doing now.
We have to stop letting recruiters (i.e. middlemen) and employers (i.e. counter-parties in the employment relation) dictate terms to software workers arbitrarily. The wider society should support tech worker organization in unions because these organizations would provide a check on executive and investor power. Without such checks and balances, we can only expect more of the same short-term thinking and ethical corner cutting.
I'm an immigrant who finished a pure-math PhD and went into software engineering afterwards by building up a portfolio and leetcoding in my spare time. With your system there is no chance I could have done that. Passing all of the exams would not have been possible without a strictly CS education, and I couldn't have studied for the exams after my PhD finished because my visa status at the time was tied to being actively employed.
So many people nowadays are becoming productive software engineers from slightly unconventional backgrounds (pure math, physics, boot camps) and this would stop immediately if CS certification became part of the job requirements.
Barriers to entry exist today, and will always exist in some form. The question is who gets to define them. I am arguing that the workers themselves should have more of a say than they do at present.
One union certification could literally be passing some randomly selected leetcode problems. Ideally, there would be a variety of certifications to reflect the variety of niches in software (someone doing TLA+ for embedded applications shouldn't need to know anything about web app architecture, necessarily).
The difference is that you wouldn't have to do it for every new employer, and workers would have more say in defining the body of knowledge considered relevant.
I don't think anyone would advocate for university credentials to be a hard requirement. I personally have no relevant university credentials except some math courses from a community college.
That said, I think it would be fine for someone to submit a transcript from a CS degree to be certified for basic algorithms knowledge in lieu of sitting an exam on that topic.
> Instead of a high-stakes and all-too-often arbitrary interview every single time you want to change jobs, you could prove your basic competence to practice through an exam, and elect to fulfill your continuing education requirements however makes sense for you, within a framework decided upon by workers themselves.
with how the barriers to medicine/law actually work. A single Amazon interview is not particularly high-stakes - if you bomb it you have a dozen+ companies that can offer similiar comp, and you can always re-interview after a year.
If you bomb the LSAT, or the MCAT, or STEP 1, you will effectively be branded for life. All your future applications to school/residency will include this information. How is emulating that going to get us closer to your stated goals?
I don't think this is true. I've heard anecdotally of people bombing the LSAT/MCAT, retaking, and entering elite universities.
But in any case, the analogy is not with exams to _enter_ post-secondary school training, but with exams to certify vocational skills _after_ such training and/or real world experience (e.g the bar exam, the F.E./P.E. in engineering, "masterpiece" evaluations in the skilled trades).
Private enterprises like TripleByte/codility try to perform a certification function of the kind I want to see workers handle through their unions. In fact, it might make sense for a union to simply contract with TripleByte/leetcode/codility to implement examinations. TripleByte has no real incentive to make its examinations a single-shot affair. Why would a worker controlled equivalent have such an incentive? There might even be a perverse incentive to encourage people to take the exam multiple times (as, for instance, the College Board does) that would have to be guarded against.
I think what needs to be considered with this is three things:
1. Tiered credentialing & scope of credentials
2. On-boarding / grand-parenting those who are already practicing
3. Studies on what interviewing in non-software related technical fields looks like. I see lots of anecdotes (probably data now) on what software interviewing is like, but mech / civil / elec, actuary, etc. interviewing isn’t something I’ve seen discussed as openly.
I hope I’m not misrepresenting or coming across as negative here or in what follows.
- - -
1. The F.E. and P.E. exams seem to be aimed at people with engineering degrees, so it’s the interaction of both education and practical experience being certified.
For the F.E. exams from [1], “It is designed for recent graduates and students who are close to finishing an undergraduate engineering degree from an EAC/ABET-accredited program.”
For the P.E. exam from [2], “It is designed for engineers who have gained a minimum of four years’ post-college work experience in their chosen engineering discipline.”
Even after passing those exams, there is still annual education and training requirements to maintain certification. Yes, it’s not nearly as rigorous as whiteboard coding that people are currently subjected to, but it’s not a one time activity either.
In both cases there is emphasis on college.
I’m Canadian and it’s pretty similar for P.Eng. There are some exceptions, but they do require a college education.
This leads to tiered credentialing in the Canadian system. There are:
- technicians (1 year education) - technologists (2 years of education) - engineers (4+ years of education)
There is a defined scope of work for each of these professionals. To move up the tier requires education, exams, and apprenticeship. To switch between specialties, I’m not sure if it’s possible.
Not everyone in the engineering profession needs to be an engineer. It is entirely okay to have tiers. However, tiers become very restrictive and could be perceived as gatekeeping, among other things.
2. I think there will have to be a dividing line of some sort to keep those who have valuable experience without an CS education in the field.
Something like: All people who can prove work experience and practical experience are under this one assessment and credentialing method. All others after follow a different credential evaluation method. Or the tiers allow math, physics, self-taught, etc. to be credentialed as such.
3. Technologist interview anecdote. When I was interviewing as a manufacturing engineering technologist the assessment has been:
- read a shop drawing and tell me what these symbols mean
- jump on a computer and start producing a 3D model in the software used by the company. Produce a 2d shop drawing from that model
- explain how you would come up with an inspection plan to show the product has been manufactured correctly
- solve statistics problems. Set up a control chart. Interpret what the points mean and explain the next steps. Design an experiment. Tell me the hypotheses, tell me how you would calculate sample size, how do you know that’s a good sample size?
- go on the shop floor be handed an inspection sheet and inspection tools. Check if this part conforms to standard
- whiteboard ladder logic for PLC
- handed some print outs of CNC code and asked to explain what the lines meant
Those are technical questions I’ve been asked in a series of interviews for manufacturing technologist jobs. It’s not one 8 hour day of interviews like some tech companies. It’s usually 2-3 sessions x 2-4 hours each session. That line of technical questioning is not a substitute for education. It’s on top of having education and certification in the field.
My point is I don’t think software is uni...
Part of it is things like the MCAT and organic chemistry are hard, part of it is there's a whole "hidden" component of med school applications related to volunteering, shadowing, research etc, that is opaque to most. This is part of the reason 50% of med school students already have a parent working in medicine.
[0] https://www.aamc.org/system/files/2020-10/2020_FACTS_Table_A...
I don't understand how anyone can think that 7 or more years of med school and grueling residency is somehow easier than studying Leetcode for a few weeks or months.
Med school has a very different selection bias than FAANG interviews. No one seriously attempts to attend medical school unless they've committed to 7 years of grueling training. A FAANG interview, on the other hand, is barely a blip on the radar over the course of an engineering career. A lot of people apply to FAANG jobs just to try their chances at the application process. Not so for medical school.
It's obviously easier if done only once.
But doctors go through education & residency once and then start their careers.
Software engineers need to repeat this every job change for no reason.
I'm not sure if the chances of success are any higher for getting into a medical school in the US. As a one-shot thing, a FAANG interview loop may be tougher, but there are a lot of big tech companies and you can keep trying your luck. I think Amazon alone has like 50K software engineers, they churn engineers like crazy and the hiring bar isn't quite as high as some of the others. Whereas if your undergraduate credentials aren't good enough or you simply don't do well on standardized exams, you're kind of out of luck in terms of getting into a US medical school. I could be overestimating the difficulty of getting into the least competitive medical school in the US, but my understanding is that they are all pretty difficult, leading many people to go to a medical school in the Caribbean.
I sure don’t think leetcode interviews are great, but I’ll take it compared to that.
Doctors in particular (with residency) and lawers to a lesser degree (bar exams) have a more difficult path into the profession. But they don't have to prep and go through the bar exam for every single interview after that.
It would be unthinkable to make an established surgeon balance chemical reaction equations or something obscure like that from their undergrad days as part of the interview! But that's what software engineers must deal with.
Getting that license is significantly harder, though
In general, companies with more money than they know what to do with can offer increasingly larger wages to make people jump through arbitrary hoops. I know people get frustrated with this, but it's really the rational thing to do.
When you consider the expected value, siphoning up 10 to 25% of your employers time to practice leetcode at work will benefit you more than doing most things at work.
Mostly because when I was interviewed the company liked me enough to skip half the process, including their code challenge stuff.
Didn't have to do a code test or defend my code or anything like that.
I'm building a developer screens sharing app that, among other things, automates non-whiteboard interviews. Typically we can review a 60 minute take-home in 10 minutes, without cloning the repo. http://paircast.io
If you're an engineering manager that wants to move away from the leetcode challenges, please get in touch with me. ian@haxor.sh
Also see http://they.whiteboarded.me/
So a candidate a invests 60 minutes of their time and a multi million dollar company invests 10 minutes.
We should all boycott these asymmetrical "take home" tests.
If you put a grand prize out there, lots of people are motivated to go after it, including the ultra-long shots.
On of my favorite interviews was for Acclaim in the mid-90s. Take home (download a zip file with a skeleton app, read the code, write the strategy element that’s stubbed out). I don’t recall how much time they allowed but it was at least 24 hours. Mine was “navigate an airplane from left of screen to right of screen against a fixed set of blocked squares[mountains]”
Probably spent a little over an hour on it, enjoyed doing it, and remember it 25 years later. They can score such a test (at least initially) totally mechanically, weeding out the “couldn’t get anything to work” subset of the population in zero minutes of engineer time per new application. It tests something quite close to what you’d do as a game programmer for them. You can do it at home, at your own pace, in your normal environment. If you pass, then you might have to get an airplane and travel to interview, which is a multi-day disruption to your life.
I’m on the employer side now; I see the value in asymmetric tests at the initial filtering stage for entry-level, because I don’t see any workable alternatives that don’t introduce other, likely worse, forms of credential-checking.
I’m sure we miss some good candidates this way; false negatives are bad but less costly than false positives.
250k+ jobs just have whiteboarding. Google, facebook, amazon ect don't have take homes.
I've seen take homes mostly from smaller shops. Netflix might be an exception in the FAANGs with take homes
> because I don’t see any workable alternatives that don’t introduce other, likely worse, forms of credential-checking.
what do you think of compensating candidates for their time?
What do you think of asking applicants to compensate the company for the time spent reviewing their application? (Many colleges have application fees as an analog.) I would be opposed to this type of friction-introduction as well.
Applicants cover their costs (including time) and company covers their costs (including time) seems to be working reasonably and gives both actors choice about how to balance their inputs and expected returns. If either side demands too much, the market moves away from them.
Literally this. You can pretty much do all of the interviews required for FANG without talking to a human being, which from the FANG perspective, is absolutely GREAT, because it takes all of the existing social biases (e.g preferring a certain race, preferring a certain gender, etc.) out of the window and focuses ONLY on the algorithmic knowledge of the applicant.
Of course, there might be some interview here and there about soft questions, but for the most part, they don't really give a shit about that, and it's unlikely that you'd be rejected based on that, unless you _really_ suck at bull-shitting success/failure stories (which I am - can't stand doing it).
I think the last time I applied to Amazon (over a year ago at this point) I didn't even get phone screened. It was just a link to 2 graph algorithm problems that were the equivalent of a medium difficultly on Leetcode, and I was immediately graded. It's so fricking easy for FANG nowadays.
When your doing whiteboard interviews the interviewer is there the entire time interacting with you, so it's taking up 1.5hrs of engineer time at least for every 1hr interacting with the interviewee. Reviewing a take home takes less time.
but they're not? every screen i've been through has been on something that doesn't even compile the code (e.g. coderpad.io for FB or docs at G) and the interviewer then writes a summary afterwards (ala hiring packet at G) with ratings along some axes.
Take-home problems are automatically scored as well. The company defines an API or interface to the code and creates a test suite to run against it.
The benefit of take-home problems is that you have the option of reviewing the code in-depth if you need more perspective. If a candidate only passes 7/10 tests, I'll still dive into the code to see what went wrong. If it's an honest mistake, I ignore the failure and amend the instructions to make it more clear for the next candidate.
Most of us work in hum-drum industries for companies no one's heard of, in towns no one's heard of, and have reasonable hours, good enough pay, and have never logged onto leetcode for anything other than to briefly see what all the fuss is about.
I will guarantee that at least half the developers I work with have never logged onto leetcode and many have not even heard of it. They're too busy working, raising kids, and coaching little league to be wringing their hands about the latest nonsense in SV.
And that’s with being an immigrant from eastern-ish europe.
But it sure is fun to flog on it as a meme. I doubt more than 30% of engineers working in SV startups ever actually used leetcode. And I certainly wouldn’t hire anyone above absolute junior based on their leeting skillz.
Leetcode is shorthand for algo interview prep, there are many alternatives to leetcode itself.
I've interviewed with 100+ companies in the bay. His experience is not representative of the industry at all, IMO... 90% of companies use leetcode here. Again, I need to emphasize, I've interviewed with way more companies than most people and most of my peers interview with dozens as well and they all have to grind leetcode.
Fair. And no, I haven't worked at a publicly traded company nor would I really want to. The optionality makes for good leverage in salary negotiation though.
From what I can tell when interviewing engineers, most over-index on the algorithms. Sure we all ask an algorithms question, but it's more of a checkbox. It's the other 6 interviews that tell us way way more about the candidate.
And yes, I could get more at Facebook, Google, or Apple, but then I'd have to work for FB, Goog, or App.
The rest of the interview types are fairly easy to prepare for, you almost do not have to, just do a few interview loops with your lower priority companies and your mostly good.
I also would reconsider not working at a pubicly traded company. I used to work in a startup for years, and I regret not switching sooner. Dan luu summarizes my thoughts on it: https://danluu.com/startup-tradeoffs/
edit: And I've never seen a startup offer enough equity to offset the average risk of that equity being worth nothing (and things like not being able to invest the money). It's fine to take a gamble, the payout can be nice, but in terms of average expected money after X years startups are light years away from FAANG in my experience.
[1] https://kstatic.googleusercontent.com/files/25badfc6b6d1b33f...
And with that said, you too should care, because I guarantee it's only a matter of time before those "hum-drum industries" take a look at the way SV does things and says "hey, we should do that too". This is already happening in many places. Your company could be next. You should be interested, if only to learn to spot the warning signs and nip it in the bud when you can.
I think Allen Iverson said it well:
"We're talking about practice, man. [laughter from the media crowd] We're talking about practice. We're talking about practice. We ain't talking about the game. [more laughter] We're talking about practice, man."
Fun fact:
I had a recruiter reach out about interviewing at a non-FAANG company that is private. Being private there are no RSUs on offer but instead some kind of Company Funny Bucks doled out based on "performance" etc. Whatever, all well and good so far. Competitive salary but TC wont be anywhere in the same solar system as some of the FAANG total comps Im aware of for a position of similar level.
Then the kicker comes - I get an email about "interview preparation" and I kid you not it was every bit as intensive as AMZN. Do they really expect me to put up with this hazing for the same money I can go make without it? For Company Funny Bucks (told to expect 10-15% of my salary at best with a whole lot of qualifying "if's" in there indicating this was mostly fiction). Needless to say I performed a quick analysis of the value of my time and opted to politely pass on the interview.
Doctors have board exams. Lawyers have bar exams. Financial professionals have their own set of exams. Electrical and mechanical engineers have professional engineer exams.
The difference is that they're standardized, so the prep industry caters to passing those exams more so than passing the interviews.
Software engineering is far from standardized because the subject matter is far too varied, so instead companies handle their own type of exams customized to their needs.
There is also a cottage industry around interview prep for lawyers, doctors, and other professions. It's just not well known because it's extremely expensive relative to spending a couple hundred bucks (if that) on Leetcode. It often takes the form of expensive 1:1 coaching that starts in the hundreds of dollars and can easily enter five figures. Students from wealthy families frequently have private coaches for this.
I think the bigger problem is that technical interviews are broken. I ask everyone to bring their own project to work on, since I hate the traditional tech interview process so much. And it goes incredibly well.
It could be adding a feature to a side project, starting something new, or contributing to open source. (Or, we have some stock ideas if people need inspiration.) Rather than asking them to solve a problem they had never heard of before or use a codebase they're not familiar with, I get so much more out of watching them work in their own environment.
I can ask them questions about why they're doing something, and they tend to have much more detailed answers because they've been thinking about it for weeks. They're solving a problem they care about in a codebase they know, which mimics how working with them will be a few months in.
We could all just buy into this notion that tech interviews suck but we have to deal with them. And then, like SAT Prep classes, there's a whole industry around how to pass them. Or, we can spend more time talking about how there's definitely a better way.
We had a hypothesis internally that some parts of the interview were redundant. The interview was certainly tweaked over time, but the data science team found otherwise. All scores are positively correlated. And removing any major part of our interview would have made the interview worse. Given all my experience with it, I believe the triplebyte interview to be a fair assessment of candidates, and respectful to everyone involved. (Though I’d be very interested to know how much 5+ practice interviews would move the needle on scores, as this article claims.)
The hardest part of my job was nervous candidates. Stress is designed to help us survive running away from a lion. When we get stressed, we shut down our ability for creative thought and our memory gets weaker - which is literally the opposite of what you want in a job interview. Most of my energy as an interviewer went into helping candidates stay calm throughout the process, and I wasn’t always successful.
I don’t think there’s anything fundamentally wrong with whiteboard interviews. You’re right - we could probably rearrange the professional world to avoid all stressful assessments but I tend to agree with this article. Just do a bunch of them and you’ll get used to them. Being interviewed is just talking for an hour or two with someone smart about something you care about. Usually you get to talk to someone you would have no access to in your daily life. If you can get past your terror of being judged, they can be a lot of fun.
Anxiety before a job interview (or exam) is your body believing that if you do badly, you might die. It doesn’t take 400 job interviews to notice you don’t actually die. The article suggests it takes about 5 practices. I also liked what they said about the collage experience. Seeing a lot of my fellow students succeed and fail job interviews seemingly randomly probably helped more than I think. It made failing an interview feel like just a normal uncomfortable thing.
Every time there’s an article like this on HN there’s people whinging about the interview process. But for most developers, interviews work fine. I stand by my claim that a well designed interview with a balance of content (see my other comments in this thread) is a fair and accurate way to assess a candidate’s programming skills.
Being interviewed at a lot of places is 6 hours of narration while you solve LeetCode problems with a dry erase marker.
Actually talking with candidates is more effective in my experience.
- Take-home LeetCode: poor communication skills, bad at workflows, unpleasant personality, poor architecture, write-only, cheaters.
- Live LeetCode: same as take-home LeetCode but at least they have communication skills and aren't cheating so you know they can write efficient functions.
- Resume: all the issues with take-home LeetCode.
- Culture fit/behavioral: all the issues of take-home LeetCode, but at least they're good at communication and have a good personality.
- Take-home project: same as take-home Leetcode but instead of efficient functions you know they can at least architect and implement a small, standard application (if they didn't cheat).
- Show me your side project: Same as take-home project, plus they might work extremely slowly, and might only be passionate about that one side project, but you know they have communication skills.
- Architecture whiteboarding: can't actually code to implement the systems they're drawing, but you know they have communication skills.
So it's no surprise that companies wanting to reduce the risk of a costly bad hire (a bad fit, not necessarily a bad person) evaluate the candidate from different angles to check for red flags.
I sympathize with the frustration of those who present false negatives and are filtered out despite actually being a good fit, for example working parents who can't spend a whole weekend polishing a take-home project.
Students sort companies they are interested in in descending order so your take-home will get done whenever they have some time available.
Are you seeing excessively demanding take-home projects? I've only ever seen take-home challenges in the 1-4 hour range.
On the hiring side, I gave candidates a choice between our take-home problem or an on-site interview. Everyone gladly chose the take-home problem.
I don't understand why so many people are loathe to spend a few hours in the comfort of their home working on a take-home challenge in their preferred dev environment, when the alternative is to take time off work to handle a mid-day interview with a live person.
As much as HN hates take-home problems, I've received near universal approval from candidates on the hiring the side relative to having people do live, in-person tech interviews.
For college hiring, that's on top of a busy schedule (and everyone interviews roughly at the same time). So the take-homes add up.
And it's a long time commitment from the candidate but a potentially very short one from the employer (run some automatic grading/testing then ghost the candidate). Going to an on-site and meeting engineers shows more commitment on the employer's side (talking to the candidate is worth 2 hours of an engineer's time).
But if you have a good completion rate for your take-home, that's great.
Easy to waste candidate time.
With in person interview time commitment is the same for both company and engineer so no sane company will waste candidates time (at least on purpose). Feels much more fair.
At some point how much hand-holding is enough?
They pretty much told candidates where to get sample problems, gave a session showing what the interview is like, did one mock interview... Pretty much all what prospective applicants have to do is pair up and do a few more practice rounds.
How is it the evil tech company's fault? They gave them the toolbox with all the tools in it and instruction on what to do. And the material to practice building whatever they said they will test them on.
What difficulty of questions will be asked? Easy? Hard? Do people actually want to "hear the thinking process" or do they just want an optimum answer regurgitated quickly? Do I need to practice "regular" interview questions also ("What's your greatest weakness?")?
All of this with a life-changing, potential millionaire amount of money at stake, which isn't great for the nerves.
Isn't it what they talk about in the outreach session described above?
It is exceptional to be at a company and all the interviewers are on the same page about how to interview. This is true even at FAANG where they’re all supposedly trained on how to interview ... but still end up all acting differently.
> What difficulty of questions will be asked? Easy? Hard?
Easy to medium depending on the position or any number of factors. MAYBE hard if you've done really well and solved the questions quickly.
> Do people actually want to "hear the thinking process" or do they just want an optimum answer regurgitated quickly?
Thinking process is far more important than getting the optimum answer. You have to talk your thought process out loud. Think less "find the best answer" and more "gather requirements and optimize within the given time window". It's far better if you treat questions as applicable to real world scenarios where you only care asymptotic complexity as a tool, because you have real resource/network constraints. It is still important to know how to analyze asymptotic complexity. It is not important to get the most optimal answer, but it is important to be able to optimize on the trivial (brute-force) answer which you should always state to begin with. Depending on the interviewer, they'll ask you go further and maybe prod you with hints. It's really really important to communicate and make sure you're solving the right problem and that the interviewer is on board; this is also a skill that you pick up. It also very much applies on-the-job "I did exactly what was asked" is probably the wrong thing to say if you're not taking ownership to clarify the issue and solve the root problem, because that's what's ultimately important. All of this can be learned with practice, and it is 100% expected that you study and practice.
> Do I need to practice "regular" interview questions also ("What's your greatest weakness?")?
Yes, behavioral questions are also important as long as you can pass the technical portion. The idea here is to understand how you would deal with situations. You answer these in a STAR (Situation, Task, Action, Result) or SAR format, and you should have these STAR format answers prepared for any types of questions they would ask. Depending on the company's guiding principles you would formulate your answers to display how you exhibited a particular principle in each of your stories. Don't be humble -- use "I" language rather than "we" language here (I had to practice this). Data based answers are best here ("grew user engagement as measured by replies by X%" vs "grew user base"). Impact is important but unfortunately that's not always within your control. The end-result isn't necessarily important but your learning is (e.g. if the project flopped, what important things did you learn that you'll never make the mistake of repeating again, and how can you pass that knowledge on to your team).
Lastly, these interviews are designed to weed out false positives so even if you're more than qualified luck still plays a part and it can be a numbers game, so keep trying.
Still, the vast majority of applicants aren’t going to pass. It’s not like it’s just some minor brushing up for most - it takes real work and dedication, for some that could do the job well over 100 hours... an infinite amount of time probably won’t be enough for those who can’t.
Or a serious algorithm and data structure class.
This is not a specific judgement about diversity as a metric, but an observation of making any something a metric.
So wrong because it equates passing the interview with being good at the job. These two things have almost nothing in common.
So right because practicing jumping though artificial hoops is exactly what you need to do to succeed at a large corporate. This skill is orthogonal to contributing actual value.
I question being concerned about a “gap” when the only outcome is a better chance for working at some advertising company.
"I have a personal policy against any type of live coding or online coding tests during interviews and I don't enjoy or engage in any form of competitive programming. Otherwise, I am happy to work offline on coding assignments with reasonable goals and deadlines and to have in-depth technical discussions about software architecture and design as well as relevant technologies."
I'm still perfectly able to find suitable jobs with good pay as a software engineer and being upfront about the above policy prevents a lot of frustration and wasted time on my side. Yes, I do have to invest a lot more effort into looking for a suitable job, but, then again, I'd very much rather spend my free time doing that than going again through one of these interviews.
PS: I have 14 years of work experience, currently working as a senior engineer / tech lead on cloud infrastructure and this is my 8th job.
Some background so you understand context: I dropped out in 2009 because I lost the programming job I used to pay the bills. At the time I mostly worked on PHP web apps and did some microcontroller testing for a local business. I joined the military shortly after, served my time, and worked my way from desktop support to network engineering, to "DevOps" (in it's early stages), to being an SRE-SE, to a SWE again over the course of six years. I never did go back to school, I can go into the myriad of reasons that affect the statistics that the DOD and VA will happily show you on the way out the door but don't seem to post publicly, but I think that's for another post. I could not get a job programming again. Logically, no one wanted a programmer four years out of practice, but I quickly learned that big tech has a major shortage of Systems Engineers and an even much more major shortage of Systems Engineers that can write full applications as opposed to scripting.
Large firms tend to focus on one skillset and that is mathematics. The reason for this isn't very illusive, they hire mostly people with mathematics degrees (CS and CE) and interview based on the skillset they know best. The problem is that the people who dominate this group know nothing to very little about systems. I have been on countless interview panels and often I find that people will pass abstract systems design but when you make them directly apply this theoretical knowledge to an OS they will fall flat on their faces. Ask them questions about network sizing and you'll get networks that are incredibly huge or don't make sense at all.
The problem is that the reverse is true too, when you take a Systems Engineer who could walk you through kernel process scheduling, the order of operations in calling execve on a binary, etc they often struggle in algorithm application. They may pass your algorithm test if it is pretty plain to see what algorithm needs to be applied and it requires pretty straight forward implementation but if you tweak the process a bit, they fall flat on their faces. This doesn't disambiguate from Systems Engineers that can't code, I'm purposefully excluding these folks because we're talking about variants of programmers. I have spent years trying to get myself up to the level that college graduates have with algorithm recognition and application.
I'll stop here and say if you find yourself in the same boat, frustrated and upset over interviews, I see you. Cracking the Coding Interview and Leetcode are okay for practice, but if you're struggling to identify less-common data structures and algorithms or how they relate to one another there are two books that helped me infinitely: Introduction to Algorithms by Cormen, Leiserson, Rivest, and Stein and Algorithm Design by Skiena. Python and Java are good for playing with most of these. It took me about two years to get up to par with college graduates.
What people from bootcamps struggle with, in my experience, is the same thing that systems engineers who can code struggle with. Algorithm recognition, selection, and application skills are not on par with that of a newly minted mathematician.
Do you want to solve this? Teach. I teach programmers about systems all the time, mainly because if programmers want to learn about systems there's a myriad of books like The Linux Programming Interface to Linux Kernel Development that are all very indicative of how nix systems and kernels work. These assume a pretty cushiony set of knowledge to begin with, so their foundational knowledge has to be increased first. Unfortunately, there's not a lot of material on the internet for this beyond shallow tutorials on Linux and Unix commands, some StackOverflow answers, etc that will inevitably guide a trainee ...