I've just landed a job at a FAANG company. Some random subjective comments based on my experience:
- it was hard work
- there was no way I could have passed these interviews without all the work.
- my past experience and education barely helped me for the interview
- it's not enough to be able to solve the problems, you need to be able to solve them on the spot, without much thinking, in an interview context
- I passed system design quite easily, even though I have little real-life experience with these systems. It would have been easy for interviewer to catch me off guard on real-life technical details, but they didn't care
- these companies (FB and Google) gave me a chance (even several ones), even though my resume is slightly atypical, and I'm on the older side (mid forties)
- Recruiters and interviewers were friendly and respectful. Overall they gave me a very good impression of these companies
- The whole process is very random
- I did learn some things while practicing. Not the best use of my time, but not totally lost either
- Algorithmic questions were harder at Google compared to Facebook
- The whole process was more fluid at FB (team-matching at google took forever, I was even ghosted by a recruiter after she told me I passed).
> - it's not enough to be able to solve the problems, you need to be able to solve them on the spot, without much thinking, in an interview context
Sounds like they're looking for assembly line programmers - crank out the code, pass it off, then on to the next piece of code without pause. This would be a nightmare for me. The high salaries and prestige of these companies definitely would not be worth it. I'm not neurotypical. I met an older man when younger who recognized this when he hired me so he left me alone. I worked at home and provided him programming solutions on my time schedule, which turned into millions of dollars for me and much more for him. I'm happy to let the fast programmers do the speed programming.
It's because when companies get that big and famous they no longer need that many creative individual thinkers, they need obedient drones. With disproportionately large numbers of applicants they get, they are able to make you jump through all the hoops they put in front of you, because if you won't there are thousands of others who will.
Plus the prestige of being able to walk into your next job and captain the ship. I've been at a few places that hired former Googlers, and they were all treated like gods.
It used to mean something more than it does now. I noticed ex-Googlers were well above average in 2012, now they can be below avg. I have a colleague of mine at my current job that makes a point of being an ex-Googler but they only worked there for 6 months, so it is kind of meaningless.
It's always been a distribution. Some are amazing, some are normal, others are less than normal. They're all really good at the handful of things Google screens for, but otherwise it's just like any other distribution of developers.
As a hiring manager I view Google on someone's resume as a non-signal. If however they are the sort of person who draws attention to having worked at Google I view that as a negative signal.
Global average or people-who-work-at-FAANG average?
The frame of reference here is important, otherwise average is pretty meaningless since we have no objective list of what an average developer consists of.
Is that really true? I've interviewed ex-FAANG employees at some jobs and there was never any pressure to hire them, and I didn't feel like any one of them would be treated as a god if hired. They were pretty universally above average though.
They were also not "walking in to captain" anything. They were applying for standard engineering jobs. Think of an average individual-contributor software engineer from, say, Facebook. Is a smaller company really going to hire them as Director Of Engineering (a totally different job than software engineering), just because of the company name on the resume? That sounds absurd.
The amount of osmosis learning of how things should be that comes from working somewhere that things were that way is hard to explain. The density of good ideas you get exposed to has a huge effect, even if you aren't in leadership. It also doesn't necessarily come across in interviews, it's reflexes you might not realize you have.
I was very skeptical about this, then I worked for one. Now I get it.
I'm not in a leading role but I did "impactful" things like introduce CI to a company. I'm not sure that it matters what position you have, because if you are the first one doing something you actually get to do a lot of decision making.
And really only an expert in the things that FAANG companies do. Granted for a place like Amazon that's potentially a very broad space, but it's still a small slice of skills compared to the world where software is ubiquitous. Among other things, zero preparation for safety-critical software. An attitude like "move fast and break things" would end up being "move fast and kill people", and that's kind of a drag on your career. (Insert long discussion about trolly problem and how self-driving car researchers are justifying their crappy algorithms)
Not my thing personally (at least not today). I could buy a lot more toys and BS and retire earlier if I took one of those jobs, but my already generous (not by FAANG standards) programmer salary is enough and it comes along with a sane schedule and reasonable work expectations. The value in this is I get more time outside of work to enjoy my life, which is worth more than an extra pile of lucre when I already get by pretty comfortably.
I don't know where this misguided implication comes from that FAANG doesn't have a sane schedule or reasonable work expectations. The people that work a lot do so because they're some of the most passionate in the industry and enjoy working a lot as a result. On average, I would speculate FAANG is less stressful and more reasonable than other companies. The reason you may think that is not the case is that negative stories stick to the same "brand" (i.e. "FAANG") that employees hundreds of thousands of people whereas a story about a random mom'n'pop shop doesn't register on your radar because there are many of them.
I would describe FAANG (in my and many friends' experiences) as "adult daycare." Not in a bad way, mind you, but very much "get your homework done and go have your free time after." (This excludes higher management and architects, etc., of course. I mean this as a middle-of-the-road SWE on a decent team.)
I'm not quite sure where the GP got stressful, but it is soul-sucking if you expect your work to be interesting, impactful, and creative, which doesn't really happen apart from a few core or research teams. There is a ton of piping and rewriting of frameworks going on all the time, even when it need not be extremely useful. This is the main reason I found it thoroughly drab—even though it is likely that the lines of code I wrote there are likely to touch many orders of magnitude more people than anything else I ever work on for the rest of my life.
I fully agree. It is soul-sucking at times, but nowhere near as soul-sucking as the life I came from and I will never stop being grateful for that. If I want more excitement from working, I can always pick up the exact work of my personal interest on the side (but I don't, because there are so many other interesting things to do outside of software). I'd rather have great security and quality of life from the work that puts a roof over my head.
Absolutely! There's a kind of beautiful freedom about it, too.
A number of people (myself included) seek to align work and passion all in one, which is fine, except it's certainly not the only (or, indeed, even close to "best") way to live and work. I've been lucky because my passion is in a field that now actually has applications in both theory and practice, after 50-or-so years of lying in relative academic obscurity.
The point is: if you care primarily about things that aren't your work (and this is true for literally 99.9% of people in the world, and is probably much healthier than the alternative) then FAANG is phenomenal in every possible way. The perks, compensation, and freedom to do pretty much anything are incredible. Quant (which nets around the same, if not slightly more profit) certainly does not fall in this category, due to its insane hours, and most other jobs with sane hours and good work-life balance don't pay nearly (read: really even close to) as much, or aren't as secure, or have anywhere close to the perks. It really is about the best gig you can get, if you can swing it.
On the other hand, for the weird, obsessive .1% of people (e.g., me) who would be happy to work all day in their mother's basement so long as it's interesting work, then FAANG (or, at least, many teams within it) can feel almost beside the point. Which is also fine!
I guess the point is that it all depends on what you want out of work and out of, well, not-work!
This comment chain is well said. There are more likely to be various random events that screw you over or suddenly put extra pressure on you at smaller companies, not to mention the lack of perks and compensation. Recently an analogy that I've come up with is index fund investing: Sure one can attempt all sorts of creative investment combinations/maneuvers, and sometimes they do make it big, but in the end, the most reliable and care-free way to grow your wealth is simply to follow the mainstream advice and go for the index funds, even though they "sound" boring af. They are recommended by the mainstream for a reason just like how people flock to big tech companies for a reason (at least this still applies in our current day and age). I've had some alternative ideas about my career with various excuses (e.g. I'd only work with a functional language), but increasingly I realize that I should probably just quit all the tossing around and go for such a path instead. It's similar with my investments: Had I not performed various stupid active trades here and there and just put my money into the index funds, or even just parked my money in cryptocurrency and held on to them, I would have got amazing, carefree returns.
Feels to me there are a lot of stereotypes and misconceptions about FAANG floating around in this thread, which I guess is not exactly surprising given the type of post this is (criticism of the "broken" interview process). It almost feels like some people find excuses to not even try, or have some sort of sour grape mentality/avert their eyes from the issue, if they feel themselves unlikely to pass the interview, even though they haven't spent the time required to master the algorithms questions at all. (Of course, there might also be people who simply find it quite hard to find such time, as mentioned in the article, which is understandable.)
My understanding is that those companies themselves also freely acknowledge that interviewing is hard. Due to the sheer volume of applicants, fast algorithms questions is the most reasonable compromise they can find at the moment. If you were in the position of the interviewer, it would also be hard for you to come up with an alternative that works for all sides involved. So instead of complaining about this reality, one needs to face up to the challenge.
It is actually a paradox: You seem to be unfree and doing something pointless when you were grinding interview questions. But after you've made it, it would suddenly be very easy for you to have a lot of freedom and security in your life with all the capital you have accumulated. In a sense it's like how college entrance exams work. It's unfortunate but again, if no better practical solution could be found at the moment, one just has to face the reality and do it. It could even be fun. Talking about "ideals" wouldn't get you anywhere in the real world.
Regarding work-life balance, perks and life quality, just as the comments who replied to you pointed out, working for big tech is most likely one of the best options you can have out there, compared to many smaller-scale companies.
The one valid thing I think you may get by not working for FAANG is complete freedom in shaping what you're working on. However this is hard anywhere unless you're the founder/executive of the company yourself. If that's what you're after and you have the safety to pursue it, sure. However, in terms of working as a common employee, there are very few possible reasons why a place could be better than big tech.
Well, there are also counter-examples to your thinking. Brian Acton was rejected by Facebook, then went on founding WhatsApp and eventually selling it to the same Facebook for $19B. "Life altering amount of money", wouldn't you agree? Probably one of the most expensive rejections in history.
That's an extremely, extremely, extremely, unlikely edge case though. You're more likely to get simultaneous offers from all the letters in FAANG while also simultaneously becoming a 1MM+ subscriber Youtube star than you are of repeating Brian's story (or even a fraction of it).
well there is the story of when Google acquired youtube at the all-hands meeting the CTO addressed the engineering department and asked them how many of them had been rejected by google, and half of the people there shot their hands up. Probably they had a better windfall, and "Google could have saved more than a few billion"
On a similar vein, I recall a story that said most Googlers thought they probably wouldn't pass the technical interview if they had to go through it again. Does match with what my friends who made it into FAANG say as well - none of them are confident they'd be able to do it again with any certainty.
There's a story, mentioned many times here on HN, where Google (I think) hiring team were given their own anonymized CVs and they rejected all of them. It's a perfect example to describe the staggering level of hypocrisy at those companies.
I think a major take away here is the interviewers weed out ppl who don't know complex algorithms off the top of their head but you don't really need that to make a successful app anyhow.
Or, with the crazy amount of applicants they get, it’s very hard to come up with an alternative process e.g. pair programming for a day like what some small companies can afford to. They have to be able to do interviews efficiently.
Interview is hard. A while ago there was a post by Jane Street that explicitly emphasized this point. They also require algorithms questions even though programmers there write a lot of OCaml. I guess if you were in the position of the interviewer it would also be hard for you to come up with alternatives that are much better for all sides involved.
I think what is required for the interviews is very different than the actual work you do once you are hired. It 's also very team dependent.
The reason why you're expected to be fast during the interviews is that you're competing with people who are fast (either because they are smart, or because they've practiced a lot).
That being said, this type of interviews is clearly not for everyone. There are tons of skilled people who (for good reasons) don't want to play that game, and there'll always be a market for them.
> I think what is required for the interviews is very different than the actual work you do once you are hired
I'm sure that's true once you achieve seniority. I'd wager that the first couple of years, at least, you're not solving problems, but implementing solutions designed by higher ups. You need to do this fast to be useful.
I'm in the interviewer pool at Google. Other FAANGs might be different.
I've had candidates ask me why we do this, and my answer is that once you're in the company, transferring to another job on the same ladder is fairly trivial and requires no technical re-interviews.
I go on to describe how I've been around for 10 years and am on my 5th team. None of those transfers required any sort of technical re-check. Teams trust me when I say what my abilities are.
Sometimes they'll look at past CLs, and we certainly have a couple interviews to make sure that the fit is good, but nothing technical.
In none of my positions has it been "crank out the code, pass it off, then on to the next piece". There has always been a clear sense of ownership of my code, where I've been responsible for both the code and a steward of where and how it's used and modified.
I’m not sure how unique that is, though. Most companies once you’re in doing technical, your peers will trust you to switch teams or broaden out a little. Re-testing a coworker would come off anywhere between amusing and insulting.
At larger companies I've worked at without central hiring committees it was common to get re-interviewed unless you were vouched for by someone pretty senior.
I don't doubt that you're required to maintain your own code after you've checked it in for others to use ("pass it off") but have you always designed your own solution or have you had to implement designs by higher ups for some not insignificant percentage of the time?
I've never been given a design doc to implement (though I prefer to code, so sometimes I wish I had). I've always been expected to do the research and figure out the design for myself. Sometimes I ask people to fill in parts of a design doc that I know they'll be implementing. This ensures they are aware of the design, it's correct, I haven't missed some critical details, and they have essentially written the design for their own work.
Occasionally I've had a design review where a higher-up has said "this is why we aren't going to do it that way". I've always been given a reasonable reason (not always one I agree with, but reasonable). I've always been the one to re-write the design in these cases.
not OP, but currently a manager at Google (full disclosure, opinions are my own, company is not involved, etc)
I fully expect that everybody at Google will create the designs for the problems they own, get the designs through peer review, work on implementing these designs, and verify that the solution is solved in process.
What changes with the seniority level is the scope of the designs - a junior may be expected to design their piece of code, only their module, a mid level is expected to design an entire subsystem while delegating individual modules, a senior is expected to design an entire system delegating the subsystems, etc. Of course, it's not so clear cut all the time, but the critical piece we have here is that - Everybody, at all levels, are expected to share expertise, knowledge and acumen in order to help others grow. When you put everything together it creates a nice cycle of constant growth pressure.
Absolutly I will not qualify anybody's work here as "droning", and if someone in my team would feel like that I would invite them to speak up and work together into making it better.
About the quality of people here, what has impressed me most is the uniform high level of competence and niceness. In other companies where I've worked the skills would more-or-less all over the place, but here it's uniform good. I'd rate Googlers consistently in top 20% of the teams where I've worked with before. Also everybody is so very nice, a real pleasure to be around and work together. I still haven't discovered how recruiting selects for this, but everybody constantly passes the airport test my in book.
That's not it - it's that interviewers set problems that they already know how to solve. They forget how hard it is to solve new problems on the spot in an interview setting.
In my experience technical interview questions are usually way harder than they need to be. I don't agree with getting rid of HackerRank style filters entirely because they save you a ton of time with candidates who just can't code at all (or candidates that think they aren't applying for a coding job). But the questions should definitely err on the easy side.
As an ex-Googler who's done a fair bit of interviewing, my bar for "will I use this coding question" is to look at the problem statement, do a from-fresh implementation in a suitable language, and if it took me more than 7 minutes, it is not suitable for a 45-minute interview slot (I would expect the candidate to have a solution in ~20 minutes, then maybe 10 minutes of follow-up questions, then flip to "do you have any questions for me").
I thus gave the candidates roughly three times longer than I needed to solve the problem myself, which should pretty much account for the interview situation.
"The key point here is our programmers are Googlers, they're not researchers. They're typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They're not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt."
Rob Pike [1]
"It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical."
This sort of "programming language designed for people we apparently have a very low opinion of" approach also greatly informed the design of Java, though Java has spent the last 20 years slowly retreating from it. It looks like Go might be following the same path; it's apparently getting generics at some point!
Can you imagine how many times Google was burned by junior devs writing C++ no matter how smart they were? Memory bugs at Google scale must be expensive. They had to come up with Go.
At scale, it might be hard to do that, however this doesn't address the key problem. One of the hallmarks of good engineering is to add technical safeguards, rather than relying solely on Smart People.
It would be comical to hear, "Hire better pilots" as an alternative to building parachutes, or fly-by-wire systems.
Every one makes mistakes. This is why we have tests, linting, code review. Our choice of tools that we use (or, in this case, create) reflect our engineering needs as well. The goal is not just to hire Smart People, but to make it _hard for people to make critical errors_. At Google's scale, I can completely understand why they might feel that developing a new tool was the best way to prevent a core set of problems.
> This is why we have tests, linting, code review.
None of which is related to using a dumbed-down language.
> At Google's scale, I can completely understand why they might feel that developing a new tool was the best way to prevent a core set of problems.
There's plenty of research around software reliability and on the sources of bugs across different languages.
Research shows that verbose languages e.g. Java don't have lower bug rates or better maintainability than expressive languages like Python.
Dumbing down a language, reducing expressiveness and introducing boilerplate does not help. If anything, it removes the attention of the developers from the core aspects of an application.
Tests, linting, and code review are all tools that we use to find mistakes before they get into production code.
A "dumbed-down" language is a tool that prevents one from being able to write certain classes of errors (e.g. some of the footguns from C).
Changing the language doesn't mean you make less mistakes, but it means that you make different kind of mistakes. I'm rather unlikely to make an error related to memory allocation in Python or Java, for example.
I know C++ and I know Rust is growing because of memory problems in C++ code. I would agree with this statement "It requires years of experience and great discipline to avoid errors in C++" from this article https://www.toptal.com/c-plus-plus/top-10-common-c-plus-plus...
Eh, I've always seen this as the counterpart of the old meme that there are no bad languages, only bad programmers.
He's not going to get many C programmers to adopt his language if he gets on stage and announces C is a crap language and anyone who thinks their code doesn't have memory bugs just hasn't found them yet. Is this asshole saying I'm bad at my job?
On the other hand, if he says that of course you, dear reader, have never coded a bug in your life - it's other programmers who do that, and this new language will help you collaborate with those poor unfortunates? That's an easier pill to swallow.
But an 'assembly line', line-of-business programmer has almost no need to solve algorithmic problems. Why would they test that if that's what they needed?
>The tests are therefore all about excluding candidates rather than identifying brilliant young mavericks with potential.
The author assumes that companies want mavericks. Maybe the FAANGs and other high tech firms still search for a few innovators, but wouldn’t they look at other networks besides the typical interview process to identify these candidates?
We are living in an age of developer commoditization, and for many large tech companies the army of assembly line programmers can churn through enough peripheral work at the right price.
> Sounds like they're looking for assembly line programmers
Feels to me there are a lot of stereotypes and misconceptions about FAANG floating around in this thread, which I guess is not exactly surprising given the type of post this is (criticism of the "broken" interview process).
In your case it's more understandable if you wouldn't like working a conventional job, since you mentioned you're not neurotypical (though I guess you would most likely find work at most smaller software shops even more suffocating).
However, for the majority of commentators, it almost feels like some people find excuses to not even try, or have some sort of sour grape mentality/avert their eyes from the issue, if they feel themselves unlikely to pass the interview, even though they haven't spent the time required to master the algorithms questions at all. (Of course, there might also be people who simply find it quite hard to find such time, as mentioned in the article, which is understandable.)
My understanding is that those companies themselves also freely acknowledge that interviewing is hard. Due to the sheer volume of applicants, fast algorithms questions is the most reasonable compromise they can find at the moment. If you were in the position of the interviewer, it would also be hard for you to come up with an alternative that works for all sides involved. So instead of complaining about this reality, one needs to face up to the challenge.
I would conjecture that most lower-paying "programming" jobs, e.g. writing enterprise Java, are much much more "assembly line" and "soul-sucking" than jobs at top-notch tech companies, which should offer a decent amount of creativity and freedom for one as an ordinary employee.
It is actually a paradox: You seem to be unfree and doing something pointless when you were grinding interview questions. But after you've made it, it would suddenly be very easy for you to have a lot of freedom and security in your life with all the capital you have accumulated. In a sense it's like how college entrance exams work. It's unfortunate but again, if no better practical solution could be found at the moment, one just has to face the reality and do it. It could even be fun. Talking about "ideals" wouldn't get you anywhere in the real world.
The one valid thing I think you may get by not working for FAANG is complete freedom in shaping what you're working on. However this is hard anywhere unless you're the founder/executive of the company yourself. If that's what you're after and you have the safety to pursue it, sure. However, in terms of working as an ordinary employee, there are very few possible reasons why a place could be better than big tech.
One big problem is that companies (especially FAANG) are wasting time having very senior devs do Leetcode-style shit, which is a false negative for people that don't balance binary trees and manually regex strings all day. This especially penalizes more experienced / older devs who don't have time to LC grind (of which I'm also one), and introduces unconscious selection bias.
Certainly there are other ways to verify someone can code: code samples, talking through high level language concepts, reviewing existing code, etc.
What people should be focusing on is this - 1) Do you understand enough systems architecture / code techniques to succeed at this particular company? This can be done via mostly talking. 2) Do you have experience that will help us with our company-specific problems? Give them an actual problem you regularly deal with, and get them to attack it.
it's impossible that they don't know about it. the more i think about it, it's that they're either lazy or want to select for age but obviously can't do that in an overt way, so they pick a tool that nobody with a family has time to grind (i.e. 'old' people)
Your comment inspired me to ask a question I've had for a while. My background is not CS, it's computer engineering. So I didn't have any education in the fancy algorithms that you'll find in these interviews. Is that expected or did I miss something?
Depends on how much CS you were exposed to, I guess? Leetcode problems generally involve: DFS/BFS search, memoization, dynamic programming, various types of sorting, hash tables, etc... all baked into annoying edge-case-y problems that are difficult to rapidly solve under a timer when someone's staring at you.
Vast experience in compilers, embedded systems, functional languages, graphics, dev ops, or cloud technologies will be of no use. (Perhaps it will be later, if you get to a systems arch interview step.)
I also went to school for CE and although we did have some algorithmic and data structures classes, I don't think they were as in-depth as the CS curriculum.
For example, the only time I ever encountered red-black trees was in the context of prepping for software interviews.
I have the same background and I think you either missed something, or your degree was much more EE focused. I had the required data structures + algorithms classes as part of my computer engineering curriculum
A lot of CE degrees are EE with just the barest veneer of software to meet ABET requirements.
Mine had data structures and software engineering as CE-specific requirements (along with a dash of microarchitecture and HDL/FPGA stuff), the CS algorithms course was an elective that obviously gave priority to CS majors.
Beyond that, we had a department head that really only cared about shoving as many EEs as possible into the PG&E hiring pipeline.
Compared to software creating a circuit design is a complete nightmare. With software you can get away with a lot of shady things but in EE every tiny detail can matter. You can do very simple PCBs as a hobbyist but it won't even compare to what the professionals are capable of doing. In software we have hobbyists creating extremely important libraries that are used by millions of people.
Re-posting a suggestion I made here a few weeks back:
Here's a radical idea (read to the end before you object). The inspiration is a blend of how open source projects recruit developers, and how the 20% Google side-projects used to work.
I work for company A, I'm starting to get slightly bored or interested in doing something else. Without quitting my job, I contribute a few days of code to company B, whose project I find interesting. As I contribute more to company B, I eventually quit company A and join company B full-time.
Benefits of this approach: no interviews. Know what you are getting into. Try different things and what works for you.
How can we make this work: legal framework. California, if you are listening, pass a safe-harbor law that prevents companies from exclusive work arrangements, so I can always do a side-gig with company B even if they are competitors. Have company B compensate me, so we don't end up in a situation where company B is abusing job seekers by getting free work done. Maybe a law could say that I'm safe as long as my work for company B while employed by company A doesn't exceed 5% of my salary or so (so I worked for company B for a few days or weeks, not months).
Would that work?
This is a key insight that people need to understand.
In a 20 year career I've only ever been on the market once (in 2017), and I saw it as a huge opportunity to join the best possible company. I did over a dozen on-sites, and every single one of them was 5 hours plus, sometimes multiple, w/ take homes or phone screens additionally. The results were shockingly random in terms of many different factors ranging from familiarity and fluency with the class of problem, to the style of the interviewer, to the order of the interviews and how exhausted I was by the end. The outcomes in terms of offer/no-offer also bore little relation to my perception of how the interview went.
I think this doesn't sit well with people (especially technical people) because they want things objective and fair. However standardizing process and addressing biases only gets you so far because at the end of the day interviewers and candidates are all unique. Success in a role is highly dependent on context that one operates in.
Honestly I don't think the hand-wringing helps anyone. At the end of the day you have to just play the game. Hopefully companies continue to employee a variety of different interview techniques, because they all have different biases and so the best thing is just to ensure a diversity of techniques so everyone can find their place.
This process is all theater. We really need some kind of certification process instead.
I'm a while out of school and one interview I went on had a requirement for a live coding session. The ask was to implement red/black trees from scratch despite the fact that they have an Angular app with MySQL on the backend. I took this as a blessing. I don't want to work at a place where they think this is a good way to hire people.
A certification exam wouldn’t survive a disparate impact challenge. Google stopped asking for SAT/ACT scores long before universities did. And long before that (according to my father, who actually used them), telegram companies had to stop giving spelling tests to telegraph operator applicants. Add to that difficulties with preventing cheating during a pandemic, and I see no alternative to rolling your own live examination. (Not that I’m defending the often dumb choice of trick tree recursion coding problems; I didn’t learn a lot about a candidate by watching him not get the trick.)
As an employer and not an academic institution, Google wasn't exactly visionary in ending requests for SAT/ACT scores, since virtually no other employer asks for them. Also, I interviewed w/ Google in ~2018, they still asked for my college transcripts even though I had been working in industry. So they still haven't fully shed their desire to academically successful people.
Just have the certification system be leetcoding on a whiteboard so the interviees need only pass it once rather than all the times for each FAANG, unicorn, and wannabe unicorn-FAANG startup that mandate such questions.
Because just like how interviewing is gamed now by leetcoding, certification exams will also be gamed by some other phenomenon like 'certcoding'. There are plenty of certification programs floating around already, not to mention the coding bootcamps which behave something along those lines. Ultimately, it boils down to who plays the game better, be it interviewing process or certification exams.
At the very least, it would be nice if all the companies that want to use this standard could get together and design a certification that they all accept. If we could cut the length of interviews down by removing the leetcode portion it would save countless hours of both candidate and interviewer time.
Well, now that you've started working. Have you actually applied any of it ?
To make an analogy, I'm always perplexed at how you're asked to build an EPR on the spot and then all you do is general electricity mundane work. I've seen a lot of EPR builder beeing incapable of simple wiring ...
If you don't mind sharing, where do you learn/read-up about the system design questions? I am not a software architect although I designed and built small modules/libraries of my own, but I don't think it's sufficient to learn about system design questions found in interviews (not just FAANG's).
A great starting point is "designing data-intensive applications". Then you can read about various designs here and there.
But you don't need to go that very deep. What they ask is very specific and (unfortunately) you're better off going through 10-20 typical interview questions and their solutions.
Typical questions are "how would you design Google News/Twitter/...". There are many resources available, all of this is discussed on leetcode or interview preparation sites.
It's not hard, but I'd recommend to prepare for this well-before your interviews.
Most of the interviewers were in their 20/30s and so is everybody on their "career" web pages and presentation documents. However, in the team I'll join, at least two people are about my age or older.
What I can tell is that never in the recruiting process did I feel discriminated against. Once you're in the loop, their main concern seems to be how well you perform in the interviews. I feel I was at a slight disadvantage compared to to my younger self in term of thinking speed for the algorithmic questions but this can be compensated by a better preparation.
EDIT: not sure why you're down-voted. Ageism is a thing and a legitimate source of concern.
EDIT: not sure why you're down-voted. Ageism is a thing and a legitimate source of concern.
There’s some folks here who REALLY don’t like talking about true ways our industry can fail and in some cases has failed at being decent and fair and ethical to people of protected classes, or just in general.
I think it's generally what he said. We age in one or two ways - get old and decrepit, or get overwhelming experience/skill which is tremendously useful. The first scares people and a lot do assume it's just the first part - maybe they think I am unaware of the second.
Thanks for your reply! For full context, I am older too, that's why I asked.
Oh I grokked it ;) but I felt very it needed a very fine and hyper-specific point to it because I'm older too, I also happen to be a racial minority, and it's a frustrating and sore point of mine-the way these topics sometimes (though in my honest opinion: far too often) get blunted and watered down so that whomever can avoid the uncomfortable sensation of staring a reality they don't suffer from, but might (operative word: might) be an unwitting participant of in the maw.
Let it be said now that your eyes are on this line, dear readers: that's not me suggesting or intimating that the person I replied to above is doing this. They're not. But it is a trend that some would be more than happy to pretend doesn't exist because they haven't had a reason to tune their cognitive receivers into the broadcast frequency people like me are sensitive to and have been bombarded with for far longer, with far worse outcomes.
Once they decide to go through the process, you'll be treated equally, however, the process itself is biased against folks who have other life goals, like raising families, who otherwise don't have the time to do competitive leetcode in their free time, but would make great employees.
Curious if any FAANG employees know if this kind of thing is still standard above a certain level, or does say "staff" level and above tend to be internal promotions only?
I guess the pay is phenomenal but I have a hard time imagining that this kind of algorithmic trivia approach makes any sense at all for hiring into senior roles. Especially if someone was trying to move laterally between FAANGs.
Google, at least, does the same style of interview for Senior and Staff positions as they do for entry level. It's just that the expectations are obviously different.
This is dumbfounding. Kinda tells you what kind of shit-eating devs they're looking for. What staff-level engineer possessing even a modicum of self respect would willingly subject themselves to this?
I've long been opposed to the Leetcode battery interview processes, to the point that I started asking FAANG recruiters that several years ago, and saying that was a showstopper for me, like a signal for how they treated people. Though I otherwise wanted to work at a couple of them.
After consulting levels.fyi, however, I've revised my opinion: if an employer is willing to pay a higher-level software engineer 2x the total comp they'd make most other places... whatever interview process they want suddenly becomes a rich and honored cultural tradition, to be treasured, and approached with the utmost reverence and humility. :)
That said, for people who've frittered away their discretionary time on things like open source, hobbies, family, etc., rather than drilling for FAANG interviews, the well-known "test prep" commitment for Leetcode-oriented companies is a barrier to even applying there.
"That said, for people who've frittered away their discretionary time on things like open source, hobbies, family, etc., rather than drilling for FAANG interviews, the well-known "test prep" commitment for Leetcode-oriented companies is a barrier to even applying there."
Salary aside - this is the truth right here. I interviewed at a few FAANGs and I didn't have what Id call a good experience. Neither resulted in an offer. To even prepare for them was a monumental time investment. I tried it and now I can have an informed opinion on the subject. Id rather have a life than drill for random interview questions.
Side note: I have yet to personally hear or read anything about why its so great to work at one of these places where someone DOES NOT mention the money. Frankly, were it not for the money Id have never even considered interviewing at these places at all. I have come to the opinion that if it's just money, there are other more tangible ways to invest my time that will result in money. Drilling For Interviews as a money accumulation seems to me a bit like heading to the casino on the 28th of the month because you're short a few bucks for rent.
Agreed. I kinda wish the FAANGs paid less, and had to appeal to people solely on positive impact, kinds of work people can do, work environment and how people are treated, etc. Adding "oh yeah, and you make more money here" complicates.
The big G, for example, already seemed like the place to go, as soon as they launched the early site (the company was obviously smarter than most of what was going on), and there was also the "don't be evil" that resonated with a lot of the prevailing sentiment among the pre-Web Internet-savvy techies. Though I suppose there might've already been a money factor from the start (it seemed like most people were crunching hard at work, but also prone to job-hopping for the hottest IPO lottery ticket at the moment), but it wasn't as clear as today.
I had a gig as contractor at one of FAANGs (they needed expertise that they didn't posses).
Money aside, after you remove from equation fleet of leetcoders there is a bunch of smart people over there that work on solving various interesting and challenging problems.
It's great place to learn on how problems (especially in scaling of various infrastructure systems on global level) are solved and also how things shouldn't be done :)
Thanks, I tried to give an objective assessment but I'm certainly a bit biased because it eventually worked out well for me (luck being a factor).
But I understand that people who invested a lot of time (and sometimes money) on their preparation feel extremely bitter if it didn't pay out in the end. It's also unfair that some candidates (especially some who have a family or not much time off) simply may not have the time for this.
> - it's not enough to be able to solve the problems, you need to be able to solve them on the spot, without much thinking, in an interview context
So true. It's not enough to write some approach that's better than brute force. We need to write the best possible method. And sometimes interviewers do not encourage methods that are not on their mind.
Unless you've made it to your "endgame" company that you're happy to stay at for a while, I feel investing anything more than the bare minimum to get your assigned work done is worth less than just grinding leetcode and otherwise studying for interviews. Doing an actual good job, above and beyond, is not going to be worth much when you're looking for your next job.
Thus we're now seeing the rise of Professional Interviewers or Professional Leetcoders. I am ashamed to admit that I too, am one, and probably will continue to be one until I make it into such an "endgame" company.
Our industry feels like it's in the decline of the Roman Empire right now.
Our craft is becoming arcane: Microsoft is building VSCode for the cloud. Few people own desktop computers anymore. Apple is locking down MacOS to signed binaries. Soon we'll all have thin clients and will write software in the cloud for the cloud. Few will be able to learn how to engineer at home anymore - you'll have to go to a university or trade school. Building a simple website will require JS package management, kubernetes, and AWS. The "free tier" will fall away.
Employees aren't excited by what they do: People job hop for promos, raises, and resume fodder, not because there's an actual interest in the product. The majority of software projects are mundane glue, pipes, optimization tweaks, or migrations.
Companies don't care about employees: Wages are adjusted for cost of living. Companies are trying to hire more outside of California in order to lower wages across the board. Employees at "passion project" companies (gaming, SpaceX, Tesla) are overworked and underpaid.
Incentives are wrong: Google bestows promos on launches, not KTLO. Google kills products that make customers and engineers happy and doesn't spend enough effort to make them better.
The industry is eating the commons: The web is turning into shit. Devices are being locked down. Ads and tracking are everywhere. Open source is being co-opted, but the benefits are not returned. The cool things to hack on and integrate with (remember "mashups"?) are all siloed up, full of ads, and dumbed down to the most basic products.
The Internet now treats everyone using it like we're all brainless idiots to be injected with dopamine. Like we're not smart enough to choose how to consume it. And working for companies in this field now feels like working for the insurance industry. Optimize for the average.
Unfortunately I feel it is hard for me to disagree with the overall sentiment of what you are describing.
But I'd like to offer a little glimmer of hope from someone with too many gray hairs to count.
Computers are still machines, and we still tell them what to do by programming them.
It is still possible to stay out of what you describe above, it is still possible to work on low-level code, on real products, on things that matter to people and companies.
The reality though is that the mundane things are where the money is though.
While we all enjoy "cool" things, millions of companies need their accounting and payroll running, their truck drivers planned, their work schedules planned, ...
So you might find that more interesting things happen in e.g. industrial engineering companies or electronics companies, more so than in web companies. It's an entirely different world than what you describe above.
Hackaday might be a more interesting hangout than Hacker News for you ?
So let's not lose our excitement and sense of wonder, after all it's all bits and bytes and we tell them how to behave.
> Hackaday might be a more interesting hangout than Hacker News for you?
The Hackaday focus on the dumbed-down format of video presentation is infuriating. It would be very nice to fund something community-driven, focused on actual content, with the same subject.
Until then, I think the few articles on the Hackaday subject that appear here on HN are worth more than the entire Hackaday site.
(I still visit both, of course, but tend to only look at the headlines there.)
> Computers are still machines, and we still tell them what to do by programming them. It is still possible to stay out of what you describe above, it is still possible to work on low-level code, on real products, on things that matter to people and companies.
Yes it is possible, but in practice one will (sometimes have to) spend most of the time with devices/technologies that make one die inside a little.
Part of the problem is that "doing the right thing" is often not competitively viable.
Some of the most inspirational stories in tech are along the lines of "I had this terrible job where we had to use tech X so I wrote adapter Y in more cool tech Z and automated the whole thing and took long lunches."
I'm an eighties whizz-kid, educated hardware and software background with borderline epiphanic understanding of computer technology. From firmware to systems where peoples lives literally depend on. In 2000 jumped on a plane to Taiwan to develop the first Arduino/RaspberryPi class devices. Still up to date and currently busy polishing a ShowHN which will blow you off your socks.
Everything nowadays is shrink-wrapped out-of-the-box, hidden behind layers of frameworks. Programming languages becoming a fashion statement. Everyone seems to copy-paste stack-overflow and even then the answers are like "Why?" because it seems nobody reads specifications.
But...
Finding a job position is impossible.
The excuses for rejection range from unbelief to insulting.
It is so bad that I have now seriously considered leaving the field, taking 40+ years experience with me.
> It is so bad that I have now seriously considered leaving the field, taking 40+ years experience with me.
Please don't. We need more people like you to infuse much needed energy in a field/profession that is becoming mundane and steadily going downhill day by day.
> The excuses for rejection range from unbelief to insulting.
I was once rejected because I did not know inane crap like what "this" is bound to at the top-level in JavaScript. Their answer: "the window object". a) Yeah, okay, if your code only runs in the browser. But not nodejs. And b) if anyone uses a top-level "this" it's an instant reject in code review from me.
Ultimately, a lot of these interviewers are waving huge warning flags saying "stay away!"
Even FAANG. Every single algorithm there is a "trick" to it. Once you memorize that trick, every leetcode becomes trivial. But it took a guy like Knuth some 30 fucking years to come up with that "trick". It's so goddamn stupid memorizing bubble sort when every language has a built in sort you're going to use. And if you ever see a developer writing their own algorithm for bubble sort at work, you're going to think something is wrong with this person. What the fuck are you doing guy? You're going to get it wrong and there is a library for all of this, used by thousands of people with hundreds of bug fixes.
I left two years ago and have been largely pursuing my own extended interests. One result is that 90% of the HN postings seem to be absolute wastes of time (to me at least.)
> Finding a job position is impossible. The excuses for rejection range from unbelief to insulting. It is so bad that I have now seriously considered leaving the field, taking 40+ years experience with me.
Before you do, are you up for a Zoom call or something? Talk about anything you're passionate about, and perhaps we'll post it as a show HN.
I'm 31 myself and at the beginning of my career (I've been longer in the education system than most).
It's because the business people got interested and are increasingly taking leadership roles. As an engineer who has shifted over to the product management side I can safely say business people suck fun out of stuff for a living. Margins, cost savings, metrics to manage, each and every slow step of creating a new, less fun, normal erodes a culture built on making "Something cool" or "Just for fun".
Worse yet is when the business minded masquerade "Fun" activities as them still being cool such as hackathons. The sad truth of the matter is that this is what happens in a maturing industry. A lot of the green field money that sat around for Facebook and Google to gobble up has been eaten. The remaining scraps are enough to prop up small startups, but really only until they get absorbed into the giants with fat checks for the founders. The regular workers get conformed into the system, with assurances "Everything will totally stay the same" as they slowly change everything.
Businesses exist to make people money. Engineers are great at solving problems and innovating. Business people are great at squeezing every last drop from those solutions till only a husk remains. To be fair to the business people, myself included, if you do anything less than squeeze for money as hard as you can, you get beat out by the competition who copy you, and nothing is as not fun as being jobless. The more and more people who get coding knowledge the more and more being a coder will be just like every other engineering position. Someone who executes. Which is why I bailed and got into PM so I could actually have a strong say to the business in what we execute on.
To end on a happy note I have never seen more people getting into robotics clubs, trying to make small static sites, learning the basics, and I am certain that every day more and more people are running their first hello world programs. So I think there some ups and downs to everyone learning coding.
Agile/Scrum was the biggest bait-and-switch con out there - developers thinking the methodologies would empower them while in fact being a vector for the worst excesses of micromanagement. I feel less empowered now than I did in my earliest days as a junior dev.
Whats driving business types to think leetcode is a good test? This should be an easy conversation with HR. I think software engineers want this arbitrary barrier.
Honestly this is probably because other businesses started doing it. When businesses have no clue they look to the market for the "standard" way of doing things. We don't make mechanical engineers design mechanical solutions for fun.It is just a consequence of the early culture of "hackers" and people who do that stuff for fun and for work. Hopefully dies over time, but it is unlikely given that now seems like the standard thing to do. Businesses are not rational thinking creatures. They just do what feels like lower risk if they can.
Leetcoding involves preparation for known problems and churning out solutions in least possible time. Most of the business have problems along the same lines (think of CRUD, authentication, authorization, UI animations etc ...) and they think people who excel in the former might do well in latter.
> Our industry feels like it's in the decline of the Roman Empire right now. ....
And here I am, writing a desktop native app that targets a small niche of users, with no marketing, no advertising, and we've had our strongest year yet, and overall usage just grows slowly year over year.
Maybe it's how you think things ought to be that is misaligned with reality, rather than "the decline of the Roman Empire".
The thing is, it's not one household. Every other company I'm in touch with in the audio software world (quite a few) had a banner year. Yes, the pandemic helped us by forcing lots of people to be stuck at home and turning to that song they'd always meant to record/write. But it was the icing on the cake for a market that generally continues to improve, despite stupid levels of competition.
Now of course, if by "household" you meant "the entire niche of audio software", then sure. Or maybe even more broadly, "the entire niche of creative software", then even more sure.
But these are not tiny niches, even if they are small.
Yikes, tried to use Ardour multiple times back in the day (I used to work as an independent radio producer and sound engineer). Classic open source desktop software in that it promised the world, but in practice was extremely difficult to even get to install, and reliant on external packages that were themselves glitchy and baroque (I believe Jack was the common issue in this case).
The prebuilt binaries of Ardour that we supply have no external dependencies except for libc, the native window system (X11, Cocoa/Quartz, etc), and libstc++. Since Ardour 5.0, JACK has been optional.
Every week, more or less, someone tells me that Ardour is a piece of shit, and someone else tells me it's the best DAW they've ever used. I gave up believing that any given DAW could ever make everyone happy about a decade ago.
Source is always available without cost. Pre-built binaries are available via a pay-what-you-want pay tunnel. Subscriptions are encouraged to allow us to continue developing the software. We made on the order of US$200k this year.
>Companies are trying to hire more outside of California in order to lower wages across the board.
Lower labor costs mean lower costs passed on to the end users which means more products in the wild which means a bigger industry. It's only a problem if you're worried about being out-competed by "those hicks in the flyover states".
Techies complaining about companies moving out sounds a lot like the guy who worked the UAW system for 30yr so he could land a buddy position where he does nothing for $60/hr complaining about non-union factories and companies moving to Mexico. In both cases it's a tacit acknowledgement that the gravy train is unsustainable.
Yeah wages might be slightly lower in 40yr but that's a reflection of the difference between being an electrician in 1910 vs being an electrician in 1950 after the last of the line shaft industries had long been converted, once all the heavy lifting and low hanging fruit has been picked there's just a lot less cash sloshing around driving up prices and wages. The people who just want to be mediocre and punch a clock will still make a decent wage but the difference is that mediocrity and job hopping aren't enough to make you big bucks in a stable industry like they are in a rapidly growing industry flush with cash. In a stable industry you actually have to be worth the big bucks.
It's hard not to see Bay Area software developer wages, especially at the big "tech" companies, as something of a bubble. They're completely out of line with engineering and science jobs more broadly, including software engineering jobs in much of the US.
Which does suggest that someone going into software just for the money or, as GP or so commented, going through the motions and spending all their time prepping for Google interviews may be chasing a pretty transitory target.
Historically there's very little to suggest that the segment of one profession that's largely in one geographic area can sustainably capture super-premium compensation even though it doesn't really require a higher level of skill than many others have throughout the country (and the world).
And the fact that a lot more flexibility in living location has come in essentially overnight means that a lot of companies are going to start looking more skeptically at some of the premiums they're paying.
This is the result of a war that was fought two decades ago and the hackers/coders/sysadmins, the people to built things, lost and lost big. It was the dot-com crash. Looking back it's absurd. Everyone was convinced there was this big bubble and everyone got caught up in the irrational exuberance of the future of computing. But was it really? The real financial damage was done by the likes of Enron and Anderson consulting. If it was so irrational why did that supposed bubble give rise to some of the largest companies that now exist? Because it wasn't. That's why we spend the next two decades wringing our hands and fretting that there was another bubble right around the corner. This never happened. Why? Because there wasn't a bubble in the first place to worry about repeating.
What did happen is a ton of people lost their jobs and those people, passionate about what they do, kept right on doing it in the form of open source software. Google, flush with cash, hovered up talent for bargain basement prices. The board room got the message that software was eating the world and if they didn't do something quick the people to wrote the software and built the systems might want a say in how those companies were run. So they outsourced what they could and doubled up what they couldn't. The message was clear. I don't need you. I've got a second one of you ready to go. The waged a war on GPL calling it "viral" and "insidious" and convinced everyone it would be much better to use more liberal licenses that would allow them to build and sell products.
The war was lost when they convinced you that management was "icky" and you didn't want that boring old stuff. You wanted to be coding so they hired the MBA to be the scrum master. The result is you were cut out of the decision making process. Your only input was on a technical level and even there you were kept a close eye on. Some people would even proudly exclaim that they liked this system because they thought they were winners based on their slightly higher than average salary all the wile cranking out multi-million or even billion dollar software for someone else. Doug Cutting, the creator of Hadoop and basically everything that was to become Cloudera was only given a job. They made so much money even they were embarrassed but only embarrassed enough to allow him to keep working for them.
You lost and they won and this is the result. You're made to jump through these absurd hoops because it's cheaper to create these pathological systems and waste your time than to do something more efficient.
I feel a common thread in the events and behaviors you describe is the prioritization of decisions by valuation, IP, and boundaries over execution, progress, and flow.
Maybe the only way out of this mess is for business schools to start teaching new metrics for the latter category.
Companies are trying to hire more outside of California in order to lower wages across the board
This could turn out to be a very good thing for the country. It's a social & economic problem if all the money & opportunity are squeezed into just one metro.
> This could turn out to be a very good thing for the country.
Once you cross the hump to not seeking physical proximity when seeking to minimize labor costs, there's very little reason to go to the rest of the US once you leave the SFBA.
Have you ever looked at the map of US HP campuses in their heyday? Dispersed across the country, with regionally clumped physical proximity, a foot in numerous labor markets and all tidily within a couple timezones.
You might think of HP as a California company but they had large engineering hubs all over the country.
Have you seen the offers for remote work? Almost every one is "remote (us citizen)", "remote (same timezone)", "remote (monthly onsites)". Unless the companies are prepared to open whole divisions with colocated management in other countries, the jobs are staying local.
Anyone who has worked with remote programmers, unless they happen to have hit the jackpot on them, really has no desire to ever do it again. Timezone differences, language differences, cultural differences, communication differences, etc, etc, all combine to chew up so much more time and money than the nominal savings of hiring someone local. And the good remote people don't cost appreciably less anyway.
After a decade or so working remotely I'd describe that differently. If someone working remotely finds a company with culture where remote work is fully functional rather than something odd that people have to work around, they hit jackpot. Unless everything's documented online, every meeting is online, every water-cooler chat has a link published, etc. then remote work is going to suck for everyone.
You seem to be agreeing with the parent. Large timezone differences, cultural differences, and language differences can be real remote challenges. (Although, in my experience, US--at least ET--to Europe works pretty well. Takes more to coordinate Asia in general and probably want to minimize the amount of synchronous communications.)
Many of them definitely won't, but daylight and the location of management's homes are still limiting factors to off-shoring. Synchronously managing people in distant time zones is no fun, and trying to do it asynchronously is really inefficient. There may be a solution to this 'problem', but until they come up with it, letting people work remotely from their homes in the same city isn't a slippery slope to all jobs being off-shored.
Or, probably more accurately, it is a slippery slope, but not a very steep one. I do believe that jobs (and wages) are going to get distributed differently in the future. But, I'm hopeful that it'll be an improvement over having every high-paying job be in the same 5 dystopian cities.
I would say is that a lot of hard problems (of last 20-30 yrs) are getting commoditised (e.g. S3, DynamoDB, Redis) and barrier to entry reduced. This would mean increasing the work is "glue & pipes".
> Google kills products that make customers and engineers happy and doesn't spend enough effort to make them better.
Heck, as far back as 2010 I got a promo at Google because I was the only one on the Google Maps data team (or the org) who wanted to keep the data up to date. (Also the only one who wanted to live in Seattle -- which might as well have been Siberia to them.) So they shipped me up there and gave me a team. It was like somewhere, deep down, they knew it was a good idea, but each person could forcefully argue why it wasn't -- so that it didn't have to be them.
It was great! Well, other than encountering more of the famously toxic culture, where people get promoted for being smart but nasty. But I'm sure that little problem has been solved.
Could it be that this is a very SV problem?
I'm from a European state, I know some people doing programming in Asian regions.
What you are describing to me sounds like a bubble. Or I am in a bubble, IDK.
Yes devices can do less than 10 years ago (less arbitrary thing), but they can also do more than 10 years ago.
Of course the market in this segment might give you the feeling that everything is dumbed down. These devices are not used solely by very smart people.
The most basic of all humans has a phone nowadays. And If apple decides to make MacOS only run singed binaries. That shows that they are targeting people who do not know how to run arbitrary code safely. I am a programmer and when I have to do that I have to think really hard. If my main PC runs stuff that I would rather not like to leave my house. I have to set up a VM and check it beforehand.
You still have Linux to do whatever you want.
If people in the job market and Open Source community are getting exploited, it is only a matter of time until something develops to create a force against the exploitment.
There are unions (at least there should be) and there are multiple ways to fund Open Source nowadays (Patreon, Gitcoin, Bountys,...).
It doesn't seem to me as everything is moving backwards. It is getting harder to live out the freedom of the individual. But on a macro level, I think things are moving forward.
Yeah, a lot of posts here seem to be trying to say the following, but they don't want, or don't know, how to word it:
Technology was made accessible for the masses. That means 100 IQ people. And then it was refined so the 85 IQ people could work most of it. I have no doubt that if you gave standardized IQ tests to every reader of Hacker News, you would not see much of an overlap with the bell curve of the American, or even world, population.
The people coming here are generally very technical, very smart (I'm defining this as at least one standard deviation above the norm, so 115 and higher IQs).
Most people aren't going to build their own enormous media server from used enterprise gear. Most people aren't going to build their own home surveillance system even though the hardware and open-source software out there exists. I could list another hundred projects for which we have specialized "consumer-friendly" devices.
Watch the YouTube video where Jordan Peterson talks about working with an 85 IQ individual and how it was a struggle for that person to consistently and accurately fold a sheet of paper into thirds and put it into an envelope. And now realize that for many of you, that's someone for which you're developing.
> The Internet now treats everyone using it like we're all brainless idiots to be injected with dopamine. Like we're not smart enough to choose how to consume it.
The problem is that most people are. Look at the statistical breakdown of intelligence. Half of the world is 100 IQ and below. Half. Hell, 16% of all people are 85 IQ and below. That's over a billion people worldwide.
Any technology that you want to see enormous widespread adoption of, has to be usable by some of those people.
And believe me, no business-minded person wants to throw a billion potential customers to the wayside. They want to simplify the technology to capture those dollars.
Sorry if this offends sensibilities of anyone, but I guarantee you if you could get inside the heads of a lot of these billionaires and multi-millionaires, you'd hear the same shit I'm telling you right here. The reason I know this is because my Uncle is one of those people. Smart. Ruthless. And has absolutely no qualms about exploiting people of lower intelligence.
Don't think for a minute that the SV crowd is any different.
Goodness, you and the OP have really hit the nail on the head.
I spent the last 5 years quite happy at a simple dev shop. Then they hired a bunch of people, paid them more than me, and allowed them complete free reign to write what ever kind of code on some brand new projects. After a year of this, one person quit mid-project, another died mysteriously (covid?), and then another just recently quit. My boss expected me to just pick up the slack on these three projects that were written in the most arcane and buffoon way possible. I basically just said no, and left. I had already been driven half insane over the year just trying to figure out the crap they were committing.
This was in the spring and I'm still unemployed. I'm mostly Java and some older languages, and was really looking forward to jumping onto python and django. But it's been a struggle really learning django good enough to interview for without any good experience behind me. I have a family and on top of covid issues and this year in general, sitting at home trying to learn a giant web framework is not very motivating when I could be spending it with my family (which were already severely affected by all my time I "wasted" going above and beyond at my last job for 5 years).
I just recently did an interview for a small django shop that didn't even test on django. Instead, I was given a half page of python code and asked to "fix" the problems. No requirements or tips. There was a syntax error, a bug, and a few cosmetic things.. I managed to find 8. All this while being stared at over Zoom. I was informed that "junior" devs can find 10-12 "problems", but they only hire those that "find" more than 18 (apparently 25 is the max).
I still got the code and look at it every now and then. Half a page of code that does nothing but take a list of "item" objects and print out an aggregate of a total price by item type. A loop over nothing but:
total[item.type] += item.cost
Of course there was some random data mangling above and below that, but that is the logic. Find the problems?! Should I raise errors or use a namedtuple or defaultdict? Half a page of code that could have just been a Select/Group by in SQL. No senor dev should be summing data like that. Sadly they said the code was from "production". They have "interviewed" over a hundred people in this year and hired only 1. All this for $45/hr 1099.
In the beginning, I briefly thought I could use my savings to start some kind of business, not sure what. But I've blown most of that just paying the bills while I "interview".
I used to love software and would dream and breath it. But I've never been so unmotivated over these last 6 months. I'm debating on just applying at a local small town municipal IT job for $30 an hour. Giving up basically. Just show up at 8am, answer the phone mindlessly for IT "problems" and tell people to try restarting their windows machine (at least 3 times minimum) and screw of playing solitaire the rest of the day. But it seems so pointless and waste of a life. But even that doesn't motivate me, but just makes me more depressed and even slower going.
Your comment highlights so many problems with our industry so poignantly, and at the same time is an extremely sad personal story...
I don’t actually know what to say as encouragement but I do feel for you :(
I was in a similar position to you on your last job, and after looking at every single company I could think of in my city (London) I ended up finding just one that seemed good in all possible counts...
Maybe there is a company out there that you’d like to work for? My approach was to filter by the product, and only look into working for companies whose end product I thought was good and interesting.
The Django shop test had nothing to do with your skills as a developer, and everything to do with language gatekeeping. It's just overcompensating for boring work and poor pay. It's no different to how the gaming industry exploits workers.
Don't give up. And for the love of all that is holy, don't work municipal IT, it would only demotivate you further. Keep at it, improve your skills and keep applying.
> Giving up basically. Just show up at 8am, answer the phone mindlessly for IT "problems" and tell people to try restarting their windows machine (at least 3 times minimum) and screw of playing solitaire the rest of the day.
You have a very holier-than-thou view of small scale IT work. There are a whole lot of problems to be solved at this level, many of them created by the people working the positions you're currently interviewing for.
Yeah, this echoes my experiences interviewing. Spent 6 months looking a few years back
It’s just incredibly demotivating to hear all the self-professed hot shots shit all over your past 10 years of delivering unambiguous value because you don’t know that [] === ‘’ is true in Javascript.
I finally found a position that’s financially great, but it’s more in spite of their dev process than thanks to it.
Is there anything you're passionate about? If so, why not spin up a website on that subject?
Django is pretty easy to learn. Model view Etc in Python instead of Ruby. Not rocket science.
Building something you care about will force you to dig into the details and become enough of an expert in a few weeks to get in the door somewhere where your skills will be appreciated.
That probably won't be Facebook, Google, or the next Silicon Valley unicorn. But there are a lot of other places and other Industries where interesting things are going on.
It's a numbers game, learn from mistakes and continue to the next interview. Eventually you have seen them all and you will pass the gatekeeping. Steel in forged in fire. After hundreds of bullshit interviews, nothing surprises me anymore and it's just all automatic process now.
I haven’t had anything quite that bad, but I’ve had an interview where I was being tested on SQL, but the interviewer didn’t actually know the SQL keywords I used.
It happens. It’s a strong sign you want to work elsewhere anyway. The problem is one of finding the right Elsewhere.
This sounds exactly like a job I interviewed for a couple of years ago, a Django shop. I'm skilled at Python but the questions were ridiculous. I feel like you probably dodged a bullet and don't want to work there anyway.
I’m spending some time in Constantinople right now, if anyone wants to spend some time lamenting the fall of the Western Roman Empire together. That is, after the weekend plague curfew. Email transitively in profile.
> Google kills products that make customers and engineers happy and doesn't spend enough effort to make them better.
Small correction here: The non-paying users are not their customers. So it’s understandable that they kill all products where they don’t have any ROI. As another user here put it recently: Ads are like a hose where money pours out. And they’re desperately looking for another such hose.
And yet, there are still so much value one can create with software... A lot of it is even outside of the reach of the spy and divisiveness as a service companies, it's the kind of thing that if they touch it, they destroy it.
The late years of Rome is actually a great metaphor. We are suffering from human capital loss, and have signs of institutional collapse. A shock can destroy our institutions and throw us into something like the early Medieval period: much less wealthy at the beginning, and messy too, but fast growing and with a much higher ceiling than the previous age.
This doesn't feel new to me. I entered the industry in the mid-90's, so I have no reference from before that period. But I'll cherrypick a few items:
> Microsoft is building VSCode for the cloud. Few people own desktop computers anymore.
I heard the same thing in my early years about these newfangled HTML email clients. Email should be consumed using Pine or Eudora, just as God intended.
> People job hop for promos, raises, and resume fodder, not because there's an actual interest in the product.
Oh yeah. I did this for the first 15 years of my career. It was faster to get a promo by changing jobs. I didn't care where I worked, as long as the company name had prestige. I kind of still do, but I transfer internally. Same effect, but I get to keep my vacation accrual.
> Companies are trying to hire more outside of California
In my early years I worked for a company that used Russian developers for some non-critical parts because it was cheaper to fly someone out there once a quarter than it was to hire the staff in CA. This was before the massive rise of outsourcing in India. See the Dilbert cartoons about Elbonia for more.
> The web is turning into shit.
Heard the same argument about MySpace. And Geocities before that. And AOL before that.
There are so many pieces of software that are latency dependent. Aspects of them can be in the cloud, but I doubt we will ever truly lose track of bare metal. Right now I'm hoping for a real time OS that has enough of the common apps that most people are happy, but that satisfies the speed requirements necessary for digital audio, lighting controls, and other tangible and interactive behaviors. Hopefully the natural world's fundamental interactivity and tactility in real time is something that we all consider going forward enough that the cloud / thin client model becomes only a part of our human system.
I've tried out Google's beta with assasin's creed, and the results weren't promising. I had gigabit fiber and while it worked pretty well for the most part, I still got quite a few gamebreaking lag spikes and fps slowdowns. It stuttered like a youtube video: freezing, then resuming in 144p quality which made the in game text completely unreadable on my screen. And that's on a beefy internet connection, imagine the situation for the median American or someone reliant on a mobile data plan. People can scarcely tolerate playing a game with high ping as it is.
I've ran my own cloud gaming VM on AWS and with an enterprise connection (1ms latency to the AWS datacenter) it's been good enough to play multiplayer shooting games and maintain a positive kill/death ratio against those who play locally.
Maybe the problem isn't that it's impossible per-se but that the consumer-grade services underprovision their machines/bandwidth, or that consumer-grade gigabit fiber isn't actually that good (or problems in the "last mile" like using Wi-Fi instead of good old Ethernet)?
People can scarcely tolerate playing a game with high ping as it is.
People who classify themselves as "hardcore gamers" perhaps, but those people will also drop upwards of $1000 on a graphics card. They're not the majority in gaming. Most people will happily play a game even if there are a few problems if it's cheap and entertaining.
Anyone will throw a controller across the room after putting a whole clip into someone taking no damage, watching them rubber band across the map, and pistol whip you in the head. That's your life on a crappy connection in most FPS games which are some of the best sellers every year.
The technology to "move gaming to the cloud" was around at least a decade ago, when Gaikai started doing zero-day "play this game in your browser via Java". It worked well then, it works well today (HN had a article several months back by a sort of follow-up to the Gaikai concept). The problem is convincing gaming companies to actually use it(they have some good reasons to be concerned).
I think the real issue remains latency. Gaming companies are using it but the users don’t want it. Try playing call of duty or doom over the network and it’s going to be a terrible experience.
Doom is on there, but I wouldn't say the experience is great. I've played it both locally and on Stadia and while a quality-inelastic buyer might be OK with it there it just doesn't match up for a serious/invested consumer. And that's totally fine; not all things have to be for all people. But it's a worse experience once you know what you're looking for, and will stay so.
And, as a TO for fighting games, there's no substitute there for the barest minimum latency possible (to the point where older games legitimately feel better because you can play them over analog connections to a CRT).
The optimist in me says that cloud gaming will expand the category, not move it from local to cloud. Cloud gaming can't beat the laws of physics, and cloud hardware isn't free. So action/fps games will always have a home on local hardware.
But cloud games have an advantage too and maybe we'll see new kinds of games/experiences that are not possible with local PCs.
> Employees aren't excited by what they do: People job hop for promos, raises, and resume fodder, not because there's an actual interest in the product.
Welcome to the other 99% of humanity. Work sucks, but someone has to do it.
>Few people own desktop computers anymore. Apple is locking down MacOS to signed binaries. Soon we'll all have thin clients and will write software in the cloud for the cloud. Few will be able to learn how to engineer at home anymore - you'll have to go to a university or trade school. Building a simple website will require JS package management, kubernetes, and AWS. The "free tier" will fall away.
Building a simple website is easier and cheaper now than it ever was.
When I was a kid, I dreamed of being able to have my own domain name and an account on a shared server where I could run CGI scripts. Now most people who can afford a laptop can afford to host their own website on a virtual server.
You can arbitrage AWS with your own servers as long as network costs don't eat you. Run say a TravisCI type service on your own hardware?
The big lockin is network pricing. No egress fees when their data is already in S3. You have to run where the consumer has their data or you eat that network transfer as overhead for your SAAS.
I see GitHub slowly charging for egress downloads as the next lockin. You "save" by paying for builds on Azure.
We have people who claim to be engineers but start thorwing a fit when they're required to do unit testing. (Aka the anti-vaxxers of software engineering)
Yeah, I burned myself out really bad trying to go above and beyond for a few years at various companies. Just ended up frustrated, making no more money than people coasting in the same position, and still got laid off during downsizing instead of the people who spent time playing office politics and going out to happy hour with the supervisor.
I feel kind of guilty now though, because I actually managed to get hired at a really good company a few years ago, but I can't work up the motivation to put in as much effort as I did before. Now I'm the one coasting (still not schmoozing though), and see other new people making the same mistake I did.
In my experience "going above and beyond" tends to get you more work and responsibility for roughly the same pay. I did get the occasional 5% annual raise instead of the standard 2-3% that most of my coworkers received. Even then the raises were usually more dependent on how well the company performed vs how well I performed.
I've noticed this a few times in my career and have had to start slowing myself down at times. If I deliver in a day instead of the expected two for example, I don't get that second day off, I get twice as much work and get paid the same for it. The harder I work, the less I make. If they want me to bust my ass and sacrifice sleep I need to be given hazard pay.
You're right, and as a result I try to work no more than 4 hours a day, preferably less. I take every possible opportunity to extend timelines, create buffer, and reduce scope. I'm highly incentivized to farm as much time as possible, so that's what I do.
I try to target obscure projects that I already know how to do, where there's an assumption that nobody really knows how to do it because it's obscure. Complexity and obscurity are great cover. Picking up legacy projects on old tech is a good way to do this. "Oh no, PHP sucks! Nobody's touched this code in years! Not to worry, give me a couple of days I'm sure I'll figure it out." Now my estimate is 3x longer than it would be if I was working in the areas under normal development.
I've also got my notifications pretty dialed-in so I never appear absent when someone needs me. I prevent slack from marking me idle. I turn my notifications to a more aggressive setting when I want to take a nap.
Nobody knows how long it takes to get a piece of code working, not even other programmers, so who cares if it takes a week instead of a day. Sometimes I keep a local branch that's represents my actual work and a second branch for pushing to the team. If I get in "flow" and want to get something done in a block of many hours, I can drip-feed the commits over a couple of days instead of dropping a PR at 2am and having everyone think I'm free to work on something else tomorrow. With a little shell scripting, I can make commits and push on a timer too, which is sometimes useful if I need to "work late" because everyone is stressed.
When something blows up in prod, I put in the extra hours with a good attitude. That helps create the perception that I'm the go-to person for things and a team player, so it's not surprising to anyone if I'm running a little late on a deliverable because I had to drop everything and help with something important (another way to add more buffer). I also try to pair sometimes, especially with new coworkers, so that they can see me working in short bursts. Pairing serves as a psychological anchor that I must work that way all the time. After all, I don't want people thinking I'm lazy.
Sometimes mistakes happen and I do get stuck working an 8 hour day, but those mistakes would have been 16 hour days if I wasn't actively avoiding doing as much work as possible.
As much as I can stomach it, I try to use the extra time to socialize with coworkers to help raise my visibility and build allies. That's the smart thing to do. In reality, I mostly play video games, do housework, and anxiously wait until work is "over" for the day so I can detach from my notifications.
Has tech turned me into a sociopath? Maybe. Do I feel like a prisoner in my own home? Certainly.
But if I don't use this strategy, I'll constantly be over-committed, burned out, salty, and missing social connections with coworkers that are more valuable than the actual work.
I can't wait until I have enough money to be financially independent and never have to do this nonsense again.
I've started my first dev job earlier this year at a small company, around 10 people. And it scares me that I already do this.
I used to deliver as quick as possible and working my ass off and finding that the only thing it got me was a little praise and that more was expected from me the next time. Now I'm browsing HN during work time still delivering within deadlines, just not a week ahead, and most importantly, I feel like I'll be sane doing this work for more than a year.
What brought me to do something similar in a former job was, that I realized it only hurts my coworkers when I do more than the average.
The management would say to everyone with performance below average something like: "How can we help you to improve your performance? What do you plan to improve your performance?"
The result was that most people stopped working once they reached their goals because otherwise they would only increase the average^^
>I can't wait until I have enough money to be financially independent and never have to do this nonsense again.
There are a lot of people operating on that plan. Mostly it doesn't work out for them.
Play this forward ten years with a family to support and a mortgage which committed you to personal inflation and a track record of ...? You can absolutely fool people for a week or a year, but a decade of non-experience will stick out like a sore thumb. Experience compounds, and the one you describe is compounding down. Do this for ten years and you will be much less accomplished than you could be.
> Play this forward ten years with a family to support and a mortgage which committed you to personal inflation and a track record of ...?
Being an excellent employee?
I understand your point, but I actually have been doing this for about 10 years now, and I consistently have improved my "career trajectory" by switching jobs when I start to feel that my coworkers are overachieving and throwing me under the bus. I look at it like a forcing function to switch jobs and get a raise.
I already had a decade of pre-work experience just from being a lifelong hacker, so it's not like I'm relying on my job to learn new technology. I don't have a fear of falling behind. If anything, I've noticed a huge decrease in SWE competence over my time in industry.
Some of my most "successful" friends at FAANGs are bad developers that just devote more time to playing the system than I am willing to do. I find the social con-man stuff to be really draining and I hate doing it. I also hate interviewing, which limited my career more than I'd care to admit.
Also, I've opted to not support a family or carry a mortgage. I'm doing something similar to FIRE. I'm hoping to be FI with a total of 15 years as a tech employee.
"But do you really hate working so much that you would sacrifice having children!?". Yes. Very yes.
It's also likely that tech workers are "overpaid" right now, as we're compartmentalizing more work, lowering the skills required to join tech companies, and remote work is now the norm. It's a race to the bottom, and I want out as soon as possible.
I SO agree with this comment! Nowadays the only place in which I'm incentivized to deliver as quickly as possible at my personal project/micro-ventures. But at work I also work 4 hours or less, and those 4 hours are after I have worked and given my most productive/creative time to my projects.
So, if less than 4 hours and whatever is left of my brain is enough for my company, that's all they'll get
This sums up perfectly why I’m pro universal basic income. How many people do this? Think of all the collective brain cycles wasted. We’re stealing from our future. You’re clearly smart and capable. Work you don’t find rewarding stole your motivation. If you could work on projects that reflect the world you want to live in you would create something much more valuable top society than whatever it is you’re half assing now.
I agree, but I think the reason we're unlikely to see something like this no matter how much evidence we present that it is better for everyone is that people with money and power generally got there because they craved money and power. Owning people's time, even if that time isn't being spent productively for them, is as close as they can get to owning people themselves and they desperately crave the power to own people.
I'm not for UBI but I totally get & agree with the reasoning behind it; including yours here which I think is pretty dead on as to why it would be beneficial (in theory). In fact the "stealing from our future" part jumped out at me as similar to the way I think of societal debt cycles (the kind Ray Dalio talks about in his books - short-and long-term [~10yr; ~100yr] cyclical sine waves of waxing & waning [in/de]flation). You probably would avoid taking on a ton of debt during the peak of a given credit cycle (when rates are at their highest %), especially if you know you're simply fking yourself that much harder than if you were to take on the debt at some point in the future, when rates are much more likely to be low, and thus save you a ton of money in the long run.
Same thing with putting in extra effort at work. No reason to actually take on the extra hustle if it pays off minimally when all is said & done anyway. Better to say no thank you, I'd rather not take on a burden of effort-debt yet and wait till it makes significantly more sense to do so
Working hard for a raise/promotion is a losing strategy. Working hard so you can change jobs every 18-24 months with big salary jumps is rather easy to do consistently.
Trying to get a promotion is deciding to compete for one position in one company with essentially every qualified candidate in the world. It’s easy to see how looking for a better job every so often has better odds for success.
I don't think so at all. I have worked hard, and had a lot of fun at now two of the FAANG's. Sure the reward has not been like winning the startup lottery, but if you told myself 20 years ago I would have this impact and earn this much money I would not have believed it. I totally suck at politics, and have seen others rise quicker, but doing good work does get rewarded in my experience.
Back in the day you wanted in to get shares before they went public. Then the dream was to cashout and using your google money you can create something. Then people stopped getting stocks but used it to get funding. Then there are the people who get in any position for less than 2 years and use that expereince to get a CTO job at a smaller org.
Why do you consider it your endgame? Top salary? Interesting problems? Making a difference?
This is an interesting question. I moved into to IT/Security from another sector, and I'm trying to figure out my endgame. At least at my company, there aren't any jobs I covet. Most of the higher ups don't impress me, and they don't seem to know what's going on in their company very well. It seems like if I moved into leadership, I'd have to spend a lot of time lying-via-powerpoint. (that is, taking a complex problem, and both simplifying and misrepresenting in a powerpoint which shows "progress" happening.)
I wasn't a loser in my old career, and I don't want to be a loser in tech. But, it seems like everyone is a loser here. IT/Security is seen as a well-paid janitor; someone you need, but not someone you really care to learn about. Worse, becoming "important" in a company seems to be useful only in so far as you have sway at that particular company. ie, it's a lot of work for some very local, and very useless prestige. And worse, there's no external meaning other than your own status. Why do I care if I have a little fiefdom within company walls? Nothing worthwhile is being accomplished, it's just more sales.
I think endgame is considered differently by different people, i.e. endgame for me is financial independence through micro-ventures thus FAANG, which I'm considering right now would just be to pay the bills and create a comfortable financial buffer until I can leave them taking with me the ex-google/facebook/netflix badge and cash on hand.
I honestly think you can do it if you want even not knowing much about you. People there are not all special. If you want some tips or a referral let me know, email is my username @ gmail.
I guess this observation doesn’t really apply to the FAANGs quite as much. They have such an insatiable demand for labor that it’s much easier to work your way up to more money consistently over time.
I guess you just find the level you want to coast at. I haven’t won the start up lottery either. But I have been able to be fully employed as a contractor with a very good hourly rate for quite a long time. Which probably means I’m coasting right now. But I still manage to bump my rates up every so often, so maybe not.
Seems like you are doing pretty well. Coasting means different things to different people, do what’s right for you. Just make sure there are no regrets later, life is too short for that.
Sometimes that means coasting and spending more time on your hobbies or with your family. Can’t see anything wrong with that.
I honestly think this is a myth propogated by managers to discourage negotiation
They know the game, no employee ever is going to stay if they're being paid half their market value. "Commitment" my ass lol. But more to the point in order to replace you they have to pay market value for your job. They can only find someone cheaper if your job is beneath you.
Parlaying offers is fine as long as the work they need doing is worth that money. Who are they going to replace you with? Hiring is expensive even if they find a sucker. The only risk is if your market value is higher than they need to pay to get your job done.
maybe, i'm not saying employees shouldn't negotiate but there's a lot of ways it can backfire so you might be better of hopping to another company at that point, rather than waiting around to have the rug pulled out from underneath you
I agree, but it's still cheaper to counteroffer than to hire someone new if the demand is market price for that job. There's big overhead in replacing you.
Fundamentally the operative variable is: "can they get your job done for less than you're demanding." That's what matters, more than the impression of commitment.
When I was a hiring manager at the previous company I was at, I gave an interview where I gave an exact description of what I wanted coded. No algorithm tricks (you could solve it faster with a paradigm, but it wasn't necessary) actually this is a problem I remember having to solve for homework in intro HS CS class 25 years ago. I was checking to see if the candidate could
1. read documents.
2. ask questions.
3 identify corner cases.
4. identify why the problem was hard
5. actually try out their code instead of just thinking about it.
One candidate used a very troublesome technique to try and solve it, and proudly declared, "I am sure this works". I knew it didn't - but it took me one hour to find the bug, and in order to find the bug I had to write a property test. This is SUPER dangerous behavior IMO. Code Reviews will not catch everything, so if you have a dishonest coder you can wind up in trouble. He got hired for another team "this is literally the best hash table I have ever seen".
Unfortunately all of the candidates were clearly folks who had practiced their leetcoder skills. Nobody completed the problem correctly. However, I was okay with partial answers that fulfilled some of the softer qualities I was looking for The other folks who were interviewing gave one of the candidates who bombed my part rave reviews. I got steamrolled into hiring him onto my team, and sure enough he didn't read documents, he didn't try out his code. In the month that I worked with him he did not push any code. I left.
This is really interesting. On a previous company my coding test was "build a contact manager application with python and Vue.js" and I really loved that! It was something I could do in less than 10 hours or so. The role was full-stack web dev and I got it.
I've been considering screening companies based on what their hiring process is. How do you think that could be assessed, say, companies that eveluate real-life experience vs. leetcoder skills?
One company (fairly well known) gave me a homework assignment to write the snake game in JavaScript. It was pretty enjoyable, and feedback was that the hiring manager/team loved my coding.
Then I got invited to the onsite where I was subjected to multiple stereotypical leetcode rounds. Got rejected.
one of the companies I interviewed at had a question where they showed me a bug in what looked to be an old version of their UI and I had to debug it as a pair with them piloting. I didn't get the job (probably in part because as an "almost totally backend" it took me a bit of time to decide to look at the web console), but it was literally the best interview I'd been on. It really exercised everything you could possibly want to know about a full stack dev, and was done in 25 minutes.
I wish companies like that would be easier to find!
From the feel of this thread it seems to me that a company that explicitly states on "Who's Hiring" that they don't do leetcode, but do actual pair programming for evaluating candidates would have an advantage above the rest!
My PL of choice is Elixir. I had zero interviews with leetcode questions, but there was one where they asked me to verbally describe how a hash table works under the hood, they didn't seem to care too much about the answer so long as it was ballpark and you said "O(1)" or I think I said "fake, amortized O(1)".
This is inconsistent with my experience in my most recent round of interviews.
I interviewed at a few places at a senior/staff level, and most of my interviews were behavioral, architectural, or discussions about past work. The few leetcode-style or coding questions I had were easily prepared for from my ~40 hours of interview-specific coding prep.
There is zero chance I would have gotten those interviews or passed them without excelling at my job. My resume would have looked terrible if I didn't go above and beyond at my last role, and I would have given weak answers to some of the questions I was asked if I didn't have real experience with the subject matter or a relevant situation.
I think I understand why you have the perspective you have. Indeed, many modern software interviews can feel far removed from the actual job, and we all know that even well-executed interviews sometimes result in decisions barely better than a coin flip. However, unless you really enjoy leetcode, I can't think of anything more depressing than studying for interviews all day. Also, it is hard to prepare for interviews at higher levels (senior/staff) without actual experience produced by doing a good job.
I completely agree with his, as someone who has recently completed several interviews for senior level. I used to think everything depended on Leetcode questions, but I was surprised to find out how much of the focus was on design, past experience and leadership.
Leetcode is "easy" to crack with some (considerable) amount of hard work and they know that. But you can't make up past experience in behavioral interviews as you get found out very quickly.
Me too. I interviewed at a few places in March for senior roles and there wasn't any algo gotchas. Some coding, I think mostly to make sure I could code. But a lot more emphasis on architecture and team skills.
So maybe there's the gap between senior roles and mid/jr/new.
But my question then is, how are senior folks training/picking folks to replace them? It must not be happening in the interviews, maybe on the job?
I've noticed the more experienced I get the less technical the questions are. My last interview was just a general chat about type systems, the good and bad of Haskell, why I have been using common lisp recently in my spare time, etc... No coding questions, no leetcode, no code walkthroughs -- I really enjoyed it.
Yes, but in my experience you need both. If you are not willing to put in some time at leetcode it might not go well. Of course you can still get lucky, but better to be prepared.
Oh, you definitely need both. But there is a misconception that Leetcode skills alone is enough, but for more senior roles you get judged on more than that.
40 hours seems low to me if one wants to enter FAANG. Even if you’re familiar with the process and have prepped before. I’d expect 100 hours minimum for most candidates. Only exception would be those who interview regularly, do competitive programming regularly, and those who have to do algorithmic work regularly.
Most people I know spend nights and weekends prepping for at least a month to a quarter.
I'm obviously biased because I don't consider FAANG to be a goal at all, either as a stepping stone or end game. There are much better things in life than a lot of money.
> There are much better things in life than a lot of money
Sure - but if you want to live in silicon valley, you will have to join FAANG or have startup riches (much more difficult) to have a "normal" life that you'd have elsewhere. You're not going to own a house in good school district with startup income.
If you live in BFE then whatever - maybe the 100%+ raise in income wouldn't affect your lifestyle. For most of us in SV, it has a very substantial increase in quality of life.
I did it over 4 weeks. I have two kids, so I spent about 1-2 hours per day. I usually did some reading or a couple leetcode problems in the morning before starting work, and a couple in the evening. Honestly, once you do about 20-30 problems, they start to feel the same. I found that if I treated each problem like an interview and slowly walked through a solution (versus just diving into code and mashing Compile over and over until I get it), the problem ends up being easier.
OK, so taking the usual programmer's working hours then add 10 hours a week to that. That's some opportunity cost there, just to be able to jump through a hoop that has little to no bearing on a real world programming career past the intern/junior developer level.
oddly (if you see my sibling comment) I just got a job where they didn't ask me any technical questions. They just asked me about my coding philosophy. I guess they just looked at my github? Dunno.
I'm only four jobs into my career, and the two that didn't ask me any technical questions ended up being either boring or a quagmire of non-technical leaders attempting to manage technical processes. Hopefully yours turns out better.
Absolutely. I work at Stripe now. In fact, I wish I only interviewed at Stripe (hindsight is 20/20), because I would have done zero leetcode prep. It is well known that Stripe interviews are much more practical than FAANG interviews. The leetcode prep was definitely necessary for some of the FAANG interviews I did.
> I feel investing anything more than the bare minimum to get your assigned work done is worth less than just grinding leetcode and otherwise studying for interviews. Doing an actual good job, above and beyond, is not going to be worth much when you're looking for your next job.
I feel precisely the opposite: if you work somewhere with people you like working with (and who like working with you) then you will start to get hired through your network, not through your mad leetcode skillz.
That's what networking really is, not "networking sessions" or various going through the motions you'll hear described in a seminar. It's simple human connections from people saying "Hey, I'd like to work with decafninja again" or "Oh, you need a frobnitz expert? You know, I know someone called decafninja who might be able to help you."
No dude, I’ve been burned by exactly what that poster described. Being well networked just gets your application opened. The leetcode is what gets you hired.
The people who would hire me without leetcode were either trying to take advantage of me or have never been my coworkers.
As another commenter said: Leetcode, leetcode, leetcode.
I think it really depends on how and where you get referred. Bigger companies are likely to be process heavy and inflexible.
My last three interviews and job moves have all been from referrals or old colleagues. None had coding challenges and all resulted in job offers. But that was a small satellite team for a big org and two early stage startups.
It’s also a consequence of timing and luck though. I’d definitely be prepping harder for job hunting.
I've gotten lots of referrals from old colleagues and bosses, but as the previous poster has said, all that has resulted in is opening the door to an leetcode interview.
Also timeframe is significant too. I'd say 5-10 years ago, fewer companies (especially outside the tech industry) were leetcoding candidates. Now, many of those same companies (including my current) are all leetcoding candidates.
I have a (metaphorical) rolodex filled with contractors who I've enjoyed working with, which I will always check first before even thinking about ringing an agency.
I have a friend/ex-colleague who I would describe as a master networker. He has connections all over the NYC investment bank and hedge fund IT department world, and can literally call a few people up and get "a" well paying job at a hedge fund in a matter of hours. Some of these connections are billionaire CEOs/fund managers.
The caveat to this is that he has to be extremely unpicky. Said job can be very undesirable other than the compensation - stuff like feeding XML feed files or working with VB, etc. But because they are at hedge funds, they all still pay well.
This is what I did for the first half of my career. It worked well for me because I worked in the same domain for my whole career. Shifting into consulting was easy because I had an address book of people who knew and trusted me.
I'm not sure if it would still work though as I've been working for myself for 22 years. It seems hiring has turned upside down since I last interviewed.
Yup, I jumped into the if you can't beat em, join em camp with leetcode. I Did 160 problems (likely low for many people) before my last job search, and I now make 3x what I used to. I gotta admit it's a hell of an ego boost to crush coding questions in interviews; being completely in the flow and cranking out flawless code.
It makes me wonder how much money I left on the table the last 10 years, because I went the route of great software engineer -> great interviewer, instead of great interviewer -> great software engineer.
Also, I have to say I really came to enjoy doing leetcode, and learned (really re-learned) a lot of interesting things.
Did you just start off doing leetcode questions online and learned from the solutions? I'd study leetcode stuff if I could even start getting interviews to show my skills :/
Yes, and I went against the standard advice to not look at the solution until you solve it yourself. I think for the first 50-100 problems it's best to not think too hard about it before looking at the solution, gaining a full understanding, and writing an implementation or three (building that muscle memory so to speak).
At this point, you'll have many more tools in your kit (graph traversal, search, dynamic programming, queues, heaps, stacks, etc.) and you can work on coming up with your own solutions to new problems. But I found it to be a waste of time staring at a problem for hours when I didn't already have the fundamentals in place to tackle it.
The other thing I did was watch youtube videos to get a better grounding in some of the data structures that I struggled with. I mostly did this wish graphs, as I was always terrible at graph problems and never had to apply them in my career. I found this series of videos to be extremely good.
That part of just following the solution for the first 50-100 problems is spot on. It resonates very well with my experience learning math by first following the "solved" examples, fully understanding them, then solving similar "simple" problems, repeating them till they fit into muscle memory and only then attempting the challenging ones.
First challenge I faced with leetcode is they do not have a concept or technique map. Similar to the chapter index in any math textbook, each dealing with a specific technique, concept or pattern. For example the idea of using a hash to store a running sum is useful for a class of problems like finding the longest sequence that adds to a specified sum, longest sequence of equal no of 0s and 1s. Yet, there was and still isn't a page or resource where such a pattern was described.
Solving leetcode feels like swimming upstream, one problem at a time, looking for patterns. Some are well described (Kadane for example) but most aren't. I looked around the web but couldn't find any resources that helped me with this.
I wonder if we could, at your experience, list some concepts and techniques that can be repeatedly useful. I believe that could cut the prep time by a good degree.
Second related problem to this is retention. With this master technique map, it would become easier to review and revise quickly. (I tried spaced rep, not useful) The most effective strategy for me has been to put everything in one book.I have multiple index pages with lists of similar problems pointing the page numbers with the solution.
I have been able to get better at data structures using this approach now I'm at the leetcode phase.
I completely agree about leetcode lacking a technique map/graph/tree. This would be immensely useful. In my studies I found that I naturally gravitated to classes of problems I was already good at, because that way I could avoid the mental pain of learning new techniques. I really needed a roadmap that lead me to what I actually needed to study, and that showed me where I was strong and weak. But as you said, they never make it super clear which techniques a problem uses, and how those techniques build on and relate to other techniques.
I'm really glad you bring it up, because I had actually been pondering ideas for making a better programming training site based on the idea of a skill graphs (similar to an RPG), repetition to build muscle memory, clear progress tracks based on the graph of skills, and greater insight into your strengths/weakness/progress with metrics.
As far as enumerating techniques, I'd need a good deal of time to work on that. I think there are two classes, the macro, being data structures/algorithms and what type of problems they apply. And the micro, which is more implementation specific techniques. Things like using a loop with two pointers into the same structure (ie: find a cycle in a linked list).
Well thanks for your comments. Feels assuring knowing I'm not alone (although clearly in the minority) waving my hands at how crude and ineffective the common advice to "do leetcode" really is. That training site idea sounds exciting, much better than what exists today.
The key perspective shift from me was from
- "I need to solve 200 leetcode problems before I can approach interviews with confidence"
to
- "Here are 50 techniques. Most solutions use a combination of these"
I started my journey splitting things into buckets (Arrays, Strings, Binary tree, BST, Stacks, Linked List, Matrix, Graphs, DP). I went through EPI and Leetcode populating those buckets. I started solving the easies for a month. Built a repo of questions and links so huge, it would take me years (really, years) to get through it sequentially. That was depressing and with no sense of immediate reward, gave up.
A few weeks later, I decided to reduce scope and focus only on Arrays, Strings, BST and Graphs. Turns out that isn't a great approach either as there are a lot of overlaps between Array and String problems and by the time I got to the string problem that used a technique similar to what I had used in a problem in Arrays, i'd forgotten most of it anyway. Repeated this a few time and it gave me the impression that I couldn't remember shit, I wasn't cut out for this and gave up, again.
My latest attempt is to focus on data structures (properties, strengths and tradeoffs) and techniques. This has been liberating so far but is a lot of work which drove me to look for resources adopting such a perspective and I found none. I believe its probably a lot of work (like you mention) but I wouldn't know unless I get through more problems. ¯\_(ツ)_/¯
Yeah, it's really easy to get overwhelmed by the raw amount of stuff to study. I found I just needed to be consistent, and get through 3-5 leetcode problems a day, while trying to force myself to hit the problems in areas I was weaker. If I tried to enumerate everything, I quickly became very overwhelmed like you describe.
I think if you hit a balance of problems that touch on arrays, strings, linked lists, trees, graphs, stacks, queues, heaps, and also some dynamic programming you'll be good to go. I found that companies really love to ask graph problems in disguise, and once you know how to recognize them and the basic DFS/BFS implementations you're golden. And if you get good at graph problems, trees and linked lists are simple, so I think it's a great area to put extra focus.
I found the dynamic programming problems particularly hard for my brain to grasp, and I had to spend a lot of time repeating the basic problems and slowly building up my skillset. A ton of practice, and I never even got asked a single DP question in all the interviews!
Thanks solid advice I can related as I did follow the same after wasting lot of time on LC problems I cant solve. I have started getting good at LC. Since you landed job at FAANG, I would really appreciate if you can share tips on specific question says finding max path in a matrix it is graph problem but how can you master it so code flows in 30 minutes or less. Did you actually solve same problems multiple times?
If you want the code to flow easy, it's all about putting in the hours and working at the right level of difficultly. Not too hard, so that you're not making any progress, and not too easy such that it's not stimulating your mind. Think of it like hitting the gym, it's just you're building mental muscle (and stamina) instead of physical.
And yes, many problems I solved 3 or more times. If you go to the discussion section, you'll see a number of different popular solutions by users. Try to understand and implement a few of them to get a greater understanding of the problem. Once you feel like you know the problem well, delete all your code, see if you can re-implement it in under 10 minutes, then try again for 5. Keep putting in those reps, you'll get faster.
Think about how fast you can write out a simple for loop. You probably don't even think about it, the code just "flows" out. That's because you've done it hundreds or thousands of times, your subconscious takes over. You can get to that point with more complex things like breadth first search, depth first search, dynamic programming, path finding, etc. you just need to get the reps in. It's a lot of work, but if you put in the time (try for a couple hours a day) you will see the results. And, once you start getting better, leetcode can become addictive like a game, which makes practice much easier.
Can you give some specifics about salary, previous & new role, and location? I see these sorts of stories a lot on here but it seems like they're all concentrated in SF or NY.
And what about job satisfaction, not doing an actual good job and spending miserable time doing leetcode is not going to add much worth to my day to day happiness.
I instead always suggest to do a good job regardless (note that doesn't mean doing long hours just working with care).
There are more important things than career ladder like integrity, honesty, work ethic and meaningful work.
Don't let societal policies compromise your inner values.
I can't over-stress how important this is. Societal trends come and go, and unfit ones eventually go. Stand your ground, and do the right thing, always. You won't necessarily win if you do, but you will lose yourself if you don't.
It is such a tragedy for our industry. Personally, I don't participate. And encourage everyone to opt out.
I want, and do, spend all my efforts in delivering best performing, most secure real products, making customers happy and the infrastructure and code maintainable. I have as much impostor syndrome as anyone (or probably more than most) but very slowly over many years and long string of managers who gush about my performance and always give me highest possible reviews, I've come to accept (if not actually believe) that I'm very good at what I do.
And yet, no way I could ever "pass" one of these whiteboard algorithm monkeydance interviews. A company wants to judge based on nonsense that has nothing to do with the job? Then you don't get to hire me, a proven expert with a track record of success. Enjoy hiring a team of people who've spent their life doing artificial exercises and (as a consequence) haven't put much effort into building actual products.
I do what I can to improve the industry hiring. I do interview lots of candidates and will never do so via whiteboard monkeydance. I interview based on their experience doing real work, based on the resume. I encourage everyone to do the same and put and end (at least slightly reduce) the leetcode nonsense that's killing the hiring culture.
I go "above and beyond" all the time, but not because I think it's going to get me "somewhere". It's the type of person I strive to be, and that's good enough for me.
As much as I sometimes wish I could be rewarded just a bit better for going above and beyond, I have to agree with you here. I appreciate your philosophy.
Ultimately, intrinsic motivation won’t always make us rich, but it might help us be happy and fulfilled. And in the rare occasion that health, wealth and happiness all align, what a good life we can enjoy.
This is so sad to read. I made my way into a tech career in what would properly be described as “hacker” in the traditional sense, though I never applied the term to myself. I came into a ton of formal knowledge and became quite talented through paths that opened with recognition of my experience and skills. I’m going into the job market for the first time in a few years and this is exactly what I feared.
That said, I’m still very talented and I’m not going to let it shake me. Y’all can have the rat race, I’ll go find myself a place I can be productive.
Hoping the best for you. I'm hoping to either follow a similar path, or dodge computing entirely as a career path, find an interesting job, and keep it as a hobby where I have the chance to work on interesting problems. Don't know that I would describe myself as talented though, but definitely driven.
> Hoping the best for you. I'm hoping to either follow a similar path, or dodge computing entirely as a career path, find an interesting job, and keep it as a hobby where I have the chance to work on interesting problems.
I’m at the point I’m seriously considering this, and I’m just not sure I can do it. Everytime I run through the possibilities in my head nothing adds up. The only viable careers for me to switch into are a) not interesting or b) pay depressingly little and would require me to obtain expensive credentials.
There is a point to "staying current" beyond chances in future interviews. Imagine working at a company that has basically found its niche, is doing well, just not growing much so only hiring really slowly. Everybody around you has been there for 20+ years. Everybody working like 20-30 years ago. This kind of bubble is dangerous, not just for the employees' future chances on the job market, but for the company itself. To find the best solutions to the problems in their market, the company needs to stay cutting edge with its tech too. Otherwisr they will get outcompeted in no time.
And by doing so, it profits the employees too. If everybody has been around for 20+ years but stays really current, even just for the sake of the company, their employability stays high too! It's a win-win.
These rants about "I'm back on the job market and now have to re-learn coding" tend to be a strong sign of complacency. "I already went through this and now want peace and quiet, why am I being forced to learn something new?" Well, because the world is evolving. Keep evolving with it, or gradually disappear in obsolescence. If you don't then that's not just bad for your job chances but even for your company. You'd not want to work at a place that still uses VB6 just because it was hip 20 years ago when everybody was hired.
FWIW I work at a company where we are strongly encouraged to stay on top of the game so that we stay competitive in the market. That automatically keeps everybody employable.
I don't think it's a strong sign of complacency. I think people just don't do toy problems involve coding breadth first searches or determining bipartite graphs. How often to people really write dynamic programming algos in 45 minutes. They don't - they think and tinker.
Algorithms can be beautiful to code but most of the time is not spent on this sort of thing. It's fixing null pointer exceptions or parsing json requests or whatever javascript front end engineers do.
Please. Neither the original article nor my comment where about interviews asking to implement a breadth first search. That's a different topic.
This was about him having to learn C# since it wasn't really around 20 years ago. And having to polish up Python cause it was very different 20 years ago. And other programming practices. You definitely need to stay up to date on the stuff that's relevant to your job. Not because of interviews, but because .. it's your job. If you prepare for an interview and notice that's what's holding you back, then you definitely started to grow complaceny in your job. And maybe your environment made you become that way, then it's not a good environment.
If you are up to date on this, then writing a BFS from scratch or debugging a null pointer issue or even json will be a piece of cake. Interview questions are an excuse to have a technical conversation, not to see if you remember some algo from school.
I switched jobs just a few months ago. I interviewed for a couple places. Nobody cared about what I previously did. It was either all algos or architecture.
> Doing an actual good job, above and beyond, is not going to be worth much when you're looking for your next job.
After you've been in the industry for a while, you are likely to be referred for jobs by former colleagues, or even invited by those former colleagues to come and interview at their new companies.
If you excel at your job, your former colleagues will be more likely to do this, because they enjoyed working with you and want to work with you again. They very likely have no idea how good you are at Leetcode-style problems.
> If you excel at your job, your former colleagues will be more likely to do this, because they enjoyed working with you and want to work with you again. They very likely have no idea how good you are at Leetcode-style problems.
Then, once they put your name in, you get a Lettcode-style interview. That's the way every company I have worked for has worked.
This is a truly remarkable take I've never heard before. I honestly wonder if it's true.
If it's actually true--and if poor quality of work and reputation mean nothing, just leetcode--it seems like that is just a side effect of extremely rapid expansion and/or churn.
Because no employer would willingly hire people like that. That'd be absurd. So the only reason that would be possible if the hiring manager never got wind of someone's work ethic or quality. And it seems like that's only possible with enough disjointedness in the people network, combined with hiring practices that don't care about it.
It does sound distopian. However if it's really true then employers only have themselves to blame. Potential employees are reacting to the incentives in front of them.
I currently produce average to slightly above average quality work while being a "Professional Leetcoder". All my performance reviews have been positive. I could produce significantly better and/or faster work by going "above and beyond", but other than a sentimental feeling of self satisfaction, why bother?
> I feel investing anything more than the bare minimum to get your assigned work done is worth less than just grinding leetcode and otherwise studying for interviews.
I totally see the logic. But the problem with this is on day 1 of the new job where you've moved up a level by successfully completing Leetcode-style interviews, you're now expected to do more and know more. And that's hard if you've only invested the bare minimum in your previous job and haven't maximized your learning.
So now you need to not only give more than the bare minimum at your current job, you need to also constantly keep your Leetcode skills up to date.
I understand where you are coming from, but I honestly disagree. I always try and do the best job possible, but I don't do it for the company, I do it for me. I think of it as training to make myself better. I am always looking out for my skills and experience, so when the next opportunity comes around, I'm ready to take it. You could say that it's resume stuffing, but I don't think of it and mean it that way. I want to see how things work and practice what I know. I want to incorporate that knowledge and associate it with my past experiences to figure out new things.
I've been where you were at too. The problem is, no matter how good of a real day to day job I've done and what practical real world skills I've learned, "when the next opportunity comes around" as you say, I wasn't ready to take it - because I got burned by leetcode interviews that have nothing to do with the above.
I too, want to do everything you mention, but until I get past the leetcode gatekeepers, it doesn't matter.
I've never done that and only focused on doing as great a job as possible, and landed jobs at multiple companies many would consider "endgame" without knowing the k-nearest neighbors algorithm. Some companies or at least hiring managers are wise enough to look for what makes a productive individual rather than someone who chases the metric.
> I feel investing anything more than the bare minimum to get your assigned work done is worth less than just grinding leetcode and otherwise studying for interviews. Doing an actual good job, above and beyond, is not going to be worth much when you're looking for your next job.
Does it mean that CV credentials like "developed requirements for a complex system, built it from scratch and overcome significant technical challenges in doing so" don't mean anything, in your opinion? Because in my experience interviewing, things like this get a lot of attention, are discussed in depth and leave impression on the interviewer. I think that my results interviewing would be significantly worse if it was just "fixed bugs and did incremental improvements" instead.
But again, I have very little experience (or desire) interviewing at FAANGs of the world, may be they do things differently?
I worked my ass off at nameless orgs that were willing to hire a no-credential computer science graduate. Always going "above and beyond", built a reputation for getting things done, almost always delivered stuff on time, took ownership, covered up for changing and incomplete requirements, entertained last minute pivots, did what a team lead and architect should be doing even though was always paid as a dev.
This basically meant I spent late nights and weekends at home or office getting shit for work done. I've also on many occasions, put fires out in my own and other teams. I always got flattered in all my appraisals, with all my superiors including the CTO of our org.
Almost 10 years in, I feel fooled for not seeing the forest for the trees.
What a waste of time it all has been ! I get paid the highest that a non FAANG org is willing to pay for my skillset. I always get handed the harder, weirder things and it never ends.
I cannot clear these crazy interviews at these endgame orgs without a heavy investment of time grinding stuff of negligible value. Prepping now is an investment that will take months balancing family time and work load.
All I had to do a few years ago was just stop. Take a deep breath. Leetcode. Leetcode. Leetcode. Get into the weeds of my favorite language. Build a compiler. Get some research published in some journal or write a book or give some talks. Contribute to open source projects enough to get my name in. Schmooze a bit. Market myself more. And let the projects at work go fk itself ( They did end up that way anyway )
Would have paid off more than what my full time jobs have paid me for the last 10 years.
Edit: some comments seem to suggest they learnt a lot of their skills "on the job" and would not have landed their current dream job without it. I am strongly biased to believe there are more blue winged raccoons roaming around in this country than such people who got hired at FAANGs because of what the learned on the job at non-FAANG orgs.
All non-loss-making, salary-paying orgs use standard stacks with standard components in two or more enterprise-y languages glued together with a shit ton of in house coded garbage running in production with some standard relational DB. Go try to make your resume sparkle and stand out with that experience.
You spend enough time in these ecosystems in production and you see yourself keeping a safe distance from anything that is new, look at any new platform with skepticism and quickly realize how painful that upstream swim is to make fundamental changes in such environments. I still have scars to show from the time (among other fun times) I tried to get cassandra into our production systems only to later be told by the cassandra folks to "RTFM, before doing anything fancy" Its a full time job to keep those up and running not some skill a dev would pick up "on the job"
Thanks for sharing! I can relate I am also on a same boat and realized now leetcode is the way out then serving non FAANG org which I thought will serve me well for my loyalty and hard work I gave so far.
Unless you're close to retirement and don't really need the money, it's unlikely you'll know when you're there. Companies change and/or get into trouble, managers change, projects get canceled, etc. I've been at companies I spent quite a few years at and I still came close to quitting for various reasons (and eventually did). I'd submit there is no predictable endgame over more than a 2-3 year time horizon.
You're right that "endgame" is different from person to person, and also in the same person's lifetime.
My current company was something I would have considered endgame at the start of my career. Now it's not.
A company I'd consider to be currently endgame (say, FAANG), may not be 10 years later.
For the sake of discussion, as I mentioned in my original comment, I would simply define an endgame company as one where I'd be satisfied staying for a while without further ambition about finding the next great thing. Where I'd be content doing a helluva great job and not even think about leetcode.
My best friend ended up at one of the FAANGs a few years ago and is doing exactly that. Although he is now afraid that his leetcode skills have atrophied and he'd fail interviews horribly if for whatever (involuntary) reason he ends up having to look for another job. But he has no short term intention of leaving and thus hasn't been grinding leetcode for a while.
I confess that, as someone who has never been primarily a developer (done a number of different things over time), I find this whole leetcode thing beyond strange. I have never in my life studied for interviews other than reading up on a specific company I'm interviewing with. ADDED: And every job since the one out of grad school decades ago has been directly through someone I knew.
You're not the only one. My wife finds the whole thing bizarre. As do my non-techie friends.
My wife's best friend thought it stupid (actually, I agree - it is stupid). Then she started dating a SWE, who is apparently also leetcoding in his spare time.
Early this year I got good at these problems and the ones I would actually encounter, above the average (based on time to solve, efficiency), as well as the system design interviews and I honestly think the behavioral interviews too, but decision makers just do not want to pay me over $180k. Whether thats salary at a Series B, C or midsize company or big tech companies whose total comp would be closer to $400k alongside a slightly lower cash comp
I questioned my competency, how I come across and everything. I subsequently let recruiters push me at the $125k range and I got a lot of offers. It was like a totally different and endearing experience, just like I had seen earlier in my career at those and lower comp ranges
So instead I created and sold some digital currencies for 7 figures
I think I would still like the validation of doing a year or two in the big tech circuit, especially because I could earn the shares and write calls on them without risking my prior capital, while being less likely to incur liability or bring attention to myself like in entrepreneurial endeavors
But I really hate that people are not able to value my contributions accurately. In fact I dont think they are valuing that at all, it felt like people were expecting a different kind of person: more stereotypical unsociable programmer at the higher comp and experience ranges. But regarding experience I also did a resume variation with less years of experience.
You created the digital currencies and sold them? So you came up with your own coin then? When was this and how did you convince people to buy it, unless you had an active project for it (or you were intentionally fleecing them)?
You could possibly get away with that a few years ago when people were throwing a bunch of money away on vaporware ICOs, but it's getting cracked down on more now.
The key for US compliance is to build a form of consumptive utility before the sale and never talk to your actual or potential buyers about the things they want to talk about (future prices, exchange listings). Look at IMVU’s no action letter for the kind of guidance US lawyers have been giving but nobody has been able to talk about. The SEC publicly agreed and I can confirm it matches the guidance given to many projects.
Huh. Okay, I'll take your word on it, I haven't done the research. Is this still a project you're actively working on, or have you moved on to other things?
Its really hard to reply to your leading questions when you're looking for controversy, or put your past troubled experience with token projects onto me (or trying to rationalize a pivot)
Token projects are just SaaS businesses with limited memberships that inherit transferability and settlement on a distributed ledger.
They're also extremely lucrative to sell in the primary market and the blockchain component sells itself.
I don’t understand this line of reasoning at all. There’s only so many tricks available in these interviews. I’m sure I’m biased, but if you know how to program, programming interviews are pretty easy.
I think if you are becoming a Professional Leetcoder, you’re still learning how to do basic programming.
I mean why not both? I worked hard and do my best in my job, but I also do leetcode and others a few times a month just to make sure I can still get another job if I need to.
I am not professional leetcoder, but good enough if I need to in addition to my experience that has been good enough so far.
Because leetcode is way more boring than making things? Also you learn a lot more by trying to do a good job and working with smart people, they are just not that easy to bring out in an interview.
That being said if you think it’s right for you, go for it.
Because it's not the latter that gets you the next job in many cases.
After you've been in the industry for a while, you are likely to be referred for jobs by former colleagues, or even invited by those former colleagues to come and interview at their new companies. If you excel at your job, your former colleagues will be more likely to do this. They very likely have no idea how good you are at Leetcode-style problems.
At which point you’ll have to do leetcode problems in the interview you got via the referral.
Former colleagues in most cases can just get you out of the application lottery - that’s it.
This is less true in PMish roles where there really isn’t a technical leetcode style interview or at the exec level where the friend is the hiring manager or ultimate decider.
In most cases though? Leetcode still gets you the job.
IF yopur #1 skill is grinding leetcode and continually jumping by being an expert interviewer, when & why would you ever stop? Have you not in fact discovered that this is your endgame? The parallels with how we envision hell are obvious...
I did that and found that I hated it. There's a lot of bullshit that you have to deal with in a small business: incorporation papers, taxes, staying away from the zillions of people who try to scam or extort small business owners, sales, finances, etc. If you're wealthy enough that you don't really need revenue and can pay people for that, you'll likely find that being wealthy just exposes how money won't make you happy anyway.
I feel like the people who say money won't make you happy need to have their eyes checked. Sure, piles of money don't do anything, but money among many things gives you opportunity to have experiences with other people, and a buffer from stressful situations, and imo that is the crux of happiness.
Now you can take that flight to see your family members regularly. You can now have a house large enough where if you have guests over they no longer have to sleep on the floor. You no longer are held hostage with the fear that you will be bankrupted by your aging parent's health issues. You can afford to bury your loved ones. You no longer have to make compromises with your children's lives that you wish you didn't have to make. Your basic needs will always be met. You are de facto exempt from physical labor since you can afford to pay others to maintain your life like a prince.
Sure, money in itself doesn't buy happiness. But it buys you a lot of opportunities to be very very happy, and serves as personal insurance towards things that might put the average person into a tent on the sidewalk.
I think when people say that they are assuming you have reached a level where you can meet your basic needs. We are talking about programming jobs here, not cashiers in the local supermarket.
A better endgame might be finding the job that you actually enjoy doing, moment to moment, so that while you're working it doesn't feel like you're working. Never have to work a day in your life and all that...
They’re designed to trick you into acting against your best interests. To push you to spend money you don’t have on shit you don’t need to impress people you don’t like, to quote a witty whoever wrote this.
At one end they exist to inform and offer you a service. I've clicked on ads and purchased and have been better off for it. No tricks involved but it did save me 1/2 off the original price I normally purchase from another store.
Who I am impressing with my canned milk buy?
Ads that show a lifestyle that tricks you into believing you can become something you are not is a small segment perhaps larger on social media. I don't see any of that or if I did it doesn't register. But I do see can of milk for sale.
I go through fliers and get coupons. I get email ads on products I purchased for discounts.
Even those store displays with toilet paper are a form of advertising. I don't mind them and often buy a pack if on sale.
Imo it's not that all advertisement is evil, just the ones that stoop to manipulation by taking pages from psychological research, turning our primal instincts against our own self interests to spend more of our limited money on dumb things or vote for a dumb thing to make someone else money.
Unfortunately for the majors in advertisement these days, that's their bread and butter.
I recently retired after working 29 years in software development. I was always very well paid but a notch below the FAANG-level. I always focused relentlessly on achieving financial independence by saving and investing as much as I could using Boglehead techniques. I can now do whatever I want.
I got a PhD so I started a bit late but I do not regret spending my 20s as a grad student. At least when I started working, a PhD came in useful. I should note that this was a long time ago so my advice may be less relevant today. In general, my advice is to save as much as you can early in your career. Thanks to the power of compounding, $1000 saved in your twenties is worth a lot more than $1000 in your forties.
Tech hiring is severely broken. 22 years in and it's only gotten worse. We still tolerate PhD Comp Sci algorithm questions for frontend developer gigs, endless series of array shuffling and sorting, canned problems intended to "measure your problem solving ability," ridiculous hypotheticals (e.g. whiteboard how you would build Slack), and a litany of other tactics that recruiters or old school management thinks are reasonable hoops to jump through.
Yes, I'm a bit salty.
The best advice I received recently came from someone 10 years my junior in the industry: politely refuse hackerrank, algorithmic code challenges, array shuffling, or anything unrelated to the work you've done or the work the interviewers are doing on a daily basis. Instead, offer to pair/group program or troubleshoot on a problem they're currently trying to solve, offer to walk through an open source project you've worked on or authored and speak to the problems you encountered. Let the gatekeeper/recruiter know you decline the kinds of interviews I mentioned above, and let them know you're looking for an org that thinks outside of that box, that values a person beyond their ability to regurgitate for-sale interview prep.
That approach has an effect of weeding out companies mired in corporate lockstep. I had told a recruiter at a national, Austin based real estate firm that I decline those types of questions and interviews. Was assured that they would not happen, and in the first round of the process was asked to sort an array of phone numbers. The interviewers had no idea I would decline the challenge, and I politely ended the call.
I recently adopted this approach with great success, speaking with a number of high quality orgs and all around great people who were truly interested in what I could bring to their effort. Granted, not everyone is in a position to take a bold stance, but I found that it made me more interesting to companies who were doing more than going through the motions.
Yeah, it does seem like the best jobs are the ones that you don't have to jump through arbitrary hoops for. Ideally, your employer or client will respect you as a human being who has something valuable to bring to the table.
When I find "good jobs", they almost always crop up from serendipity in areas that I am genuinely interested in at the time. Looking back it feels like dumb luck, but the sort of dumb luck that is helped along by trying to make your own opportunities.
If you ever have a chance to talk candidly with an executive or entrepreneur about a subject that you are passionate about...well, at least take the meeting. Those sorts of discussions aren't interviews per se, but sometimes your vision will click with someone else's, and that's where the magic happens.
> Yeah, it does seem like the best jobs are the ones that you don't have to jump through arbitrary hoops for. Ideally, your employer or client will respect you as a human being who has something valuable to bring to the table.
Even better if they actually know you!
> If you ever have a chance to talk candidly with an executive or entrepreneur about a subject that you are passionate about...well, at least take the meeting. Those sorts of discussions aren't interviews per se, but sometimes your vision will click with someone else's, and that's where the magic happens.
This is great advice. Talking to business folks when you aren't working for them is a great way to practice this skill and you never know what you might end up running into. Another good thing to do is to try to connect two people who might benefit from the connection (discussing a technology, an opportunity, etc). Sometimes something will happen, sometimes not, but the goodwill will be remembered.
A few years ago I joked about never wanting to submit a resume again. If you spend time on your network (all the time, not just when you need a job) and do good work, hopefully you'll get to a point where you can contact people you know who are looking for help.
Sure you'll still need to "interview" but the stakes are lower: they know you and you know them.
You can't believe how many people are unable to do the basic things like sort an array.
These kind of questions is not to see how smart you are, it is to weed out all the ones who don't event get the most basic parts of programming. And I can assure you as someone doing a shitload of interviews, that a huge part of candidates doesn't understand the basics of programming such as sorting an array.
If all candidates had a minimum competence, sure we could do other kinds of things. But right now, you will first have to pass the "I can do newbie programming" tests.
Why would any company want me to write an array sort instead of calling the .sort() method on the standard array class? Is that really the sort of thing they want their devs to code and debug and maintain by hand?
Having a deeper understanding of how things work is important in knowing how to use even the high level constructs well. How do you choose between an ordered and unordered map? If you've implemented them even one time I bet you'll have a clearer understanding of where each one excels.
If you couldn't remember how to implement quick sort or merge sort that would be one thing, but if you had no idea or never considered how a fast sort could operate that's another problem. I would never ask this in an interview but to use it as an example, it wouldn't be recall of an implementation that I'd be looking for but seeing if the candidate can identify a divide and conquer approach to the problem.
Good architects know a thing or two about material science, good electricians know a thing or two about physics, why programmers programmers be averse to understanding algorithms (i.e. the nature of computation)?
You should use sort() and ask whether it's okay to use the built-in?
They will always say it's fine and move. It would be extremely uncommon in the current decade to come across an interviewer who minds using the standard library.
I think testing whether someone can recall the implementation of quick sort and has practiced writing it quickly is not really testing for building complexity or solving problems.
It’s testing for practiced solutions of memorized algorithms and a bit of role play.
I get there’s some IQ challenge to preparing this and it’s hard to evaluate skill, but I don’t think this tests much beyond that.
Want to test true basic programming capacity? Do fizz buzz, ask someone to reverse names in a string with loops - everyone should be able to do that without thinking.
That’s actual basic stuff.
High level or more complexity? Discuss a relevant problem the company needs to solve and how they’d approach it.
Better yet discuss a problem and debug it together. Most programming is debugging anyway.
Note that koonsolo never mentioned quicksort, only sort. You can easily make it a newbie question by just accepting any sort that returns a correct output, even with a quadratic complexity in the best case. Any programmer should be able to write that in less than 10min.
And as the post you answered to alluded to, the point of the question is really just to filter out candidates who can't even write simple code, just like fizzbuzz. That's the kind of question you could ask in a first round, and then proceed to more relevant questions.
I haven't written a sorting method in years and couldn't remember it on the spot in 10 minutes, despite having analyzed the big ones 6 years ago. Yet, I have no problem creating a giant, modular, cookie-cutter enterprise structure, which is generally more sought after and something many hardcore leets seem to struggle with, especially once it comes down to doing more than just a fancy UML graph.
Again, you can make it a newbie question by just accepting any sort, including one you come up with on your own (so no need to remember). I'm sure you can design your own sort given enough time, granted 10 minutes might be too short to get it nice and clean, but with a bit more you're on the level of difficulty of fizzbuzz.
To make my point clear, you can implement a dumb and inefficient sort by implementing a min function, taking this min, then iteratively call it on what's left of the array and append the values to a new array which you then return. That won't get you into FAANGM, but maybe that's enough to get some discussion started in an interview at a company that's not too much into leetcode and is trying to evaluate other skills like communication. And I do think that 99% of people who write code every week could come up with something like this or better fairly quickly.
The reason I jumped to quicksort in my initial reply is any sort short of quick or merge sort (or some other nlogn variant) would fail you at FAANG.
You could do the naive n^2, but it better only be in the first two min and hand waved off as obviously inefficient, almost a joke that you implemented it at all on the way to writing the nlogn version, bonus points if you talk about how merge sort is nlogn in worst case and quicksort is n squared in the worst case, but in practice often faster.
Some people consider me a senior, yet the only sorting algorithm I actually remember and can write from scratch without consulting anything is bubble sort. And maybe insertion sort. And that's it. Both horribly inefficient. In real life I use whatever the language provides, for example Collections.sort in Java.
The more general problem is just how far removed from reality are all these questions. I once tried interviewing for Google, just for fun because they sent me an email about it. They asked me about quicksort, I said that I'm able to implement it in any language I know given an hour and the ability to google things. They were apparently not very satisfied with this response.
Why do you need to recite things from memory on the interviews while you'll be able to consult whatever the hell you want on your actual job? No one knows.
Knowing how to implement sort does not mean you can't do higher complexity things. These are not the basics of programming, I think. Someone the other day refused my candidacy just because I was unable to comment more broadly on the abstractions used in C# async library, which is completely off the point. If you need to do some tweaking on async, you go to microsoft or google and find it out. Most of the time you just need working knowledge of how to use async await and a few other things.
I have never implemented sort after the second university compsci course. I might still be able to write one if I think about it a bit, but just not relevant at all.
This is a good strategy for senior engineers to avoid the leetcode interviews. And to any recruiters and hiring managers reading this, there’s the other side of this. If you want responses from high quality senior engineers, then start your LinkedIn email with “NO Leetcode”. Response rates will likely increase by a lot.
Same here. I ignore all cold emails or mark them as spam. If I saw something like NO LEETCODE in the subject I'd be likely to read it. If it sounded like a reasonable place to work I'd share the job with my network.
I can't help notice the irony that they wanted to put you through a gauntlet of leetcode style interview questions only for you to be working on what are most likely basic CRUD apps.
Thank you, this is brilliant advice. Despite decades of experience I was nervous due to this trend and spent way too much time on hackerank. The company I ended up with didn't ask any of that crap (despite being founded by a PhD), and we couldn't be a better fit.
Of all the companies I have interviewed with, the only ones I ever joined had sane, non-leetcode interview processes. I have actually reached a point where I see companies asking those questions as churn factories to be avoided rather than schools of practice. If/when I find myself interviewing again I will be declining leetcode interviews.
That's exactly how I handle these interviews nowadays.
Granted, it'd hard to know what's your price when you're young and you would take everything in the early years.
But now I'm mid 30 and have seen and executed enough interviews to know that the rational thinking and kind human is so much more worth than a code monkey that is twice as fast.
Why? It's the same reason why code should be readable - you have to live with it. And the only way to achieve this is by asking for the way of thinking, now what's the solution is.
A rather tired conversation in my opinion. Everybody likes to complain about interviews, but every single alternative I've heard is even worse:
Take-homes are biased toward those willing to work hours for free, a "track record" is biased toward those who inflate their resume, a casual conversation is biased toward the likable and native english speakers, high-level whiteboarding is biased towards people who are good at whiteboarding
Recently I started trying something new for our interviews. I start with a phone interview that is more about discussing their background, expertise, what they need to feel productive, and explain the role. If I think they’d be a good culture and expertise fit, I send them something like this (I’ve made a few): https://gist.github.com/tywalch/cf60e4c942ab6a80e481f4ba6754....
It’s a small “api service” that represents a POC with some bugs and bad practices. I tell them to look over it, write down notes on how to make it production ready, setup a time to discuss their thoughts in a second call. No code writing necessary.
It ends up being an excellent Rorschach test where folks can really show/express their unique skill sets and experience. I ultimately let them drive the conversation and it gives me great insights into what experiences have shaped their career and what it might be like to collaborate with them. Best of all it does resemble what some of their day to day might look like better than hand crafting some tree algorithm.
I had an interview a few years ago where they literally hauled out some of their legacy code (unstructured PHP written in the PHP 4 era), and asked me to make a list of what I'd do to clean it up and make it more manageable. No coding involved.
It was a very pleasant experience from this side too and allowed me to express all of my domain knowledge without making a significant investment. This is such a great approach IMO.
the only way it could possibly go away for good is database libraries that don’t support dynamic SQL. But you almost always need the flexibility at some point, and SQL is so powerful that taking it off the table is hard to justify.
Yes, there's lots of ways to fix SQL injection. I'm more surprised that after knowing about this vulnerability for 20+ years, its STILL lost on many developers. You and I pick up on it immediately, but there's (apparently) a lot of developers who think the code is "good enough, works for me" and ship it to production.
So it needs to be asked for in interviews, and if you find it and discuss it you're apparently one of the "better" programmers. The bar for being a passable programmer is literally on the floor.
That’s cool, I’d actually enjoy getting this instead of being asked to build yet another production ready app in “two hours but you can spend more if you like hint hint and then we might even get back to you”
I disagree. This taps into a lot of technical know-how and communication skills.
It’s a well-rounded examination of how someone can contribute to the development of a product. That such a well-rounded assessment happens to include examining your likability or “other emotional response” is just a byproduct of testing how well someone interfaces with other humans - part of the job almost always.
The grandposter actually doesn't say "social skills" are worthless. You're kinda putting words into their mouth. They only claim that that type of interview is biased for one factor.
"Culture fit" is one of those things that seems to be used as a proxy for traits that are illegal to take into consideration during the hiring process.
At its worst case, sure. But it also means, can I work with this person? Can we be productive together? Are they picking up what I and the rest of the team will be throwing down?
Everyone has had to do a terrible group project in school where the group dynamic was just not there and the whole thing suffered, despite all the smarts being at the table. This is to attempt to avoid that exact same thing from happening, because often you just don't have the time to flub around telling someone how to document something properly for the 10th time.
We recently spent a long time filling a position. We're a relatively small team, where it is paramount that one works well with the rest of the team.
That doesn't mean you got to fit some tight social profile, far from it.
But since we're a small team each person has a lot of responsibility, and so we need to trust the right decisions are made for the right reasons, that communication won't be an issue, that you can handle dealing with customers for projects and troubleshooting etc.
We don't need the best skilled coders. We need developers who're good at finding solutions to our customers problems, within the constraints of us being a small team with limited resources (time most of all). We need someone who's capable of learning new technologies as the needs arise, and we need someone who can communicate well within the team and with our customers.
When I got hired, my actual coding skill wasn't really a topic. I didn't get a single programming quiz or similar question. They were far more interested in my background, what sort of projects I had been working on, what motivated me etc.
I can understand this concern though I can assure you when I say "culture fit" I'm considering it a two way street.
A good example: I had an interview earlier this week for a full-stack role and the inteviewee had recently come off a two year project that was heavy on react. The project he'd be on has a jquery frontend. I told him candidly that the project would likely never make a "modern" refactor a priority, and asked him if he could still be happy in a role that used jquery.
Our full-time team is small and ensuring we can all collaborate and work together is very important for us to be effective. On the flip side we try to be transparent about what our team looks like too and give you a chance to decide if you could be locked in a room, hashing out which circle talks to which on a whiteboard, with us.
I've found asking people to write a small program works pretty well. Like ask someone to build a command line app that arranges your mp3 files in folders of their artist's name. You can even ask it to be whiteboarded, or coded in a notepad, no code execution or IDE.
I found that to quickly tell you if someone can write programs. Surprisingly (and maybe not surprisingly), a lot of people can do difficult leetcode questions, but can't write a small app, or can't do it well.
It'll quickly show you about how the candidate can come up with some level of UX, handle OSish level stuff, how they structure and think about their code and readability, how they model data, and depending on the app you ask them to write, it could include a little algorithm in it as well.
That kind of UX experience, OSish or design small app whatever can be learned very quick on job. However Leetcode skill is not -- you have to devote 2~3 hours per day to grind and practice.
Yes, it's extremely tired. FAANG companies are not dumb, they hire at scale and know how to find talented engineers using a rigorous/repeatable interview process. I think most of the complaints come from people who fail these interviews (I used to be one), and don't want to admit that maybe they're not good enough.
There is an abundance of people more than “good enough” for roles at FAANGs. They may simply not be stellar at the examination process used by FAANGs to assess candidates.
As much as many folks at those companies might want to partake in some fart-huffing and call that a predictor of engineering excellence, it’s not. It’s an optimization to shovel candidates at scale, and intentionally throws out ton of exceptional and even over-qualified individuals to instead hire a predictable style of engineer with as little investment as possible.
I think OP meant "not good enough" to pass the interview, not to perform on the job.
Saying that a certain $PREDICTOR is bad in itself doesn't say much, in particular it doesn't say whether there's a better one available under the same constraints. Widespread leetcode interviews is just an indication that large companies have not found a better predictor yet (again, under the same constraints with respect to time, budget, etc.).
> FAANG companies are not dumb, they hire at scale and know how to find talented engineers using a rigorous/repeatable interview process.
Eh... maybe some do. My experience is that they hire people they already know. In fact that's how I got hired at a FAANG company. I had applied there many times and been rejected. Then I saw that a team where I was a great fit had hired someone I knew and had an opening. So rather than submit my resume through their job board, I sent it to him and he passed it on to the hiring manager. Most of the rest of the team got hired because they were all a team at another company that got cut. One of them got an interview and said, "Hey, I have about 20 coworkers who just lost their jobs and already know all the stuff you need for that new product you want to write. Why not hire them all?" And they did.
Sure, there are a few who went through the regular recruiting path. But many did not. I'd say on my team, most did not. (And they're all good engineers, too.)
It takes a talented bullshitter to convince themselves that a 30 minute whiteboarding session can determine anything of worth about a person’s first month at a company, let alone year or two. “We only hire the best” is just marketing.
Well, that's why the standard interview loop consists of at least 5-6 45 minute sessions that intentionally do not overlap in subject matter done by separate people. If the signal is not strong enough, then more interviews are done. Works pretty well I think.
Do you have any empirical data demonstrating that this “works well” or are you just assuming? What is your definition of “works well?” Low false positive? Low false negative?
Empirical data that it works pretty well? I think the fact that this has been the de facto way of interviewing at the top tech companies during the time that tech has absolutely exploded in ways never seen before, I'd say yeah, it's working pretty well. I think you're seeking an explanation where one is not owed. If it wasn't working well, it would be changed, just like the brain teaser questions of the early 2000s pioneered by Google.
And look, I get it, it's frustrating. I share in that frustration as someone that wants to switch companies but knows that I will have to put in the effort outside of work to prepare for that. But I still think the process is much more meritocratic and predictable than virtually every other industry.
> I think you're seeking an explanation where one is not owed.
Forgive my curiosity and desire to make things better.
> If it wasn't working well, it would be changed, just like the brain teaser questions of the early 2000s pioneered by Google.
This is a gigantic assumption, though. Tech has been exploding for a long time and basically all companies are ravenous for engineering talent. It’s not at all clear to me that this interviewing process is the cause of this growth or in spite of it. If I had to guess I would bet they’re wholly unrelated.
> And look, I get it, it's frustrating. I share in that frustration as someone that wants to switch companies but knows that I will have to put in the effort outside of work to prepare for that.
I have no problem passing these interviews, I just think they’re silly. Their prevalence in the industry frustrates me because I think they give an unrealistic portrayal of what’s important in software engineering. But then again my greatest area of expertise is legacy software maintenance, which is the work that nobody else wants to do.
> But I still think the process is much more meritocratic and predictable than virtually every other industry.
That’s an extremely low bar.
My favorite approach that I’ve seen is Latacora’s hiring process, in which they give you a work sample problem that can be graded quantitatively in stages as well as any prep materials that you need for it.
The FAANG interview process is designed to allow people who are bad at interviewing to assess candidates in a way that's replicable. It's designed to be a flowchart that you can't screw up.
The point is to remove wiggle room. It's a domain-specific solution. Note e.g. DeepMind don't hire the same way.
Their number one problem is automating the beurocracy at scale with people who are fundamentally not that good at evaluating other candidates, or more likely don't care if they make a mistake. Everything else is downstream from that. Copying them without understanding their objectives is a mistake.
I completely agreed with you. People who hate Leetcode, I am wondering, are those who refuse or lazy to devote hours per day to practice.
Because of covid-19 there are overwhelmed programmers, newbie and veteran on the job market to compete with fewer programming openings. Companies have reasons to be extremely picky, and job seekers either to comply with the game rule (Leetcode) or consider to change career.
And those who have job also need to consider to regularly practice Leetcode (one or two questions per day or every other day) to stay employable.
There was a time where you would just hire someone and fire them if it wasn't working out. Why make the barrier to entry so high and prone to bias when you can always just let people go who aren't doing the work?
Yes, I've worked at places where that was the approach. Problem is if you end up doing it very often it costs you a lot of time and you do have to eat some inital payroll and administrative costs. Plus out of respect for the candidate, they've quit their prior job, maybe moved and signed a new lease, and now they are unemployed 30 or 60 days later.
You really need to have some basis for confidence that the candidate is a good fit before you put yourself and them through that. Even for entry level jobs where what they know coming in isn't too important, you want smart people who can get along with the team and learn.
I've paid candidates and been paid by potential employers to complete take homes. I've also given candidates the opportunity to substitute a piece of open source code in place.
This is admittedly still biased towards people who have available time, paid or unpaid, but I think it's a step in the right direction.
What if there were a certification authority that could claim that professionals are, indeed, competent in X, Y, Z within software? And, of course, that authority would need to be recognized by A, B, C companies. That'd certainly skip the endless, often mind-numbing, repetitiveness of technical interviews (especially for those with many years of experience) and can jump straight to culture/team/behavior fit.
This is basically what all engineering disciplines do and it's why I take "software engineer" with a massive grain of salt.
I have several certifications from Microsoft and Google and, for the most part, mean jack to an interviewer. I am still forced to leetcode and answer mind-numbing questions.
On a side note, of all the choices I prefer a take-home, as long as it is timeboxed to no more than 1-2 hours.
It never is one or two hours though. It might be if you designed the thing and know exactly how to get there and handle all the corner cases. Oh and also we always underestimate.
I have yet to see a 1–2h take home test actually be doable in that amount of time. It’s more like 8–10h to get going, have something meaningful, and code that isn’t inscrutable.
It can be if they give you something to start with.
One company gave out sample code and asked me to optimize it so it ran under 5 seconds. The exercise was in parallelizing or caching/reusing what you could per the requirements.
The timebox has to be enforced on the company side, meaning that you have e.g. 2h to submit your answer once you've opened their link (which you should be free to open at any time, so that you're sure you have the time allotted).
I think the <textarea> problem can be solved if the interviewer gives enough information so that the interviewee can have their IDE working correctly by the time they get started.
The pressure problem can be solved by giving more time than what would be expected in a work setting. If you expect a task to be completed in 1h, just give 2h. Of course that implies that you don't give a task which would take an expected 6h to complete.
Of course these are things to consider from the company side, if they think they want to hire people who can program under high pressure, they should probably keep that as part of the interview, for both the company's and interviewee's sake.
i would agree a universally accepted accreditation organization, like the American Medical Association, can make interviewing for technical competency easy.
But like with AMA, they would (and does) gatekeep. What kind of policy can the organization be instituted with so that gatekeeping is impossible?
Doctors _should_ be a dime a dozen. They should not cost so much - because their services are valuable and therefore, more of them should be produced to make medical costs lower.
Software engineers, if they followed the AMA model, would cost $500k in student loans to train, and there's be barely any graduates to fill the demand.
> Doctors _should_ be a dime a dozen. They should not cost so much - because their services are valuable and therefore, more of them should be produced to make medical costs lower.
Physician salaries make up about 8% of medical costs. And even if you doubled medical school class size, you wouldn’t get 2x the doctors because there aren’t enough resident slots available.
And even if you had enough slots available, you’d still need to guarantee high salaries afterwards. Most people who are smart/driven enough to be doctors aren’t going to work 80-100 hours in a high stress position for 3 years if they are only going to come out making $80k.
So the only way to drastically increases (3x,4x) the supply of doctors is to drastically decrease the standard of training.
So you reduce residency down to 1 year and you triple the number of doctors. Now you’ve reduced the quality of doctors, and you save people less 5% in healthcare costs, but no one even notices because that number gets drowned out by the continued rise in the other 92% of healthcare costs.
You're assuming the bugs are required. Residency as it is now is a terrible system that had no need to exist in its life destroying form. The industry had already figured this out and is moving work from doctors to nurses and PAs and offshore radiologists who don't need a residency.
Moving work to lower level practitioners is functionally equivalent to reducing physician requirements.
Of course companies are going to do anything they can to reduce prices. And of course the industry is going to put out flattering white papers in support of their cost cost cutting measures. Yet those reduced costs haven't been passed on to consumers or measurably improved medical care, so the argument merely that the industry is doing something is a poor argument in favor of it from a consumer/public health/societal standpoint.
Some companies love to outsource labor to countries with relaxed labor laws. That isn't a convincing argument against the need for labor regulations.
Maybe because building a bridge is a very standardized process that lives through regulation. Maybe software will end up there some day, hopefully a day by which I am retired.
It may make sense to do this for certain disciplines, like software tailored for other engineering disciplines (think medical grade software, airplane/car control software, etc.).
However for the broad mass of software projects, certification makes no sense and is in fact much worse than what we have now. Do you think certification can't be gamed? It will usually be much easier to game that one since certification by definition is meant to be achievable by a broad mass of people. You don't build a certification program for elites.
Professional leetcode programmer? Sure. So let's count the facts we have at the end of the interview:
* You can code yourself through a number of problems, answer follow-up questions that dig into random specifics of your problem, slightly modify the problem, etc. You can demonstrate structured problem solving, ad-hoc clean code and you make an overall good impression in that performance.
* You are able to demonstrate the necessary experience through targeted behavioural questions that probe deeply into specific aspects of your job history and alignment with the company values
* You are able to design a complex software system and are able to answer unknown follow ups and able to follow drill-downs into random aspects of your design.
Congrats, you are a professional software developer. Can you game the leetcode part? Potentially, however I met several "leetcoders", some of which were even kind enough to put that on their CV... They usually fail quite spectacularly at random follow ups and modification to the problem statement. But even if you are able to somehow "wing it" convincingly, you need to succeed several times and you need to still demonstrate the adequate proficiency in the other two pillars (behaviour and software design).
What we might need is an "interviewer" certification.
I don't have statistics in front of me, but I'm fairly certain that the vast majority of people with "real" engineering degrees aren't Professional Engineers (which is what I assume you're referring to). On top of that, there was a SWE PE offered in the US for several years. NSPE stopped offering it for lack of interest.
I can leetcode hours for free or I can do small projects for free and usually learn a new thing while doing it instead of trying to memorize something about a binary tree.
What about a pair-programming session? Even having failed some pair-programming interviews, I've felt at least like it was a fair assessment. It's an equal time investment between myself and the company, working on something pertinent to what I would be doing, in a realistic environment.
Contrast to whiteboard interviews where I've been assessed on how to calculate the number of moves of a knight on a chessboard given position X to position Y on a whiteboard in front of three people as a front-end developer. Contrast to take-home interviews which basically function as a way for the interviewing company to save on time and money by putting the whole time-investment on the interviewee.
a "track record" is biased toward those who inflate their resume
Could you explain this a bit? I'd have thought this is the only real way to judge someone. People will lie but figuring that out is part of the process.
Other orgs don't have recruiting problems that FAANGs do. They can do better than imitating FAANG processes. They can afford to go wrong and self correct more. They can find a strategy that works for them which can combine whiteboarding, pairing, casual conversations, references, real life problems, letting the candidate showcase their work.
The problem isn't that they don't work and they gave up, problem is they aren't trying.
I like take-home as a filter for candidate from institutions that have low signal to noise ratio (getting hundreds of applicants from "some technical institute" and then have a sub 5% hire rate).
But I know from college applicants that take-home end up at the bottom of the pile in terms of priority vs in-person interview with a real engineer. Unless it's FAANG of course.
This shouldn't be downvoted, it's exactly right. For every "do this instead" I've ever seen in articles bemoaning the state of tech interviewing, I've seen a dozen people attacking that other thing just as vehemently. There's nothing even remotely approaching a consensus viewpoint on what we should do instead.
And with all things in life, the answer lies in the middle. You should ask programming questions, but they should be applicable, universal and not “trick” questions. You can do a take home, but if you do, make it 60 minutes and fun. You will end up whiteboarding in a room, but you should train your team to be good at this, shadow them and help them get better at it. Nothing is wrong with these techniques, per se, but often they end up as a terrible candidate or hiring experience.
The author has been working as a developer for 15 years, and claims very strong technical skills. Why are they learning/re-learning Python, C++, SQL, C#, college math? Nobody will be fooled by that; at 15 YoE they will be evaluated on what they have done over a career, not over the last month.
> it's all about how much time you can spend on Leetcode.
The author is playing a game built for new grads. Here's a secret, speaking as an (ex) Facebook interviewer:
Facebook's hiring pipeline is optimized for new grads, but its hiring needs are senior engineers. They know this, but you can't build a high-volume interview pipeline for senior engineers: there's not enough of them, their skill set is too varied. So Facebook is kind of at a loss, but in general if you have 15 YoE and can show you're good, they want to hire you. In particular they'll try to find deep domain experts ("pirates", their term) to evaluate you.
So be prepared to demonstrate basic competence in coding, and also some deep expertise. T-shaped engineers, as they say.
That's nonsense. I've got 20 YoE, an elite college degree, tons of experience in Python and C++, have single-handedly put together mission critical software systems, and I can't get my foot in the door outside my small area of expertise. The teams I've worked on are tiny, so I have no career network to draw from. I'm missing machine learning and cloud experience, and my resume gets no hits because of it. Age 44, and I'm starting to think I've been aged out. As far as I can tell, no one is interested in experience that consists of project successes. It's just years of buzzwords and coding challenges. (So I just signed up for Hackerrank. Maybe someone will notice me there.)
> my resume gets no hits
> Maybe someone will notice me there.
I'm not sure if expecting them to come to you is a winning strategy. But you could get someone to review your CV to see if the presentation of it can be improved ?
I also have more than 20 years of experience, and if anyone asks me more than a fleeting question on what I did in college, that would be a massive red flag for me. I feel that even if I'm new to a certain technology, my overall experience is helpful and valued. The grey beard perspective so to say.
And getting some experience with machine learning has never been easier. Play around with TensorFlow, or buy one of those Nvidia Jetson dev kits and follow the free Nvidia AI courses. And there's plenty of things on Coursera, fast.ai and the likes for more formal insights beyond experimenting.
Same with cloud, free tiers everywhere.
But it takes effort to learn these new technologies, and that is not always easy at an age where more life has happened than for a recent graduate. So we need to be a bit smarter and efficient at it, but it can still be done.
Edit: I actually checked your Linkedin that you posted in another comment. I personally don't feel it's a bad CV, but I can see how it might not be a CV for FAANG companies. And you are already doing my suggestion of learning the newer stuff.
But I've experienced two things that might apply in your case as well. You're self-employed, which tends to reduce the people reaching for employee positions as they might think you're not interested at all. Secondly, you seem to be working remotely, which reduces opportunities even further.
I'm just wondering if recruiters commonly reach out to experienced developers that are self-employed in a remote capacity with a strong history of real world applications. Maybe a recruiter here can chime in ?
But it does seem you could use some more networking.
There's some other problem. None of us can say what it is unless you share your resume, what companies you've applied to, etc. But if you get "no hits" with 20 years of experience in Python and C++, the problem is 100% not "missing machine learning and cloud experience".
Where's the 20 YoE? Your linkedin says 10. And it only shows 6.
What did you do between 1998 (when you earned your degree) and 2014 when you started doing the consulting? That's a super long time to leave undocumented. That makes potential employers nervous.
What subject was your degree in? It's strange that it doesn't say.
I think you should take a look at the resume of other people with 20 years of experience in the software engineering industry and compare and contrast. When I look at this, I think... "What did this guy do for all this time? Did he advance in any meaningful way?" In 20 years, I want to see
* Advancement
* Variety
* Leadership
I don't know your story, and I have no real reason to think you're not an accomplished engineer. But your CV isn't doing a good job of showing it. Good luck to you.
How big is Bernardsville, New Jersey? Is it New York basically or is it elsewhere, countryside?
One really bad thing about the industry that's rarely talked about is how the jobs are concentrated in a few cities worldwide. If you're in SV/NYC you're fine but if you're in a small city there might hardly be any opportunity.
I would had some numbers in the resume. When you say large amount of data for example, how many sensors? how many GB per day?
You're saying you're a consultant? I think it could turn off some companies who are looking for a permanent employee. Also, it's really uncommon for a consultant to work at the same company for 6 years.
If you've worked mainly for two clients, you could describe that as two separate jobs. That would add way more content and show more experience. The resume is quite empty right now for 20+ years.
P.S. Can see all the experience going back to 1999. There's no problem of linkedin hiding anything for me.
I suspect that even though you have a lot of experience programming, recruiters aren't counting it as applicable experience to the jobs you want. You essentially have even less experience with cloud/ML than most college grads who at least took classes where they have applicable project experience.
Changing job areas is hard, the best way imo is to find a company that does both what you currently excel at and what you want to do, then do an internal transfer to build experience. I've seen it done before where a friend of mine joined one team building internal support tools, switched to a different team doing data science, and now gets job offers for data science.
Would you consider moving away from the north east? Because you would probably be able to at least get interviewed at a national lab. But only Brookhaven is in NY and that is one that I have very little experience with.
If you were willing to entertain the idea of New Mexico then the labs might be an option for you.
I recommend joining a Python meetup. It can be a simple way to grow your network and have free pizza and beer.
Now, with respect to cloud... it's not that hard to learn. If you have system administration skills it should not be a real challenge for you.
Now, people in the industry did not wake up one day and conspire to radically change how things work. It has been a gradual change over many years... that's why it's important to stay informed of new trends and technologies.
Meet-ups may work. I met my current employer at a local Python meetup and got offered a position right away (I am 40+ too, by the way). I had recently moved to the area and had no contacts.
competitive programming can be really fun, addictive and great learning experience, and incredibly frustrating and takes lot of time (> 3 hours/day for 1 year to do it the right way).
If you want to learn algorithms for the sake of learning, perhaps specialize in some weird algo sub-topics, places like TopCoder, SPOJ, CodeForces that train for ACM ICPC might be a great place to start. These are different from LeetCode.
Can you do Leetcode medium level problems bug-free in 30 minutes? If yes you can try FAANG. I knew some people of your age (one is 59) were hired by Google -- they are all good in Leetcode.
Companies nowadays want you to be good in domain knowledge but also good to solve Leetcode problems during the interview. Time has changed.
That sounds damn frustrating. Would you be willing to share your area of expertise?
At 17 YoE, I avoid the cloud and ML because it's hard to bring my skills and experience to bear, and also I have no passion for them. But I have also found there's a ton of C++ code out there; IME there's a lot of appetite for someone who can wrangle it.
Well, the technologies I've used are all over the place, but the niche is defense contracting. Until now, I don't think I realized that processing lots of data really fast locally (i.e., not in the cloud) wasn't more generally in-demand.
That's not exactly a small niche. Edit: Just saw your LinkedIn profile below, have you applied to DC area companies? I think you would have much more success in the DMV metro area.
No, I know more defense would be easy. I'd love to try other stuff, though. There's so much out there to learn, and it's more fun to do things that push me.
I hear you. There's lots of non-defensive tech companies in the DC area these days too. The workforce isn't just made up of young college grads either.
Haven’t worked at fb but same experience at other big co. Also I question authors experience interviewing people - I’ve done literally hundreds coding sessions and there’re surprisingly large number of folks who claim 5-10 years of experience and several companies under their belt but aren’t able to code a simple for-loop in their language of choice
Literally a scan of string with some basic logic and three cases inside. People would take 30 mins+ and create a giant mess. This was easily 50%+ cases during phone screen and resumes all looked good so not recruiters fault (most of the time).
So basically a FizzBuzz, Jeff Attwood discusses it here. This article was really eye-opening to me.
Problem: Write a program that prints the numbers from 1 to 100. But for multiples of three print "Fizz" instead of the number and for the multiples of five print "Buzz". For numbers which are multiples of both three and five print "FizzBuzz".
Hard to believe. Actually I am surprised companies even asks such a simple question anymore. When was that?
I have done several LC easy and mediums, have done internships and published papers and didn't even make it to phone screen at every FAANG or other companies whose names carry some weight in future interview opportunities.
5-10 years ago. If you ask questions not from LC you have to make them easy or no one would make progress. My goal was to have at least something coded up so that candidate wouldn’t feel like they totally bombed, then I would calibrate my score based on quality of solution - basically secondary traits. Not everyone used this strategy =)
> have done internships and published papers and didn't even make it to phone screen at every FAANG
I recommend finding someone who works there through your network, conferences or open source projects and asking for a referral.
> there’re surprisingly large number of folks who claim 5-10 years of experience and several companies under their belt but aren’t able to code a simple for-loop in their language of choice
No. This indicates a failure in the interview technique.
Many software jobs barely involve programming. Just look around in this thread, you will find people who argue that the job barely requires writing any code at all and mostly involves talking to customers or managers. That kind of experience doesn't make you a better coder, it makes you a better product manager, so technical interviews filtering them out is intended.
Not really - these companies try to cast a very wide net deliberately so it’s natural there will be large number of rejections. Smaller companies do a lot more prescreening so it’s less common there
Wouldn’t that be wonderful? Over 20 years of really solid experience here doing some awesome stuff for recognizable employers. I’ve had the exact experiences as the author.
One recent interview run by ex-FUAANG folks started with a non-trivial take home that represented their actual business. I come in, am told it’s one of the best they’ve seen. Which was great, because I was genuinely proud of it. Now let’s find all of the combinations on a boggle board. Which wasn’t even the worst of it.
So far, that’s been pretty par for the course for me. It’s been discouraging.
> Facebook's hiring pipeline is optimized for new grads, but its hiring needs are senior engineers.
The hiring process should be based on the position and candidate. If you're applying the same process you use for new grads to someone with 15 years experience you're doing it wrong. FB should be capable of doing this correctly.
What if we form a group/site that refuses to do leetcode interviews?
This seems like a classic coordination problem. If enough people refuse, companies will have their talent pool limited.
We could use this group to help match companies and developers who don't want to leetcode.
If it's true that leetcode filters out great developers, than companies who 'can't find talent' should be able to use our group to find some. In fact, it could be a great sign of how willing the company is to think against the current hiring zeitgeist.
Edit: Here's a quickly built site.
say-no-to-leetcode.netlify.app
In (what I worry might be) the real world, the word union conjures unhelpful barriers to action.
I'm less interested in fighting idealogical battles. I'm more interested in achieving a practical goal - getting a large group of people to say no to leetcode.
My guess is more people will say no to leetcode if they think of it as a general group anyone can join. This allows a larger amount of people to ignore idealogical barriers they might have to joining. So for now it's a "group/job board".
To be blunt, most of my observations of traditional unions have given me the impression that they prevent the hardest workers from advancing and protect mediocre workers who do the bare minimum. The incentives appear to create a negative work environment for those who do want to excel, even in traditional union careers such as teaching and nursing.
I agree with you that the trend of asking Leetcode (or any rote-learning) style problems hurts candidates. I have no moral problem with software engineers bargaining collectively to reverse a trend that is harmful to the industry.
That being said, I think there is a tendency for organizations created around a cause to find themselves rudderless when that cause is finally achieved. The urge to not disband and instead look for another cause is often too strong, even if they don't feel quite as strongly about the new cause.
I genuinely would like to know how traditional unions obtained their negative stigma. My guess is they were started with equally noble aims.
A union that disincentivizes leetcode problems will reduce the ability of candidates who are best at rote-memorization problems to advance while protecting the ones who are mediocre at rote-memorization problems.
In this case it happens that people who are good at rote-memorization problems probably aren't the best people to lead the industry. But the union doesn't exist to serve the industry, it exists to protect the people working in it.
In an ideal world the HR department would be considerate of every employee's needs and there would be no need for unions. But in practice the incentive structure of the HR department doesn't allow that, so you need a competing incentive structure to balance things out (the union). Neither can achieve the goal perfectly on their own.
> getting a large group of people to say no to leetcode.
I assume you mean LC to be a stand-in for the types of interviews that focus on LC-style questions? LC didn't invent these and they're certainly not to blame when companies ask senior SWE candidates to invert binary trees.
I'm not aware of one. I've always said LC-style interviews.
I don't think LC is entirely useless, I've seen people graduate with CS degrees but couldn't do fizzbuzz. But the prominence of it for certain interviews is frustrating in many cases.
In the EU unions are not as tainted as in the US, but we still have neoliberals on the right, and 'progressives' on the left, both clamoring individualism for their own agendas.
There is no solidarity left : earlier this year my country ( NL ) threw all elderly under the bus ( we have no room for you on intensive care ).
You know what happened? They got scared. That was all.
I remember the 80ties : all unions would have united and the entire country would have revolted.
Many Unions in the US have a good standing (Teachers, Police, Nurses), some circles have been brainwashed by corporate propaganda that they are all horrible.
I'm fine with voluntary unions that don't want to take my money. I just don't want to be forced to pay up to a mafia 'protector' just to work in a position.
In NL unions negotiate central contract terms for all employees in certain sectors. The unions are funded by their members, but the result is for everybody.
Why not just publicly collect the companies that are known to not ask applicants to "invert a binary tree"? This would generate an incentive for companies.
The data could be community-driven, but of course that risks sufficiently big players fudging the input data (sort of like the fake reviews on e.g. Amazon). Even so, it may be possible to detect which companies are faking it.
I used to be a recruiter. Roughly 1 in every 25 developer I worked with told me they wouldn't do silly arbitrary technical interviews and that if the company wanted them to they would decline the interview.
I respected that decision but it none of those engineers every got hired by companies I was working with. They all had jobs already so clearly that was fine with them but it seems like there needs to be a better alternative.
One developer would ask what the role entailed, then find a relevant job/project that showed he had done similar work. That was helpful but obviously only works if you have a longer career with many projects to pull from.
Leetcode also filters out bad developers. I’ve said this on HN many times before but I don’t actually want to work with people who can’t solve basic leetcode.
There are a lot of “experienced” engineers out there who don’t know how to tie their shoes once they’re out of their comfort zone. Try interviewing people, you’ll see.
> What if we form a group/site that refuses to do leetcode interviews?
Why does it need to be a group? Refuse to do them, explain why, and move on to the next company. Talented developers are in high demand. There are plenty of other opportunities.
Does individual defection even matter? The purpose of this isn't to put pressure on job seekers, it's to put pressure on employers. The whole idea of "policing" the members seems strange to me.
If you're the type of job seeker who has no objection to leetcode, you wouldn't join. And if you're the type of employer who refuses to do anything else, this would be the last place you'd look for hiring.
The goal is to publicly show employers how many "refuseniks" there are. The situation right now is that refusal only happens privately and anecdotally.
You're right - individual defection doesn't matter. This is optional. The whole idea of "policing" the members seems strange to me and I agree doesn't need to be anywhere near this.
"If you're the type of job seeker who has no objection to leetcode, you wouldn't join. And if you're the type of employer who refuses to do anything else, this would be the last place you'd look for hiring."
This is very well said and exactly what I'm hoping for.
"The goal is to publicly show employers how many "refuseniks" there are. The situation right now is that refusal only happens privately and anecdotally."
This is exactly the goal and what I'm hoping to improve.
OP said the objective was to create a critical mass of people refusing so companies would have to adapt. That's what wouldn't work.
If it's just a niche job board then that's not an issue, but it also seems like one of those things that should have been done already, probably has been, and isn't popular for a reason.
There is already a large number of people who hate audition-style interviews. They don't want to defect.
A public group actually makes it easier for people to avoid defecting. It's very difficult for a job candidate to talk to employers about this when you're just some lone weirdo with idiosyncratic principles. It's much easier to have that discussion when there's a public group of people you can point to with the same principles. There's strength in numbers.
Consider it a kind of "Alcoholics Anonymous" for interviews. You wouldn't say that can't work because people defect. Yes, people defect and drink again, but they joined AA in order to avoid drinking, and the purpose of the group is to help them with the goal of not drinking. And also to remove the private shame of admitting a problem, by showing publicly that it's a very common problem. This is not a perfect analogy by any means, but the gist is similar.
Great point - there will be a giant incentive to defect. I'm not interested in policing it.
I'm interested in raising the incentive for people to say no.
I'd do this by offering another job board for people who aren't likely to leetcode anyway. I would tailor it to people with great open source projects/ experience that might get looked over in a more traditional interview.
I would give this at least a cursory glace. This is how SO careers was marketed to me back in the day (regardless of whether or not that was true) and it ended up landing me in an interview process that was not as terrible as it could have been.
I'm with you on this. That said, something like this is happening anyway it will just take a while to play out. If companies keep interviewing like this, it will keep on selecting in a certain way and basically exclude people who aren't willing or able to play this game. This will impact on the company's products in the long run but the problem will be hard to notice if the company sits on a lot of money still, until it doesn't.
You're right that it's happening anyway and will take a while to play out. I'm interested in hurrying that change along if possible. I'd also like to give the people who aren't willing or able to play it more of an alternative.
30 years ago software engineering was probably a few bunch of technical skills. Now it's a very big spectrum, no individual knows everything.
Someone applying to search quality team at Google that works on search algorithm really wants someone who knows algorithms..
but that may not be the case for a web of app developer.
but the same app developer needs to know have algorithmic sense to do some performance tuning.
The current interviews ignore all these nuances and simply ask a weird, sometimes boring, competitive coding question. That's fine too.. most engineers enjoy a puzzle once in a while.
But what really irritates me is sensitivity of assessment in these coding interviews.
Someone the other day was saying Cracking the Coding Interview book is no longer relevant. The problems are apparently simpler to what people ask in real interviews.
We don't just have to provide pseudocode. Write working, beautiful code, solve the edge cases and speak to the interviewer while doing all of this. I don't know since when engineers actually talk and code at the same time during working hours.
The phone interviews are a joke. In a 45mins meeting, where 10mins spent on introduction from both people has zero weight. In those days it was supposed to weed out non-serious candidates with fizz-buzz question. Well' agreed fizz buzz isn't really a good question, but neither a LeetCode Hard DP question to be solved in 30mins.
I agree and also don't get it: I barely write real code in my day job as the only coder on a project I own. I mostly go in, make notes on what looks bad, then fix it later, but the majority of the work isn't writing code and sometimes even I have to look up the proper `case` statement syntax or something. I can imagine being nervous, going in to do FizzBuzz, and bombing it, even as someone who has coded since I was 14 (I am now much older). We need to stop worrying about coding expertise and start thinking about how a programmer visualizes and thinks about data and code flow, that's the important part. Syntax can be forgotten, the semantics of programming are the important thing.
I was a teacher for a laughably short time, and I think what you are talking about would be called an "authentic performance task". Also, I think what interviewers are attempting is called "assessment", and I can say these tests are the absolute laziest version of it.
Genuine assessment is very hard. I worked at a leading bootcamp you would know the name of and was asked by $BIGCO to create a one dimensional assessment for all (guessing) 10000 of their programmers, so they would know who to fire. I refused. It isn't that simple.
I think a company like hackerank likely got that contract.
I am not expert enough to weigh in heavily on what's the best way to do that, but I feel like "software engineer" is just a title to make us feel great while we assemble our components much like the workers on an auto manufacturing line, but with a tiny bit more education and day-to-day work differences. However, with all the low-code and other tools which make it easier to write software and deploy it (crappy software, but "it works") soon we'll see "software engineers" turn into "software assemblers" or something like that. Sure, there will be a handful of programmers who will need to code those tools, or specialize in algorithms or writing code on constrained environments (embedded), but those will be the surgeons who make all the money, and the rest of us are the closers (whatever they call the surgeons who just sew things shut and finish up the procedure).
Lol. I took the teaching job because I was bored with "software assembly" (nice name). It was fun to get drop shipped into a random location in the world and go toe-to-toe with their best and brightest.
I've since moved on to embedded development, and it is as you say. I've recently got to work on tensorflow light, pytorch, rust, object detection, compute shaders... it's amazing.
The big company stuff can be a bit boring, but I can also say there's some pride even in the "glue". The team I was most proud of implemented Heroku-flow in their proprietary cloud using some kick-ass devops skills, figured out some innovative ways to solidly test their creation, and also got to write a genuinely comp-sci database diff tool to migrate data nightly from the original thing into their re-write.
If you can build the trust, there's most often a good route to turn a terrible, untrusting, corporate monstrosity into something decent. But that being said, it takes a ton of passion and also sometimes it will just be dull and a hobby project is probably a necessary relief valve.
I love your comment, thanks, it gave me a bit of hope, which is more valuable than most other things in the world (my son gave me the hope needed to get out of depression, maybe you will give me the spark to make my company better?).
Yes, it's not 1:1, but the comparison is apt, IMO. I worked in a factory that had a semi-technical assembly line, in other words we had to train the workers to some level of technical competence (medical devices) and I see parallels in how I was onboarded at my current company. They don't care about your technical designs or how good your algos are, they just want you to pump out ticket completions as fast as possible, ensuring you follow the procedures to the letter, no matter what. As someone who thinks highly of my own abilities (why wouldn't one think highly of themselves?) I feel like my growth is stunted and my full abilities aren't being used because of the strict environment and procedures. I understand why they are there, I know they are important for quality (I was a QA manager at that factory) but I think there are better ways than treating coders like assembly line workers.
Don't take the comparison too literally, the actual work of putting a machine together is different than coding, and I'm not talking about "sticker applicators" type assembly lines, I'm talking about high-tech assembly lines like what I experienced (medical devices, in this case). I did base my comment on more experience than a few "How It's Made" episodes, though.
Agreed. There's one in my family. She's literally putting the same kind of sticker on the same kind of car 8 hours a day for months or years (they rotate positions in factory so that people don't go crazy - but retraining for the new position is a matter of a couple of hours). She's basically a biological machine augmenting the factory pipeline and the company has her only because for now she's cheaper than a robot arm. I see zero parallels between that job and software development.
> "In the past, when I was interviewing myself, I would come across large numbers of really smart candidates all the time. Once in a while, though, I'd find someone exceptional who could approach problems differently, and those people would always turn out to be the best hires. They would have been filtered out by these systems."
This reminded me of a quote I once heard (on Slashdot if I'm not mistaken).
"There is often a mentality in the workplace that with sufficiently detailed protocols and procedures, the village idiot can perform theoretical physics just as well as Einstein.
In fact, no amount of procedure will make that happen; quite the contrary, all that procedure ensures is that if you ever do hire Einstein, their output will closely resemble that of the village idiot."
On the other hand, I've seen well-managed organizations that allow a team of competent but not necessarily exceptional group of engineers to accomplish exceptional feats and also the opposite, where a team of exceptional individuals but without any coherent structure led to dismal results.
Indeed. In fact, I would think this is in fact supportive, rather than contrarian evidence for that quote, since both are arguments for good management practices that prioritise individual humans and their complex abilities and personalities (whether as individuals or as team players) over abstracted metrics and automated processes.
I was just griping about this earlier today. I'm in the interview process with a company, who has talked to me before, after being referred internally to do so. I've talked to them about technical problems I've solved in the past, discussed problem solving and approaches to optimization and architecture. Interview process has gone really well.
They said the last thing is a code test, that they do through Hackerrank. I figured ok, I'll go through some on Hackerrank and get the hang of them, since I've never really done much on these types of things. I did bomb out of an interview process last year that was strikingly similar, with a final step of random algorithmic code test that was timed/monitored and I struggled on.
I spent 2 hours working on Hackerrank stuff just to realize:
1. It's virtually all either 1+1 intro or comp sci stuff. There's nothing there remotely applicable to any work I've done in my career, which has included numerous positions of architecture/scalability/emergency fixing.
2. A lot of the problems are very poorly described. After an hour of failing to solve one, with no feedback on what strange inputs were failing (because the ones it would tell me all passed), I finally clicked the editorial part. And it began with "here's the obvious solution, but that won't work because it's O(n^3). Well no sh*t, I'm aware, but this is a stupid brute force exercise and there was no notice of "be efficient, must solve using linear algebra."
In the past, a couple places have done a code test that is basically "sit down with Jim for an hour, he's working on XYZ problem, and see how you would approach it." Those have been the absolute best code tests, both for me to show talent and for companies to judge me.
Anyways, time to go bomb out of another candidacy at the last stage.
I haven't used Hackerrank specifically, but some other similar tools, and yeah, those were my exact feelings. Self-taught, been doing software professionally for more than 25 years, and have rarely ever needed anything close to the types of math/compsci problems these services test you on.
The 'sit with someone for an hour' are far more indicative of how you'd work with someone because... you're working with them. 2 years ago I did a "remote pair code test" with the team lead for about 30 minutes. I think I got most of the 'test' done in half the expected time, and we talked about where/why I cut corners, how you'd test it, what sorts of things you need to keep in mind to address edge cases, etc. I got to see what working with the team lead was like in that case, and... ultimately, it wasn't much different after I got the gig.
In order to prepare for eng manager interviews a couple of years back, I quit my job and spent several months on Leetcode and system design. This is with 8 years of management experience at the time and many years without hands-on coding. I landed a FAANG job as a result, something I would have 100% not been able to accomplish without the prep, so I suppose it was worth the effort.
The not-at-all-surprising end result is that my role has no coding or system design expectation, nor is there time for that even if I wanted it. I'm exactly the same person, doing a not-entirely-dissimilar job to my prior experience, yet I would not have been considered a desirable candidate had I not jumped through these hoops that bear no relation to actual responsibilities.
Now that I'm on the inside, I don't see any particular conspiracy to select for people that are willing to jump through hoops. Yet I have a hard time reasoning out why else my candidacy would undergo such a drastic transformation otherwise. It's a sad state of affairs indeed.
This betrays a lot of what tech culture is. People do it because they enjoy building stuff. We don’t have hazing or never did. I guess the money just got too good, so nothing good ever lasts.
> Once in a while, though, I'd find someone exceptional who could approach problems differently, and those people would always turn out to be the best hires. They would have been filtered out by these systems.
This is the goal. When you’re a large org, you do not need exceptional people, you need foot soldiers who do what they’re told.
Yes even in engineering. Most of the day-to-day work boils down to JSON bureacracy and code archaelogy.
Remember: They pay so much because otherwise people wouldn’t stay.
I think someone who can approach a problem differently and effectively, can also follow orders just fine.
I like to try new things and approach things differently, I don't do it with every task and recognize there is value in doing it the same old way at times too.
Way too many tests and etc assume that people can only do X, or Y or Z.
Oh totally. The problem is that folks like that often get bored by the job.
The number of stories I’ve heard of engineers having to microdose just to get through the day because working on 1 button for 6 months kills their spirit ...
I wonder if interviews should consist more of reading a pile of open source and just trying to make sense of it.
There's some crusty open source I've had to deal with whereupon it took quite some intelligence just to get it to compile and work - absolutely nothing to do with 'algorithms'.
I'm half inclined to just say: "Here's a git repo, build it, modify this thing to do that" and if they can, they're gold.
I'm not sure what language you work in the most, but based on the build issues I might guess c++, in which case I'd say check out conan central. It's still sad compared to other package managers, but if you're building c++ all day, it's a game changer.
Thanks for that - you guessed it - C++. It's like you think you speak English but then you walk into a pub in Pembrokeshire and you absolutely cannot understand a word anyone is saying, even though ostensibly they are speaking English. C++ will forever be a 'distant second language' that is different in every project. It's very frustrating.
As a consultant to large orgs who was paid handsomely to fix the situation you describe, I can say that is exactly what they think, and also exactly wrong.
[edit] Many people in these orgs are doing exactly that. Having come in, diagnosed the ultimate crap that kept them on that 1 button for six months, helped give them the autonomy to do what was needed helped everyone involved, from the devs to the PMs to the division itself.
It's a common and insidious pattern, but even big companies benefit when it's broken.
I hate to tell everyone this, but this isn't new. It's been this way for 25+ years. This is just a new form. There were the "brain teaser" questions in the late 90's (How Would You Move Mount Fuji), and then there was the whiteboard coding (reverse a linked list). It's always been this way, and IMO it's stupid, but there will always be companies that do this. I've been discounted, because even though I did what they asked I didn't go above and beyond on the "test assignment." You know what, I don't want to work for those companies anyway, so I consider it a boon they asked it in the first place. There will always be people are that are gatekeeping and trying to show they are the smartest person in the room. If you and I can't sit down and have a conversation and determine whether or not I can help your team without some silly test about writing a loop, you're wasting my time.
As someone who has been on both sides of the table, I don't really know what some 45 minute HackerRank test is supposed to demonstrate that can't be learned in a 10 minute modified FizzBuzz. Probably 95% of software development jobs don't need the kind of algorithmic expertise that these HackerRank problems try to test. There just needs to be confirmation that this person's resume isn't a complete lie and they actually have the skills it states.
I refuse to take any such tests, and I've had no trouble finding employment. In a world where recruiters are blowing up your inbox, the ball is in your court.
One time I interviewed somewhere. It wasn't a perfect job, but I would have taken it if the offer was good. After the interview they called and wanted me to take some kind of test. I said no. They called me at least two more times to see if I wouldn't reconsider. That made me think wow, they must really like me from the interview. Why not just make me an offer? But no, they didn't call back after I firmly denied them. Maybe they learned a lesson, maybe not. Not my problem.
And that's the final lesson. If a place has this kind of hiring process, that is already a red flag that this is not a good place to work. Even if you took the test and they made you an offer, it would not be a good time working there.
Can confirm. Competitive programming is the new normal as we all hyper optimize our selves for the corporate overlords. Watch some videos from the top competitive programmers, crack a book, and crush leetcode. This is the way.
I think it’s a waste of time and boring as hell but 9 times out of 10 nobody is ever going to look at your accomplishments or work history unless you’re coming out of a FAANG.
Just memorize Two Pointer, Depth First, Breadth First, Binary Search, and Dynamic Programming. Solve leetcode problems. Most people recommend 200-300 before applying to FAANGs. Turn the descriptions into Anki cards and learn to site read them for TP, DF, BF, BS, DP. Keep a soreadsheet if your solve times and each puzzle’s solution type. Optimize, optimize, optimize.
I don’t think it’s a good system but that’s what we have.
It's easy to complain without giving a better alternative.
I see these kind of articles on HN all the time. But nobody really gives a better alternative.
Same in this article: "In the past, when I was interviewing myself, I would come across large numbers of really smart candidates all the time." So how did he know they were smart?
So anyone with experience in interviewing candidates have a better alternative than letting them code and asking technical questions?
The same way you size up anyone else's aptitude, really: by making them feel comfortable, speaking with them honestly, trying to quickly figure out what excites them and asking lots of follow-up questions. When someone is eager and bright, and they've been made to feel relaxed, it's usually obvious.
Conducting a great interview is hard. It requires some mentorship and a ton of practice. Not everyone's cut out for it. But when a technical interview is led by an experienced technical person who knows how to interview well, the candidate knows they're being assessed fairly, and you get far more valuable information than you would from these coding challenges.
You ask them about a previous project they've worked on, or a problem you currently have and take it from there. You are bound to hit interesting problems where you can ask them what they would do, if they've had similar issues, how they solved it, what tech they used and why, would you do it differently now, etc.
If you care about performance and data structures you can dig in, you can ask what bottlenecks they had, what structures they used. I've had a lot of success just asking in the middle something like "why not use a list or vector?" (in C++), the discussion that follows tells me already if this person knows how memory works, how algorithms scale, etc and this are things I really care about in my industry, not just random trivia.
All of this is done as a conversation, I want to minimize their nerves as that just obfuscates the real person I'd be working with.
I get none of that info asking someone to invert a binary tree on a whiteboard.
"Can you tell me about a hard problem you've solved?" is usually enough to kick off a good dialogue. It gives you a little peek into their approach to solving problems, but also tells you what they think is hard. If you ask good follow up questions, you'll very quickly have a solid understanding of their current experience levels and a rough gauge of their aptitude. A lot of it comes from intuition and experience interviewing and hiring.
Building out a great team is more art than science, and you won't ever hone that craft by throwing coding challenges at your applicants - you just end up with a group of people who are a bit more likely to be very good at jumping through arbitrary hoops.
Pair-programming session building a small "feature" that's relevant to what you do for a living. It's almost like a mutual assessment between two engineers in a real-world scenario.
Leetcode is the current meta of the developer career. As all metas, you can choose to ignore it, but if you want to maximise efficiency, you need to play by the rules.
Also many companies have systems that encourage this. For example, currently I am a mid level developer at some large software company. To get a promotion to senior level, I need to "consistently prove I can work at senior level". In practice this means spending about 2 more years of assuming the responsibilities of a senior, delivering large impact projects, coordinating team members, writing endless documents, and get a committee to approve my promo. After all that effort I will be given a new title and a meager raise.
Alternatively I can spend 3 months grinding Leetcode and Systems Design, interview around with a few companies, and cross my fingers. If I'm lucky I'll get a senior level offer. If I'm really lucky, I'll get several, engage them in a bidding war and substantially increase my compensation.
> If I'd had the opportunity to read-up on it, I would have been fine.
This highlights the paradox of Hackerrank-style tests. They would make sense in an age where the overhead to refresh your knowledge about something took time and effort: Find a relevant paper book, read it, perhaps type-out the examples. But in that age. where they would make sense, we didn't have the technology to make them available to the masses.
Today, where refreshing your existing knowledge only takes a couple of minutes searching online, these tests actually do a bad job in telling apart the code-monkey from the expert who happens to be a bit rusty on a specific topic.
The point of hacker rank isn't to tell apart the code-monkey from the expert who is rusty. It's to find the people who are willing to spend hundreds of unpaid hours grinding leetcode. The thought process is that you only need two things to become a successful developer. Baseline critical thinking skills and the willingness to spend 60 hours a week reading up on best practices. If you can pass leetcodes interviews you've probably got both those. Figuring out if someone is an expert coder is hard, figuring out if they have these skills that you believe are required to become an expert coder is easier.
Still, it makes little sense if the applicant holds a BSc/MSc/PhD on the subject. These degrees require many more hours of commitment than the time you need to master leetcode. Moreover, the scope of leetcode assignments is rarely broader or deeper than an advanced-course assignment. Just take 5' to go through their academic record, take their professional experience into account, and you're done. No need for dubious "magic" solutions and useless charades. Even if you include cheaters, what makes the recruiters believe that someone who has cheated their way through a comp-sci master's program will have trouble cheating to inflate their Hackerrank?
I've got a PhD in statistics and consider myself a pretty good data scientist, but I am not a computer scientist. The last job I applied for asked me to perform a coding challenge prior to a possible in-person interview. The challenge was heavily focused on algorithms and data structures, almost nothing about statistical inference, causal inference, experiment design, model fitting, etc. I didn't bother submitting my answers.
I've got a feeling that these large corporations have started to realise that the 'data scientists' (commerce and engineering grads that know some python) they are hiring are all pretty useless because they don't have the engineering skills to actually get anything done.
A lot of the job advertisments for 'data scientists' I see these days focus WAY more on things like 'AWS, Spark, building pipelines, etc' than statistics and modelling skills.
Slightly related note, I'm seeing a silly number of advertisments asking for PhD's in quantitative fields and experience with PowerBI. That'd get me running for the hills.
Data Science and Machine Learning are buzzwords with little jobs behind them.
There's work to do around data (databases, logs, analytics, marketing, business intelligence, etc...) but none of it has to do with stats/maths. The realization is quite hurtful for those who wished to pursue data science.
The only field that recruits maths folks is finance, specifically quants, who are doing financial analysis all day. It's only a few roles in a few places and highly selective.
Yeah, tooling is the heavy work. Most of the times a simple KNN model baseline is good enough starting point.
People are impatient to do math, they'd rather want to try 100 things at once, see what works. So I am not surprised they don't care in the interviews.
Only when someone writes a fancy engineering blog post or paper, weird equations appear out of nowhere..
This is so much visible in deep learning papers. The equations are there just to impress.
I've hired a lot of people out of FAANG. In recent years, there are developers there who are extremely polished at these style of interviews, which makes them seem very impressive, but don't know anything else. The minute you step outside what they've been practicing for, the façade of ability crumbles. Increasingly, I suspect these interviews are overfitting for people whose only skill is that they spend all their time practicing for these interviews. In my current hiring process, we've needed to do things to weed these people out because quite a few have been getting through the FAANG filter.
I've worked at FAANG and gotten offers from the rest, but I can't view leetcode as anything but a hazing ritual at this point.
Holy crap, I've seen myself in the op here. I used to love coding, owned a c64 and wrote games and other small utilities when I was only a toddler armed with the "programming guide" that came with the ol' breadbox.
After 10 years of "srs coding" I felt like I was burning out and I was burned out. Because the feeling of discovery, solving people's problems and teaching the good stuff kinda disappeared in the churn. What I felt was I was adding data to a database and retrieving it when needed. The software did the required transformations that's all. Back then I was writing Java mainly and its verbosity kinda added to it.
I am not an engineer, my diplomas are on philosophy (bach.), sociology (m.a.) and international relations (bach.). And I used to feel fun and joy while doing that. Now it's all about buzzwords and creating stuff that's not neither usable nor fun.
Anyway sorry for the rambling but as a person who is in his late 30ies I didn't imagine this present, where I feel queasy from coding and think I should "relearn" the trade.
Generally, I'm more likely to hire someone with interesting hobbies than someone who has completed HackerRank tests. I don't find it compelling to see that a candidate has accomplished standardized metrics; but I am swayed by non-computing hobbies. Synthesizers, painting, rock climbing, volunteering, and so on are indicators of a curious mind that's happy to apply itself.
But do they still have to pass a bunch of HackerRank-style interview questions?
The best interview question in my life, a few years ago, was one where they gave me an open-ended question, a laptop, and the whole afternoon with occasional checkins to see how I handled it. The evaluation was completely subjective.
That's hard to standardize at an industrial scale, I understand why FAANG can't do that, but smaller shops really should and stop denying themselves acquirable talent.
I think it would be nice to have a pair coding exercise where you're given a snapshot of the company's code base from a year ago, and an actual, simple, historic ticket to work, and the interviewer kind of acts like it's your first week and you are getting to know the codebase.
We don't have any technical quiz as part of our interview process. We look at experience, education and creative outlets; then folks sink or swim upon being hired.
So far we're batting fairly well. Folks don't generally lie about their experience.
In my youth I wound up in charge of hiring at a low-end shop due to a funny set of circumstances and absolutely got burned by people straight up lying to me.
If I were more experienced, I'd have been able to ask the right questions about their alleged experience and smell the BS.
We tend to catch the liars when we talk to them about the particulars of their experience; it becomes quickly apparent that they are being dishonest when they cannot answer technical queries.
I've used this process for about ten years now, and it hasn't really burned me yet.
Maybe your company is too small for data structures and cutting every 0.1ms latency count. As an example at Google I needed director level exception to introduce 0.1ms latency to the ads server (which wasn't needed at the end, but the monetary damage for timeouts is real).
Understanding basic data structures and how the computer works is important in these cases, even if you just need it once in 3 years.
The rarity of this scenario is not remotely close to once every 3 years, and not everyone is interviewing to work on something so obscenely performance dependent.
Probably >99% of developers will never encounter something like this in their career.
Fair, but for those unaware, ads infra at Google etc. are a class of their own because it's the starkest place in the pipeline where latency = -$. More like high-speed trading fintech than regular engineering. They don't care anywhere near as much about services (possibly--but possibly not even--google.com).
That sounds interesting. I would have a job by now if someone valued the fact that I like memorizing Ancient Greek poetry :) Instead I failed my last interview because I took longer than half an hour to implement JSON indented stringify in JS and did not use template literals and a switch statement. It was my first technical interview ever after 10 years of developing software. I did not expect how much being watched and trying to fulfill several unclear expectations would hinder my performance on a problem, which I would otherwise consider very easy.
You don't have to do it. Depends on how desperate you are for it. I've had a successful 10+ year career in web dev in the UK. I've always avoided places that had a technical interview, it's a phobia of mine.
I've landed multiple contracts without any technical interview, a couple of them from just an informal chat. I once kept rejecting an interview for a company that specified a tech test, then 6 months after they first contacted, the recruiter said they'd dropped the tech test, I phone interviewed then went in and got the job.
Granted these are not the FAANG type places that Americans seem to be so obsessed over, but they look good on a UK CV and every contract I worked on was >£100k pa. I have never had any desire for prestige-type positions, what matters to me is an interesting project where I can develop skills, good rate, and good working environment. Ultimately the high rates of these contracts allowed me to work less and ultimately enjoy freedom which is my main goal.
It's the same in UK
Went over interview process this year. A complete joke with no name startups asking the most absurd things for middle level positions
When I hire, I would be happier to hire older (>40) engineers; they have more experience, they are usually done with job hopping, and are also mostly done with resumė stuffing and buzzword bingos that includes the latest framework.
However, it seems that those older people that I want are not actually looking for a job - they either found their endgame in tech or realized that they have to go to management/consulting for better salary and control.
Many of the 20-years of experience that do apply are better described as “having 20 times the same 1-year experience”. They are not any better than a recent grad despite those 20 years, but they lack the energy and expect much higher pay and automatic respect for their opinions.
The rare older engineer who wants to keep doing technical work, has learned from their experience, and can actually deliver is very valuable. Many people describe themselves in this population and complain of ageism but very few actually are.
I guess companies do very tough interview to justify high salary. Let's say Google and some-small-shop have same interview for exactly same job position and responsibilities, and only one of them pays really well.. I am quite curious how the economics of market will shape out
when someone has a spouse, two kids, a mortgage to pay, a whole bunch of daily chores to finish, pressure from manager to finish under tight deadlines, a simple depth first search looks like a very big problem at the end of the day.
People pay cognitive tax that robs them from doing intellectually difficult tasks. This is well documented in behavioral economics. "Scarcity: Why Having Too Little Means So Much by Sendhil Mullainathan and Eldar Shafir"
I'm very sympathetic to the idea that a more objective test like interview format eliminates bias from the interviewer, as well as the idea it allows introverts or those not as well versed in storytelling to be successful opposed to traditional 'sell yourself' interviews.
However, it's a huge waste of time when so many of the questions are the same. I get it, every company wants to know if I can turn a list into a balanced BST, it's not an unfair question, it's not particularly hard, but I really get annoyed I have to keep solving it over and over.
I really wish there was some certifying body that would put me through the whiteboard guantlet once, and then I could just share my score to companies I apply to.
This seems like a pretty good idea on the surface. I'm curious how the SAT and ACT standardized testing in the US came into the position of almost de-facto standardized college entrance exam. On the other hand, I've wondered why a similar thing doesn't exist in the real estate industry for home inspections. A good inspection costs a lot of money, and it seems basically every serious buyer needs to pay for it themselves. Why doesn't the seller pay for one up front and share the results with interested buyers? Certainly there's room for corruption / cheating, so maybe that's why? The same concerns would apply for a standardized whiteboarding. Not to mention that some kind of interview would have to happen anyway just as a context for getting to know a candidate. Personally, I think it's actually good that this happens in a technical context and, as others have said, is not completely based on a verbal conversation.
"Why doesn't the seller pay for one up front and share the results with interested buyers?"
In the Bay Area they do. No one makes offers with an inspection contingency because it's so competitive but often the seller will already have done an inspection that they share with potential buyers
>I really wish there was some certifying body that would put me through the whiteboard guantlet once, and then I could just share my score to companies I apply to.
In my field (actuarial), we have a ridiculously long credentialing process that involves 10 exams, which can take 8 or so years to complete. And many have the opinion that the tests are unfair and wish they could just have technical interviews instead.
Then there are some companies that don't trust the credentialing process and give you a technical interview anyway, even after you had proved yourself by finishing the exams.
I've tried to actively go against the approach described in this article when I'm interviewing candidates. We allow thirty minutes for live pairing on a pretty generic task. Candidates are using their own device, so whatever OS; IDE etc they like, with desktop shared by video. The idea is to match the work environment as closely as possible, so all resources are available to them- Google; stack overflow; other people's public projects etc. We don't expect candidates to complete the exercise in the time available but we do see how they tackle it
I've always preferred to give very serious candidates some technical homework. Make an API that does this particular thing. You have two days. Then we look at what they built and talk about it. It's way more realistic because that's how we actually work-- nobody is coding algorithms on a whiteboard. To any extent, it has worked very well. The people that have done great ended up being great employees and the people that did just enough to pass also did that once they were hired.
The problem with the rise of the homework approach though, is that unlike you, most companies don't treat it as an alternative to whiteboard leetcode interviews. They treat it as an addition to the whiteboard leetcode interview.
It also doesn't scale. The assignment is for one company alone, so if you get rejected, that's time spent down the drain. As heinous as leetcode interviews are, the effort spent grinding leetcode can scale massively horizontally.
Multiply that by the number of jobs someone typically applies for when they want to change role and you're likely contributing to someone not seeing their family or friends for almost a month. Also... Is that 2 days total dev time, or a deadline that's 2 days away? Someone with few responsibilities and a willingness to forego sleep is likely to put in far more time than someone with a family of the deadline is two days away.
It sounds like your interview process is designed to push away people with families and friends. Let me guess... Those great hires really put in the extra hours?
We've been trying to hire a part-time contract dev recently and we hate the process so we've been a little half-assed about it.
As a result I think we've stumbled across a fairly effective approach.
We ask them to do a half day to day coding task based on a real requirement. We pay them for this as we have few enough applicants that we want to test that we can afford to.
We give them the requirement as if it came directly from the client. It's incomplete and there's a few assumptions they might make that would be incorrect.
It's fascinating to watch how people have approached this. We've only done two so far but the degree to which they ask the right questions vs leap in and try and code their way through it is revealing a lot.
Our initial setup instructions had a couple of errors in and this too has been really useful. Watching how they respond and how they resolve the problem.
It's remarkably close to real world tasks - poorly worded requirements, problems with documentation, missed assumptions that it feels like we're testing the things we really want to test.
The difficulty is that we can't come right out and tell them this is what we're doing and the artificial nature of the test might make them less likely to ask questions that they would ask in a live task. We've tried to drop hints to guide them into doing so however.
Huh. On three separate jobs (small tasks, few hours to couple of days) I was told, after asking some questions, "stop bugging me and just write the damn thing".
I would probably not ask any questions on any new task of that sort and just randomly pick something. To be honest, that might not even be intrinsically bad - the client can always change their mind even if I write exactly what they wanted, so "write something and show it to me" is probably a good idea.
Yeah. We would have accepted that. We did explicity say several times "ask questions. we're here".
Our desired outcomes were (in order of preference:
1. Ask and figure out the task was easier than it might have seemed
2. Don't ask but make the right judgement call
3. Don't ask and overcomplicate things because you've assumed the worst.
(For example - the task could have been done with no UI and just a CLI interface. We never said it needed any user facing elements. We wanted to see if they jumped to conclusions. So far everyone has assumed it needed a web UI)
I once had an interview like this from a very large e-commerce company in Seattle (though I did not get paid, at least they paid for my flight and hotel and food. A good deal for a college kid). Though the coding problem was less "poorly worded requirements and bad docs" and more "this is actually an NP hard optimization problem".
Some of the thread can be a bit depressing, so I want to try to cheer it up a bit by enpowering us :-)
I’ve been building tech hiring processes for a bit now, and here is one far-fetched corollary of Conway’s law I believe in: tech hiring processes reflect the value and internal behaviour of companies.
So pick the process you get recruited by wisely.
You have to go through a whole slew of leetcode questions and double-indirection array inverting tricky loops to get a foot in? Expect the same mindset to apply to mentoring, promotion and getting any big thing done.
At the opposite side of the spectrum: if you’re hired no question asked with a 3to5 letter language in your CV and blabbing about having done some HTML at some point, expect some very fuzzy internal politics and decision making flow...
Here is the thing though: in most countries I recruit in, tech people are in demand.
Pick the process that reflect the type of company you want to work in.
Maybe there’s a tech job crisis I don’t know about, but we, as recruiters and recruitee, dont have to accept this state of affairs.
If people stop applying to some type of interview, or gently refuse to participate in the p*ssing-contest part of the flow (pun intended), company will adapt ...or die.
Tell them, no sorry, you won’t be doing whiteboard-coding with comma validation.
And if mediocre candidate learn rote leet-answers and spit them out to go and crash down BigCompanyX every 2-weeks, I can assure you the the company will soon learn and change (Google did, I believe MS did too). Or go bankrupt. Or outsource to a more sound-minded company.
I've heard myself and other say many times, "the kind of work they have you do in the technical interview is rarely the kind of work you'll actually do". This so often true, I think many of us take it for granted. Odds are strong that you won't be implementing a hash table, a question I've been asked in several technical interviews. Often when pressed on this kind of thing, I'll say something like, well isn't it good to know anyway?
I think the author makes an important point when they say...
> My technical skills have definitely sharpened up by practicing Hackerrank-style questions, but I believe the companies using these tests are creating a bias in favor of candidates who a) have time to practice and b) who've recently graduated and are familiar with the format. It's very hard to prepare for these tests if you're working full time and have a young family. It's also an opportunity to excuse ageism. In an assessment the other day I was asked to code something that I hadn't covered for 30 years. If I'd had the opportunity to read-up on it, I would have been fine.
Again, I think it's taken for granted that FANNG companies should be gated in this way since they are looking for the "best of the best". Maybe it's worth taking a harder look at this and actually try to get an idea of who these "best of the best" look like. Are they all young people with wealthy families who attend top-tier computer science programs and apply for these jobs soon after graduation? I suspect that is the case.
Many of these hiring techniques do trickle down to other, smaller companies who view whatever Google or Facebook might be doing as a "best practice". I think it's worth asking if this kind of bias is acceptable.
What I find most hilarious about it is FAANG (certainly, Google in particular, since they researched this themselves and then chose to ignore their own research: https://www.wired.com/2015/04/hire-like-google/) knows whiteboard interviews are pretty bad, but they continue to use them.
I can only assume it's a means of filtering out absolutely trash candidates. FAANG also knows they are not hiring the best of the best. That's simply not possible when you're employing 10k+ developers. Some of them are going to be less than great. Your goal at that scale is just to avoid wasting a huge amount of money on a terrible hire, and whiteboarding is decent at filtering out complete trash, but the problem is we don't train people how to do whiteboard interviews properly, so they also filter out incredible developers who just aren't interesting in memorizing a bunch of algorithmic tricks they'd normally just look up, but would be perfectly capable of implementing whatever.
I think a big part of the problem is that a lot of folks who are okay at programming but not really really good get into positions of power one way or another and then sort of gum up the works.
Story time...
I worked (briefly) at a large company that had hit hard times and then found new investors, so most people had left and then they were hiring new folks (like me.)
One meeting the CTO comes in and sketches out his idea for our new infrastructure on the board and, lo and behold, he's reinvented ethernet.
My immediate supervisor gave me a piece of code he had written using a state machine. You know that feeling when you read some code and it's like "am I an idiot or is it this code?" The state machine graph was:
A -> B -> C -> D
He used a FSM library for this. I replaced it all with about ten lines of code and bounced it back to him. I got the feeling after that that he didn't like me, but wtf am I supposed to do? Dude's my boss but he doesn't know what a state machine is.
(I was ready to quit, talked to HR on Friday, Monday they laid me off. Bullet dodged IMO.)
I'm going through the process right now and I think my favorite one was an interview with a company that basically asked me to review some mock code which had nothing to do with their business just to get a sense of a) my thought process, b) see if I really understood the language I said I knew, and c) could communicate with another engineer.
I can't help but ask myself, why can't we just switch sides? Why can't a group of us "hackers" get together, create value, and thrive?
Yeah, we need somebody to keep tabs on margins, and do marketing, and whatever else "business" but if those roles are UNDER engineering and answer to the hackers as opposed to the current system in which we are answering to business... why can't this work??
You guys very well know it is you who build the thing, that you are only giving 30% if what you can ACTUALLY do!
What if a group of us band together and give 60%?
I know this might sound hopelessly idealistic or whatnot, but, why can't it work? or, why is it not more common?
Unless you live in a communist country that takes away a person's freedom to work for himself or create a company, you're free to try it.
Having tried it myself a few times without success, I've found that I have drastically underestimated value provided by managers, sales, marketing and other professionals from other fields. Having managed technical teams, I also found that I have overestimated amount of motivations that other engineers have, and my skill at interviewing them.
However, I might be wrong, and you can earn a lot of money proving so.
I will not say I don't know why you are downvoted, since such remarks get downvoted here.
But can't we look at an alternative model where some such standardized test is used to test basic competence, and then trainees get 2 week training on the job? Afterwards, we can select a subset based on specific tests designed for the job, rather than the usual interview questions. How many of us have actually used dynamic programming to solve a real-world problem?
Eh, again, it’s a scale problem. When there’s too many people, the only respectable way to say ‘it’s crowded here already’ is to make the entrance criteria tough.
Take a look at skilled migration in western countries. We want to maintain a sane(sustainable) population in our society.
The problem is no other profession fucking pays or provides a decent desk job career.
The only positive of this level of gate keeping is that it’s keeping salaries decent. If the gate keeping disappeared, the metric fuck ton of downward pressure on developer salaries would be catastrophic.
I think we're increasingly losing the art of making and taking ownership of technical decisions that correspond to the level of the position and the job title. When the author says that "technical skills have definitely sharpened up by practicing Hackerrank-style questions", I would actually say that senior engineers practising online problems would have added value no more than getting better at Sudoku. I've been frustrated by senior software engineers who have strong opinions and can talk hours about the choice of text editors but then magically disappear when it comes to making project-critical decisions with millions of dollars on the line.
I think this is reflected in the hiring process also - no one wants to be responsible for bad hire so it becomes a group-think exercise where each applicant has to get thumbs up from half-a-dozen interviewers. This will inevitably drive mediocrity and I'm sure this also structurally weeds out any candidate who can become a threat.
I'm not sure sure the author is coming from. I have a similar amount of experience, but wouldn't say I had to "relearn coding" when I did my last round of interviews.
I've landed enough jobs without crazy amounts of studying, but knowing what was coming, I did ~100 Leetcode questions over a month. I also read an algorithm book knowing it's one of my weak points. I got a FAANG offer from my first interview, and even got feedback that I'm good at algorithms.
There's a comment here about someone who's in their 40's and can't get anyone to look at their resume. Maybe that'll change for me, but I get lots of recruiter emails. It definitely helps that I have four well-regarded tech companies on my resume.
Hate the system all you want, but you know what's expected. Either suck it up and do your leetcode and be an expert and the language you're using or stop complaining about being stuck somewhere.
so you're just saying that if the system sucks, then instead of talking about it and trying to raise awareness about how bad it is so that we can possibly come up with a solution, your solution is just to "suck it up"?
I think this interview process is not perfect, but it gives candidates like me, someone without a CS background, a pathway to enter the industry of software engineering and succeed in it. I learned programming mostly on my own, and by studying the for the interview, I learned so much about software engineering. In the end, that process of learning for the interview is very similar to the processing of learning on your day to day job and solve problems. Some of the answers to those problems might be quite obvious to a seasoned engineer or someone with a solid CS background, but I felt that being able to solve those problems puts me on par with those with more experience and CS background. I am currently at FANNG and doing as well as the other people on the team. If the interview process is all about the past experience, I would not stand a chance to get to where I am today.
Every few weeks this topic comes up and the complaint is always the same: Coding interviews have nothing to do with day-to-day work. But who says that this is the goal of those interviews? Maybe these companies simply want young, ambitious and smart people and their coding interviews measure exactly that: Young (has enough time practicing leetcode questions), ambitious (is willing to spend time practicing leetcode questions) and smart (recently graduated and still has detailed CS and algorithmic knowledge in mind and is mentally capable of solving algorithmic problems).
This culture eludes me. You don’t have to practice made up questions of varying difficulty for 5 months before looking for a job, there are great companies out there that are not Facebook or Google, and that will give you job satisfaction and a decent salary without grilling you, look for those:
1. Office friendships that last a lifetime are never to be seen anymore, all people seem to want these days is sh*t load of money.
2. What about contentment? No I need more, which eventually becomes a cause of restlessness, anxiety.
If employment is Organized slavery, interview is basically blackmailing.
One thing I've seen some companies do for Sr hires is give a tech talk. Present some past work, take questions, etc. Seems like a better way to evaluate what you actually end up doing.
How much would people prefer a more practical 1-hour exam? My company has a takehome to build a basic CRUD api app. But my impression is that most people aren't even comfortable enough with their tools to whip up a simple webapp from scratch. Given the choice, they'd actually prefer to implement a hackerrank function.
> Young people aren't benefiting from these tests either. To succeed in the testing process, you need to code defensively against edge-case problems.
I think coding defensively against edge cases is good. It helps prevent security problems. I am a bit of a perfectionist so I know I lean this way more than others, but it just seems like a good idea to me, especially any code running serverside that's user-facing (aka attacker-facing).
Author's point is it's neither an indicator for senior developers (too much CS stuff) nor for new graduates (finding edge cases requires real world experience).
In my time in college there was a lot of edge case stuff. There were autograders that would test tons and tons of edge cases, so a large percent of my project time was analyzing my code trying to find which edge case I missed that was taking a point off my score. I also participated in CTFs which are all about finding security vulnerabilities (edge cases). If the senior developer is going to be expected to write a lot of code, then I would expect the senior developer to be adept at finding edge cases. If the senior developer isn't going to be writing much code, then yes, a coding interview is maybe not so useful, and a more architecture-focused interview might be better.
When I interviewed at goog a few years back one thing I noticed is the questions themselves are not hard. They are hard in the same vein as the questions in an old game show "Are you smarter than a 5th grader" were hard. Meaning that unless you came straight from college alot of the concepts you are not using in industry and have forgot. You won't use them at google but I suspect that it has a age bias built in as they favor younger workers.
I do sympathize, but there is a flip side to this. I have worked in large orgs with many developer and engineer titled employees that can’t code at all. Zero coding skills. And their title would be things like “Senior Enterprise Application Engineer”. Unfortunately their resume doesn’t read that differently than a similarly experienced engineer that actually writes code.
I think (hope?) you're getting downvoted because most folks aren't arguing against giving someone fizzbuzz or seeing if they can loop through a tree, it's the fact that some of these tests gives you what is an obviously O^3 algorithm and you have to use some non trivial trick to get it to O^2 or something.
I’ve worked with people who led competitive programming competitions and they couldn’t produce working code in a real project. The entire project was held up by them over and over because they couldn’t figure out APIs or write anything maintainable. They were wizards at leetcode but I’d prefer having somebody who could code. Managers are just lazy and imagine these people to be magical because of how intense their brains can work at niche problems, but it’s not magic at all and isn’t even on topic. Ask some design questions
I've had people show up to an interview with a solid looking resume who can BS their way through some technical talk but can't even write a simple for loop.
As an Engineering Manager, I find that solving this kind of problems really helps in my work, and it also helped to make our interview process more objective.
When working with high-load systems, it kinda doesn't help that a person knows what "DRY"/"SOLID"/refactoring etc is.
What helps is the ability to write code that handles corner cases and does it efficiently.
I feel like there is a missed opportunity here. Some companies are going to start ditching the traditional leetcode interview questions and switch to more experience based coding questions. Will be interesting to see if it gives them a leg up in the hiring competition amongst other tech firms and allows them to scale quicker than normal.
My personal low was when I applied to a big European fintech and they sent their standard “IQ test” right away. Mind you I was applying to a tech lead or engineering manager job. Needless to say I failed. But I’m not playing those stupid games anymore. Be aware that there’re plenty of jobs where interview process is sane.
Interviews do have to check whether the requirements of the role are met by the candidate but the real value in an interview is uncovering the candidates greatest strengths and loves in the domain of the position. That tells you so much more about how they will show up every day and the kinds of value they will create.
I read things like this all the time, but it's not been my experience at all. In the last year in had on-sites 5+ FAANG companies and some late stage prominent startups, all for a Sr (L8) IC role. They had a bit of of basic code and algo analysis, but not much. Mostly design.
If you and I and everyone else knows that we can write valuable software without the need for all of this tangential puzzle practice, it seems a very suitable response would be to do everything in our collective power to sidestep the puzzle lovers altogether.
Hmm, wonder if i know the guy. 'Strat' is still a particular title, and I'm not surprised a strat is struggling to study, especially one at the VP level. The daily work is terribly demanding.
These comment threads always turn into motte (every programmer should know basic algorithms) and bailey (stop whining about spending 100 hours studying if you want to have a decent job).
- It's an anonymous source claiming 15 years of experience and technical proficiency but somehow still had to relearn basic concepts. I'm not buying it.
- I would much rather do general computer science problems than have to answer questions about the framework that happens to be trendy this year or have to spend days on evaluation projects. General CS questions also allow people to transition between domains and subfields more easily.
I'd buy it.
- 17 years ago I was pretty good with Microchip PIC microcontroller assembly. (Haven't touched it since.) Today, I'd have to pull the datasheets and spend a few days re-reading them to remember much of any of it.
- 9 years ago I worked heavily with a large, legacy perl code base and wrote a bunch of internal web apps in perl. Again, I haven't touched it since and again it would take me a while to get back up to speed on that language stack.
- As recent as 3 years ago I was heavily into a 200~300k loc PHP code base that did some pretty complex stuff (think ERPish ). Again, I haven't touched it much since then and again it would take me a few days to a week or so to get back into the swing of working on that code base.
This kind of knowledge is highly perishable if you don't use it everyday. You quickly find yourself moving from "knowing" something to "knowing how to find" an answer to "how did that go again?". It's just the nature of the business.
It doesn't mean you aren't good at or capable of picking those things back up, it just means you may need a quick refresher. Not being allowed to use references makes that artificially worse.
I think that you're being to generous to the author. Your examples are true but a job interview doesn't ask you to refamiliazire yourself with a codebase or a tech stack, it asks whether you're familiar with algorithms, data structures and basic logic in any C-style language. That's a way more general skill than the details of your old assembly codebase.
The article omits what the author's experience is and when they say "I've spent 15 years working as a developer and a strategist at leading investment banks", I suspect that their role was much heavier on the strategist side and only now are they realising that they haven't been a developer for the past 15 years.
That's only partially true. Having dealt with these from both sides, I'd say you need to be familiar enough with some language (not necessarily c-style) to be able to write code on the fly ...
This is why I’ll never make any significant money. Can’t motivate myself to learn stuff that seems to abstract too far away from allowing me to work in the things that interest me.
Same issue with math, it would do me so much good to go back and released math, but I just can’t bring myself to do it because I’ll have to start too far away from any useful application and, even though it’s important.
I wonder how many HNers are old enough to remember when Joel Spolsky shook up a lot of thinking about software hiring at the time (~2006). He had two major insights, one of which has become lost to time unfortunately and the other has mutated into an abomination over time:
- Hire based on "smart and gets things done"
- FizzBuzz
Prior to Spolsky software interviews were much more like a traditional job interview: resume, CV, talk to a manager, a bunch of questions about experience etc. Things like N years experience in language X where hugely important. The idea that you should hirer people that were "smart" and "got things done" was mind blowing at the time.
Unfortunately FAANG seems largely focused on hiring for their definition of "smart" and has virtually no interest in if you can get things done. I've learned when interviewing at these places to never mention any past experience I've had solving a problem since it always seems visibly hurt my performance.
And VC funded startups have really doubled down on the "not smart" and "get things done" category. All of the sub 1k employee startups I've worked at or talked to in recent years seem to penalize thinking about or understanding the problems your working on, and mostly care that you're constantly scrambling to get things done, even if those things are useless.
So sadly, "Smart, and get things done" has been completely lost to time. FizzBuzz on the other hand...
The entire point of FizzBuzz was to make sure that people could code. It was supposed to be very easy, and completed in a very short period of time. Again, the problem in 2006 was that there were many corporate programmers who only knew how to basically refactor legacy Java code. If you had to start from zero, which most startups did back then, you needed someone that could build a program from nothing and think about problems computationally. FizzBuzz was meant as a sanity check, not a stress test.
This has morphed into a bizarre paranoia that "most coders can't code!" Now the point of FizzBuzz wasn't to replicate the exact problem, but to come up with some other quick, easy problem just to verify that the candidate does, in fact, know how to code. But hiring managers had no imagination so they just replicated the exact example Spolsky used. This lead to candidates memorizing the problem as part of interview prep. This of course lead to companies developing harder problems, which lead to candidates studying more. When this combined with Google's famous algorithm questions (originally to check if, you know, you did in fact understand computer science) we ended up with the leetcode nightmare we have today.
It's tragic since many of the "smart and gets things done" programmers today struggle to pass interviews. But perhaps this is because companies don't really want that anymore.
Easily possible. He's worked in IT in investment banking. I did that for about 8 years; it involved no college-level mathematics, barely anything beyond 8th grade algebra.
What's even worse is when you have a different way to get the desired results and can defend runtimes but you're rudely interupted the second you deviate from the predecided best approach.
If there was a brilliant kid with a unique approach to solving the problem he would certainly be excluded by these systems.
Even worse, they say "don't worry we just want to see how you think" but I've been interupted multiple times during interviewes where the person presumes, without knowing what path I'm on, I'm on the wrong oath the literal second my answer deviates from the cracking the coding interview book. Then I'm asked to explain and I ask to just code and show it.
This is even worse imho. So I have learned to literally not think outside of the box when I interview and give them the memorization of the cracking the coding interview equivalent in my preferred programming language.
Trying to solve it your own way even if you have a good solution despite what they say is too risky the interviewer feels threatened by this new approach because they cannot follow you and are trained to rapidly rank you based on a very specific expectation.
Even worse as a female I've learned to begin all my interviews by asking the interviewers to please...PLEASE not jump in and interrupt me to try to "help me out"
I also have to provide a disclaimer that I'm about to think. If I'm silent for more than three seconds that's not thinking about how I want to approach the solution before I begin talking through my thought process it's interpreted as being completely lost. Ultimately then jumping in will count against me.
I'm serious.
Multiple interviews I'm terrified of being silent for more than two seconds but I've learned to literally instruct my interviewers to actually give me 3-10seconds to think before I speak and also please do not jump in with the answer.
The only thing more infuriating is when they jump in and say exactly what I was about to do so when I code it they think I couldn't do it without their help.
I have banned all interviewers from speaking or giving hints without my explicit permission before the interview.
This is my preferred method and it has worked well. I've gotten through interviews for top tech companies twitter facebook etc etc and work for a top tech firm as a software developer from senior to Staff and I love my job but wow....
Some companies really concern me the kind of people they are filtering for these days. Regurgitating cracking the coding interview without a moment's delay is the only acceptable way now.
I also agree with this guy. I was an engineer but not software for yrs and spent months practicing these tests to move into software and the moment I did I havnt used any of that since.
I find the revisiting of fundamentals to be valuable practice when the job hunt begins. Refresh the algorithms, pick up new skills. Yes a bit of it is playing the game but its not totally wasted effort.
I'm in the job market and I've hit a lot of these Hackerrank style tests.
They're easy. They (the people writing and administrating) the tests bend over backwards to offer the same test in many different languages. They provide unit tests and examples.
To be quite blunt: These tests just verify very basic programming skills. They're meant to filter out people who just can't code. Someone who's struggling with these kinds of tests probably needs to consider a career change.
Edit: A common gripe early in my career was the amount of incapable programmers we had to put up with. I suspect the author isn't capable of learning how to program well.
I'm assuming you have never needed to practice these problems as you already have basic programming skills and are thus able to do every Leetcode Hard within 30 minutes of first seeing the problem?
I typically do assignments from prospective employers in half the alotted time.
I don't waste my time trying to build a leetcode / hackerank profile. Edit: Compative coding has very little to do with industrial strength software development.
I had to quit coffee earlier this year because a single cup in the morning was keeping me up at night.
But, let's be honest: One of the questions that I solved was basically "detect if a string is an anagram of another string."
So cat -> act: true, cat -> dog: false.
This was just a matter of treating the string as a series of characters, sorting them, and putting them back into a string. Then, if it's an anagram, the two sorted strings match.
Can you solve that in under an hour? Specifically, can you solve that in under an hour when you can choose from 20 popular programming languages and unit tests are provided?
More specifically, if you've been professionally programming every day for ~20 years, can you solve that in an hour?
Ok sure. This explains a lot. If that's the problem you're getting, then it is indeed testing basic programming skills. But the general landscape has gone far beyond this. Nowadays this solution would probably not get you the job. Instead of sorting, you should create hashmaps storing counts of each character and checking equality of the hashmaps. And if you didn't produce the hashmaps solution within 10 minutes, you would not be competitive with the hoardes of people drilling these problems and thus producing the hashmaps solution within 5 minutes. What most people here are complaining about are being expected to solve significantly harder problems within tight timeframes. If you are interested in what these ridiculous problems can be, go to Leetcode and browse the "Hard" problems.
A Hashmap isn't "better." For example, if you need to optimize for memory, running a bubble sort on a character array will be the most compact solution.
Likewise, if you profile, there's no guarantee that a hashmap is faster or slower, or even more readable. It gets into the nitty-gritty of how memory allocation works and the overhead of maintaining a hashmap versus whatever optimized character sorting algorithms are part of your runtime.
Anyway, I've found that companies that want to ding me for those kinds of things aren't worth working for. IMO, we're better off having an industry-standard licensing board. Plenty of other industries do the same thing.
Edit: I've also spent an afternoon with a FAANG's set of practice programming challenges. I won't go into details out of respect for confidentiality, but they weren't unreasonably difficult. I only want to work with people who can solve "most" of them. (No one's perfect.)
The best analogy is like being a musician or an athlete. Anyone can learn to play an instrument or play a sport, but to be a professional musician or athlete requires something that takes more than practice. No one's excluded from those industries due to lack of talent, but the people without the talent have to take the jobs that support the musicians and athletes.
- it was hard work
- there was no way I could have passed these interviews without all the work.
- my past experience and education barely helped me for the interview
- it's not enough to be able to solve the problems, you need to be able to solve them on the spot, without much thinking, in an interview context
- I passed system design quite easily, even though I have little real-life experience with these systems. It would have been easy for interviewer to catch me off guard on real-life technical details, but they didn't care
- these companies (FB and Google) gave me a chance (even several ones), even though my resume is slightly atypical, and I'm on the older side (mid forties)
- Recruiters and interviewers were friendly and respectful. Overall they gave me a very good impression of these companies
- The whole process is very random
- I did learn some things while practicing. Not the best use of my time, but not totally lost either
- Algorithmic questions were harder at Google compared to Facebook
- The whole process was more fluid at FB (team-matching at google took forever, I was even ghosted by a recruiter after she told me I passed).