“I've had to relearn coding to get through the new interviews”
news.efinancialcareers.com
news.efinancialcareers.com
- 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).
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.
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'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.
"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."
Rob Pike [2]
[1] http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fro... [2] http://talks.golang.org/2012/splash.article
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.
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.
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.
Making them learn go is basically training for then to be better engineers though, so that's kinda better
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.
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.
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.
Part of why this has stuck around for so long is that so many people are willing to do that because it's a life-altering amount of money
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.
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.
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.
I was very skeptical about this, then I worked for one. Now I get it.
All I see is that faang is a term for expert code monkey.
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 guess that's just how it goes, though.
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!
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.
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.
Sounds like the exact opposite - they're specifically looking for people who can actually solve algorithmic problems, rather than just code them up.
The fact that the diamond in the wedding ring is worthless is actually a feature.
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 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.
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.
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.
>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.
Thank you very much for listing this. I wonder how life is for older candidates in these jobs.
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.
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.
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.
And I will speak out about it.
Every time.
Downvotes be damned.
I think that's the standard recommendation
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.
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.
For example, the only time I ever encountered red-black trees was in the context of prepping for software interviews.
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.
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.)
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)
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?
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 ...
NB: First result of an "EPR electricity" search.
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.
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.
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.
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.
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.
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.
Just sucks!!
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.
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.
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.
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.
Unfortunately for the majors in advertisement these days, that's their bread and butter.
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 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 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.
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 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.
Sometimes that means coasting and spending more time on your hobbies or with your family. Can’t see anything wrong with that.
Why do you consider it your endgame? Top salary? Interesting problems? Making a difference?
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.
If your work makes you an important person in the company, you have a strong basis for negotiation. Most people just don't use it...
often times companies will opt to pay more as a stop-gap until they find a cheaper replacement
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.
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.
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.
Work your ass off when it's important, and just work otherwise. A valuable skill is distinguishing important from urgent
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 read a lot during this job xD
One of my biggest fears is that by the time I can stop working, I won't have any will left to pursue passionate endeavors that would benefit society.
Even if I just didn't need to worry about health insurance cost, that would be enough to shorten my financial independence timeline by years.
If I had sufficient UBI to cover basic expenses for the year, I would quit right now.
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
So, if less than 4 hours and whatever is left of my brain is enough for my company, that's all they'll get
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.
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.
That sums up very nicely. This reminds me of a quote:
"Passing an exam with good grades/marks only show that you are really good in passing the exam" -- By (don't remember)
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.
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.
One of the jobs mentioned is free time rich and money OK, and the other I don't know what the payment is like, but would require credentials.
If you haven't worked in foodservice yet, I actually highly recommend it as an experience, at least in a short term sense.
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.
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?
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!
Then I got invited to the onsite where I was subjected to multiple stereotypical leetcode rounds. Got rejected.
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.
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.
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?
Where did you find time to do 40 hours of prep, and how many weeks did it take?
Most people I know spend nights and weekends prepping for at least a month to a quarter.
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.
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.
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.
While there are some things that are even more latency sensitive, I think that could become a very small niche in the near future.
You can say what you want about the business model or Google itself, but the UX is impeccable.
I am periodically in disbelief when I think that what I’m playing on the screen is being streamed by a server.
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).
I'll grant: it's impeccable under the right network conditions.
But cloud games have an advantage too and maybe we'll see new kinds of games/experiences that are not possible with local PCs.
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.
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)?
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".
Have we generally proven otherwise?
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.
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.
Look at the job listings for US tech company EMEA HQs. It's almost all sales and legal. Occasionally a pre-sales Engineer position comes up.
Meanwhile, they are hiring dozens of Devs at their US HQ.
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.
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.
The country it's good for isn't the US.
You might think of HP as a California company but they had large engineering hubs all over the country.
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.
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.
This may not be specific to IT only, either.
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.)
Exactly. It’s wild the potential that many of us hold.
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".
What is it?
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.
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.
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
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.
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.
Best of luck and don’t give up!!
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.
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.
Good luck
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.
It happens. It’s a strong sign you want to work elsewhere anyway. The problem is one of finding the right Elsewhere.
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.
I will own a desktop computer until the day I die.
Excellent post too.
Gamers will buy every RTX3xxx card that hits the shelf and every heavy duty programmer I know has at least a fast desktop and often server racks.
I don't think we need to worry about the future of the desktop just yet.
I responded with, "Whatever you guys buy - Dell, Lenovo. A 14" laptop and an external monitor would be fine."
He torted, "I've never seen anyone be productive on a laptop. Nobody here uses laptops. I'll get you a desktop with 2 monitors."
After I started, I notice he did almost all of his work from a conference room, using a Surface Book remoted into a desktop in his office.
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.
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.
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.
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.
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.
Stay curious.
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).
My email is in my profile.
What's your email? I'd love to reach out to you and discuss some openings that we have on our team.
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.
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.
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.
California isn't the industry...
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.
Maybe the only way out of this mess is for business schools to start teaching new metrics for the latter category.
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.
Edit: better sentence formation.
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.
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.
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.
Welcome to the other 99% of humanity. Work sucks, but someone has to do it.
> 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.
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.
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 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.
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.
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.
Here here!
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.
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.
https://www.youtube.com/playlist?list=PLDV1Zeh2NRsDGO4--qE8y...
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.
Appreciate your response.
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).
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. ¯\_(ツ)_/¯
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!
I imagine that strategy ( focus on weaker areas and be consistent) to work more reliably than making it a numbers game.
Appreciate your comments and hope you can see that training website through to a real product. Would benefit a lot of people like me.
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.
I am not professional leetcoder, but good enough if I need to in addition to my experience that has been good enough so far.
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.
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.
That being said if you think it’s right for you, go for it.
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.
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.
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.
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."
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.
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.
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 used to like computers. not so much anymore.
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.
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.
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"
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.
1) Interview with any sort of success
2) Judge merit after getting the position
I think a lot more people may be operating on intuition than you realize.
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.
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.
You definitely have to prepare.
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 thought about it a couple of times, and then synergies came into play.
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 think if you are becoming a Professional Leetcoder, you’re still learning how to do basic programming.
I too, want to do everything you mention, but until I get past the leetcode gatekeepers, it doesn't matter.
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.
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.
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.
It's like a relationship, you'll never truly love the one you are with, if you keep dating or looking at others.
Plus, just a general poor moral value, IMHO.
Nowadays, at least in tech, quite a few people consider it a red flag. The world we now live in.
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?
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.
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.
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.
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.
We really don't need True Scotsmans on this site.
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.
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.
If you can't divide numbers, how will you ever do algebra?
Guess what? They're different skills.
A person who is good at algebra, may not be good at all at division. I know a few who fall into that category. The use a calculator.
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.
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.
* they are a pedantic, roll your own type of place that is full of custom frameworks and libraries that you're better off avoiding
* they are big enough or specialized enough that they really need that level of knowledge
I imagine the former is more common.
And if you are applying to the latter, you should know that from your research. You do research companies before you interview there, right?
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.
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.
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.
This happened to me too, despite assurances from the recruiter beforehand.
Don't believe recruiters. They'll tell you anything to get you in the company's hiring process.
Go and look at some Javascript answers on StackOverflow, and then consider why lots of websites are so slow!
Some random examples:
* Deduplicating an array; top answer is N^2: https://stackoverflow.com/a/9229932/265521
* Deduplicating array again: top answer is still N^2!: https://stackoverflow.com/a/14438954/265521
I've seen loads of similar examples. Maybe there is code that doesn't use any algorithms at all but it's probably not very interesting code.
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
Shouldn't the process itself be biased towards people who can enunciate their thoughts anyway?
This is basically what all engineering disciplines do and it's why I take "software engineer" with a massive grain of salt.
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.
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.
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.
Interview pressures and job pressures are completely different.
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.
it was great because:
- problem statement clearly defined
- skeleton code provided
- about 2 hours to complete
- solved an actual, real-world problem
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.
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.
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.
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.
Take home projects just make the hours overt.
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.
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.
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.
Ffs is that never going to go away?
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.
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.
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.
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.
It's probably a better use of your time than studying leetcode.
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.
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.
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.
There's not much evidence that they are doing the best at hiring for those wth 7+ years experience by using said interview styles.
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.
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.
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.)
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.
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.).
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.
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.
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.
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.
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.
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.
> 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.
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.
> 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.
[1] https://blog.codinghorror.com/why-cant-programmers-program/
Basically our job is to weed out the candidates that haven't made it to "newbie programmer" yet, and probably never will.
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".
It's not. People STILL fail FizzBuzz. Every day.
But - there are tons who are great devs, unwilling to 'play the leetcode game'.
So both those things can be true at the same time.
No. This indicates a failure in the interview technique.
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.
One hit was for making machine guns target humans better. (I rejected the in-person interview.)
Another dropped me because they wanted cloud experience.
A YC company changed the job from remote to SF only before we talked.
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.
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.
If you were willing to entertain the idea of New Mexico then the labs might be an option for you.
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.
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.
Anyway, best of luck !
Yes, if you have spare time.
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.
The meet-up is a good idea.
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.
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.
Companies nowadays want you to be good in domain knowledge but also good to solve Leetcode problems during the interview. Time has changed.
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.
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.
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
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.
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.
"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.
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.
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.
In an ideal world, this would be a union.
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".
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.
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.
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.
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.
Is there another, more general term I could use? I'm looking for a term that would be as clear to as most people as possible.
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.
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.
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.
This site would basically be the same list - with the added goal of explicitly filtering employees and employers who want to hire this way.
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.
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.
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.
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.
Sounds like they want to rationalize firings in a way the blame is on the engineers.
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.
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.
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."
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.
This made me chuckle. For what its worth, I've bombed out multiple times in the past month. You're not alone.
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.
Good luck to you in your hunting!
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 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've never heard this phrase, but it's so apt to most of every dev job I've had. I love it.
(An excerpt from A Deepness in the Sky by Vernor Vinge)
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.
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.
Really tells you a lot about the candidate.
https://github.com/conan-io/conan-center-index/tree/master/r...
[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.
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.
I still haven’t met anyone who gets paid $400k+/yr and didn’t have to go through some hoops of these sorts for being an IC engineer.
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.
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?
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.
So what do you ask then? How do you assess the skills of the candidate?
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.
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.
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.
Draw your own conclusions.
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.
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.
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.
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.
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.
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.
Thank you for reading!
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.
So far we're batting fairly well. Folks don't generally lie about their experience.
If I were more experienced, I'd have been able to ask the right questions about their alleged experience and smell the BS.
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.
Probably >99% of developers will never encounter something like this in their career.
There's no surprise that people are screening for the roles they are trying to fill.
Algorithms absolutely matter, and that will be evident from work experience and education.
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.
Yep!
https://dev.to/bytebodger/why-older-people-struggle-in-progr...
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"
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.
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.
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
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.
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.
So you end-up with huge assignments and a poor reputation among the folks you are trying to hire.
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?
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.
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.
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’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.
Build the world you want to live in!
"For the moment, then, experience seems to count for nothing: it's all about how much time you can spend on Leetcode."
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.
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.
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
(I was ready to quit, talked to HR on Friday, Monday they laid me off. Bullet dodged IMO.)
Sure there are good engineers that are bad at hacker rank questions. But there are fewer bad engineers who are good at hacker rank questions.
Its just a numbers game with a filter
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?
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.
It might take more than a "group of hackers" but "a group of hackers that know each other"...
It might be that I'm hopelessly optimistic but one of my favorites quotes is by William Wilberforce, and he said:
“We are too young to realize that certain things are impossible... So we will do them anyway.” :-D
Take a look at public school standardized tests. That’s basically where we are at with tech because we can’t handle scale.
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?
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.
On the other hand, maybe it would force engineers to join the rest of the disgruntled masses and organize for a more equitable society.
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'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.
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.
> 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).
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 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.
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.
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.
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.
- 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.
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.
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 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?
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.