Senior Developers Are Getting Rejected for Jobs
web.archive.org
web.archive.org
I'm currently in the process of preparing for interviews. I'm almost 50. I'm currently talking with FANG and other well-known Silicon Valley unicorn startups so I don't feel any ageism yet. I hate it, though. But it's the reality of the industry right now. I don't pretend I'm above it, so I will do whatever I need to get a new job.
Yes, I hate them with a passion. Today I had a phone screen with a company and I was so nervous, I think I'm suffering from PTSD from how completely random the question will be, and how random the evaluator's perception of me will be based on said question. But I accept it for what it is. I'm auditioning for a role as "senior programmer", just like an actor would. That's the reality, and if I'm going to get myself a job that pays ~$400,000/yr in total comp, I will jump through whatever hoops I need to.
The OP was saying he was doing one programming question per week. Really? I'm doing 5 per night, and even more on the weekends. As I get closer to onsites, I'm going to be studying 8 hrs a day on weekends and leaving my kids to my wife.
The rest weren’t, however. I surely got points off in my interview for pointing out how practiced Alien Dictionary was for anyone studying for an interview.
Third party AWS partners can have consultants who are more software architects.
But SAs are all over the map between pure sales => infrastructure (lift and shifters) => "cloud native" architects/developers.
At that point I would rather die than adapt. I'll go do demolition with Peter Gibbons and see my kids evenings and weekends.
What I often get caught up on, and really hope to see more people in this field consider, is that there's more than one way to live a life worth living. And often to find that, it means walking away from a high-stress, long-hour FAANG-like job, even if your salary suffers.
I've known a few people who gave their 20s to Silicon Valley and didn't have a whole lot of joy to show for it after.
But again, this doesn't mean it's wrong to make the conscious decision to stay in that life. Especially if you've found a way to make it all work and you're happy.
It does not mean one needs to pretend everything is super great.
I have no problem with your claims when restricted to the valley. They are pretty much spot on for it and a good reason not to live there.
Most of the local startups are recruiting me to be the “adult supervision” and were asking me architectural questions.
Probably the hardest part of looking for and getting a FTE gig is starting over clearing a space for yourself I think. It's tough to switch from being the local expert to just another FNG.
Personally (like anyone cares, but this is the internet after all) I'd like to find a really interesting job and I don't give a rip about the money. I suppose there's always open source, but working for free violates all kinds of my internal makeup.
I'm not smart enough or ambitious enough anymore for staff but L5 is definitely doable.
Also, and possibly related if the point above is the case, I have read from various Googlers recently that getting hired from outside at L5+ is really hard.
You benefit right now, in countless ways, from past versions of those exact same people you are so tired of hearing. Awesome gratitude, and way to pay it forward.
There is a correlation between these horrendous interviews and quality of candidates otherwise, if they were full of false positives, we would stop doing them.
The problem is they produce false negatives and how do we go about fixing that? Is it even that big of a problem? These are all debatable. We haven't hit the point where hiring is SO expensive that we can't handle false negatives, we may in the future, then we'd work much harder at addressing the current situation.
Or the alternate explanation. Hiring is incredibly difficult, everyone is bad at it, and the best solution people can come up with is to cargo cult Google's hiring process.
From experience I know there are many companies that have absolutely no evidence to support their hiring process, they just do it because it's the current fad.
And I assure you whiteboard interviews are full of plenty of false positives. Particularly now that people are spending so much time prepping for the interviews. You know the saying about metrics ceasing to he useful
In other industries people just don't talk about spending 6-8 hours a week every week interviewing applicants--not even in high-turnover industries. That's an incredible cost, but it's not counted as a line item, just yet another annoyance of the annoying hiring process.
My claim is it's not expensive enough yet for decision makers to actively explore alternatives. Will it get there as supply of quality engineers decrease? Maybe. Probably.
In my experience the companies I worked at tracked it very well, and we knew exactly how many hours were spent on hiring related work and how much it was costing us. We still used the current industry standard whiteboard, full day approach.
I think the perception of a lack of quality engineers in the market is just a symptom of the problem: the expense in time and annoyance of changing jobs and the risk (or experience) of becoming a false negative reduces job mobility and heavily slants the resume stack towards the true negatives rather than the experienced people who would be more actively looking around in a saner market.
I haven't heard of a better explanation for the notion, seemingly unique to software, that so many people floating around the industry are so abysmally unqualified to work at another company in the same industry. There are historical factors, but they don't seem adequate to explain this perceived fraud problem.
I've interviewed at Microsoft when they asked me how to find the fake coin based on N number of weighings. I've gone to Silicon Valley Brass Ring job fairs during the Dotcom Boom where they interviewed onsite and I was asked to code on the spot. During that era, various companies asked me things like what the largest number was for a 2^64 number or what the current Linux kernel version was, or what the default TCP timeout was.
And since Google came on the scene with their focus on algos, the entire industry has changed again. Every year the interview process in Silicon Valley has gotten harder and harder. That's the reality. Crying about it won't change it.
If I had the power to change it, I would hire fast and fire fast, like Netflix. But that comes with its own problems as well, so there is no best solution. All you can do is adapt and change with the industry. I know I'm not smart or ambitious enough to ever make it to the highest echelons of a company to affect culture so I'm happy getting paid as much as I can until I retire.
Some of my former co-workers are STILL stuck in the same company 16 years later. I still have lunch with them at least once a year, and they are petrified to change companies even though this current company keeps laying people off and replacing them with offshore workers. They don't have the guts to buckle down and study and adapt, so they're waiting to get laid off, which is sad to me.
> I'm doing 5 per night, and even more on the weekends. As I get closer to onsites, I'm going to be studying 8 hrs a day on weekends and leaving my kids to my wife.
I'm not going to do this. No job is worth that much stress to me.
The kids can have these jobs. There are plenty of other interesting development jobs. They pay well, just not FAANG well.
It really, really isn't. Thanks for the reminder of why I would never live/work in SV. I have never encountered anything like this in many years of working and taking new jobs. Mostly they look at my resume, we talk about stuff I've done, there's maybe a couple simple technical questions specifically related to things I've done and things that the position will involve, and that's about it.
Your will power, mental flexibility and cognitive endurance -- should deserve nothing but praises.
I am going to add an additional assumption here, is that throughout your work, you were able to impress people you worked for and with, in the same way.
So you have built a network of 'admirers' so to speak, of your skills.
With that, you should, evaluate if these types of capabilities deserve more, than what you will be getting.
When you sign up to work for a company that does not particularly value your experience, your network -- but instead demands up-to-date / or needle-in-haystack interview skills -- you are trading reduced risk (of a salaried employee for a large corp), in exchange for reduced financial reward.
Other venues your own startups, your own contracts, may be joining ad-hoc contracting gigs.
In a country where most people live like kings, why is everyone so determined to become a peasant?
I have a couple onsite at FAANG coming up in the next few weeks and I decided to buy a year of InterviewCake to work through the problems. I'm trying to do at least 1 per day or so and more on weekends. I'm about 2/3 of the way through the course and will go through again when I'm done and supplement with Cracking the Coding Interview, High Scalability blog, and probably some LeetCode problems. Otherwise, I have a job right now I'm very happy with and comfortable. I can always try again if I want to give it a shot.
So I don't understand why people think there's a disconnect between Leetcode problems and day to day work. Even in web development, the fundamental skills that Leetcode tests for come up daily. Something as simple as manipulating the DOM, for instance, requires that you know about tree data- structures and algorithms.
There are lots of companies that just need a guy who knows Spring design patterns or something, and they shouldn’t be giving tough algorithmic challenges, but at certain tech companies paying highly for people to work on very diverse sets of problems, many of which are technically complicated, it makes complete sense to prefer people with very strong fundamentals.
And if you are sitting there watching them write the code, it's still a waste of time. An applicant's relative level of skill can be ascertained in five minutes of talking with them instead of 30-60 minutes of watching them write FizzBuzz or something equally useless.
Hiring in literally every other engineering discipline works this way. New hires include a 90-day probation period just in case someone can talk the talk but can't walk the walk. Good software shops function similarly.
Programming interviews are some weird cultural hazing ritual that apparently you just have to do until somebody figures out a better way and it catches on.
I use it quite a bit, for spoken language learning, programming language learning, and more.
I helped a friend get set up for Anki, and it was quite a pain, so I wrote a guide to using Anki for programming practice.
If it's helpful to anyone else, cheers!
https://broadcom.wd1.myworkdayjobs.com/en-US/External_Career...
Yes, the housing in the immediate area is expensive (Boulder County, CO), but there are many more affordable places to live within commuting distance.
What's your hiring process look like?
What does Rally Software make? Edit: Ah, ok, found it. Nice.
Making sure that developers have the "needle in a haystack" solution that you're looking for almost guarantees that you'll weed out the most talented folks -- the ones who are programming generalists that can reason about and solve any kind of programming problem.
I chose my next role because they didn't ask me those questions and instead asked how I'd tackle problems.
Engineers have enough market power to change this if we choose. For some reason, we just choose not to.
You know you can solve such problems (sometimes even enjoy them) but the conditions you're solving them under aren't at all remotely reasonable. Giving up admits defeat and what makes you a skilled engineer, part of your identity/character, is that you rarely, if ever, give up on a problem and love a challenge.
I think we should view this as a different challenge all together instead of the one presented. Let's understand the presented challenge is silly and look at the problem as a need to change the presented challenge to something all together different utilizing our skills.
Maybe the problem isn't 500 applications, but rather an organization that is trying to hire too fast by not being specific enough to hiring personnel and services. Shotgun approach is a very effective way to generate spam.
Regardless, any job for which an automated online test can reliably be used to filter candidates is a job that's at most a few steps away from automation.
this doesn't make these problems hard, it just makes them inconvenient and a poor measure.
there are only a handful of Advanced algorithms that I have had to implement from scratch in industry. data structures on the other hand are usually the bottleneck where I find myself needing to be more creative.
this is possibly the same category as white boarding, this is not hard just inconvenient. I would even argue that whiteboarding is much more necessary than algorithms problems, as a measure of ability to communicate over a technical Topic over a live edited interim document.
the biggest problem against these algorithms and data structures tests, is that they discriminate against those without a traditional academic background. if your company does not often enough run into inability to solve these problems, then you're testing for the wrong thing
two things I have found useful in this space, for every interview I ask in advance whether I'm going to be asked to these questions, and I am very specific about what I have experienced in. If any questions are asked outside of my experience I can lay claim, and reference my resume for a lack of note. Every time that I have expose myself as unexperienced in a topic during an interview, the interviewer has changed the question for me
Oh well, I guess I'm not employable! (I'm currently a remote web developer).
Allocate an array sized by the number of leaves. Store all leaves. Reverse all pointers. Former head points to null.
It's a dumb data structure
If you want a specific type of company, you're gonna have to play the game.
Also maybe FANG wanna-bees that are cargo culting interview practices.
Before this one I had a company ask me to write a sample iOS app with a list of data + a second page with specific validation rules for the form. I wrote that 3 weekends ago and sent it in, still haven't heard back from them, I guess they get 100's of applicants a week (it's a full remote job).
Sure, these kinds of interviews have problems, some of which might disproportionately affect older programmers. Sure, our industry (and FANG companies in particular) are rife with ageism. It's usually not overt, but I could practically write a book about the "soft" ageism of work environments and evaluation processes that disproportionately affect older workers (high overlap with those that affect workers with families or with disabilities BTW). There's definitely reason to complain.
That said, there's also some question about how valuable older workers are in newer companies. I don't particularly suffer from imposter syndrome, but I do sometimes wonder about the value of my experience. Sometimes having known other ways of doing things is an obstacle. I find myself fighting tools that have been built with a different philosophy. I find myself at odds with coworkers who have different views about things like designs, tests, and code patterns. Even if I'm "right" these minor conflicts are sometimes more of a drag than they're worth. There's value in having people be on the same page. I adapt as best I can, as well as anyone I know, but a lot of things still don't come as naturally to me as to the kids two levels "below" me who grew up with all this.
Sure, having some folks like me is good both because of the lore we carry and to prevent monoculture, but how many at 1.5x the cost of our younger colleagues? Not too many, I think. The world has always needed fewer senior developers than junior ones. The reduction in demand has always been faster than the reduction in supply, which is why so many have always "graduated" into other roles (especially management) instead of remaining individual technical contributors. That is only becoming more true as the industry grows and technology accelerates. Nobody can rest on their laurels. The onus is on the individual to make themselves more competitive as they become more senior.
Why can't I prove that I passed this screen once, then take a piece of paper to each of my FANG interviews and skip the technical part. Then maybe retake it every 5 years if you're interviewing.
Professional licensing, unionization, and or startups that directly compete with them that avoid this hiring trend entirely.
As soon as the logic puzzle came out, the job was a no-go for me.
You should not be asking questions you're not qualified to answer.
The programming tests are a variant of this. If your own programmers who do the job right fail at them, you should skip them in hiring. It means the test fails validation and you will get a number how much it fails. If you accept a test with 2 in 3 failure rate, then do not complain nobody is there to apply.
If the test is aspirational, you have to still verify how successful your people are in solving it.
Occasionally (usually at smaller companies), you’ll get some exercise that’s completely inappropriate for the time allocated, or requires knowing some unobvious trick.
One exercise I think of was the time a startup company you know, asked me to write both an IRC server and client in like an hour and a half. The interviewer and I spent a surprisingly long time googling how to open up a port in Python (something I have never had to before or since, and something I hadn’t done at all since maybe 1999), and trying debug terminal settings about why terminal was receiving things twice. None of that is related to the problem at hand, and all could have been solved with a skeleton. Needless to say, this went poorly, and I wasn’t very impressed with them either.
However, the only interview I ever refused was with HomeJoy. The interviewer said, “Why don’t you come and spend the day with us, and wow us with what you can do with our data.” Seriously. “Wow us”.
No. I’m not going to spend 8 hours on something completely ill defined, subjective, and biased towards a meaningless visualization. It’s not a serious interview, and proposal confirmed my impression of the company form the phone screen.
About half the people tested could do it in two passes. I never saw someone do it one. I told my manager his criteria was bullshit and he should stop expecting a one pass solution for a passing mark. Of course, he got all up in arms and said I was stupid for saying that. We grabbed another person on the team, and him do the question. He got a 2-pass solution, and couldn't see the 1-pass solution. So my manager started to explain it, and his explanation was going nowhere. Eventually, we got the entire team around looking at a whiteboard listening to him to try explain this 1-pass solution. Fifteen minutes and seven engineers later, he succeeded, and unironically declared, "I told you it was simple."
That is what worked for me in my last job search (1 year ago).
But a whiteboard test? It's almost insulting.
I have a CS degree from a top school and 20 years of experience. I code every day and have had a good career, full of learning and working on completely different things.
I had 6 onsite interviews, two of which didn't count (lunch and the one with the 50-person group overall leader, who I had no idea I'd be meeting with and was floored to have been given the time to do so).
While I aced the leadership principle and system design questions, I definitely struggled through two difficult CS whiteboard questions. Unfortunately, my worst interview was with the bar raiser, so I wasn't surprised when I got rejected.
As practice, I solved about 3 dozen practice questions on HackerRank/LeetCode, but in hindsight, I should have solved 300. Rust definitely plays a role... I would have done much better on these questions had I been I was fresh out of school, but then I wouldn't have done well on the leadership principles, so take your pick ;)
As much as I dislike whiteboarding, I understand the top companies' point of view. They have a handful of hour-long interviews to see if you can do the work, so it was up to me to use this time wisely and impress them. I did my best on that day, but it wasn't good enough. Let's say it wasn't a good day for me and I can do better. They don't know that--they can only judge what they've seen, so the decision is fair on their part.
I'm surprised at all the pushback from a sizable portion of software engineers on HN who feel "disrespected" by these interviews. I think about it this way--if you're a building contractor with some years of experience, shouldn't you be able to whiteboard the plumbing design of a multi-story building, the gauge of several electrical circuits that run devices with different loads, or diagram exactly where the fire/CO2 alarms are placed throughout a townhouse? You absolutely should, and if homeowners "interviewed" potential contractors like these companies interview us, there wouldn't be riff-raff doing shoddy construction work. The same way there shouldn't be shoddy civil engineers building bridges, etc. So, I believe fair is fair and even if I think I'm a "false negative," that's much better from Amazon's point of view than a "false positive."
I remember my high school track coach telling me "you have the right to train harder than your opponent," and that still resonates with me. If you really want the job, study harder and go get it. That's what I will do if I decide to interview at a top company again in the future. And I am married, with a young child, so I do understand that it is hard. But a top job should not be easy to get. Because then it would be a common job.
Recently, we hired several new developers which I lead the effort on. I had (mostly) free rein on hiring so I set out to fix things I felt were broken based on my experience as a candidate in the past. Following are my major complaints I have about the tech interview process.
* Most coding exercises I've been giving were mostly impractical BS. * Coding exercises are often used as an easy scapegoat rather than a true measure of skill. * There were several instances where I thought the coding exercise was in place solely for the interviewer to demonstrate their wit. In one case, after embarrassingly fumbling on the whiteboard for 30 mins trying to explain an advanced dynamic programming algorithm that I threw together, I watched as the interviewer smugly walked through the answer seemingly to showoff how much smarter he was. He had clearly spent hours practicing and rehearsing the answer. * Companies mostly fail at giving respectful reasons for passing on the candidate. * Companies focus too much on specific technologies and stacks vs capability to ramp up. * Good fit is underrated. I would much rather have a mostly capable developer that has a positive can-do attitude than a poisonous genius. * A college degree is an accomplishment. There are other ways to reach your goals and achieve competency. I have a masters in software engineering. I know of 1 or 2 other developers at least that only have high school degrees that were as capable as me maybe even more.
We are finished with our hiring process and I like to think it was somewhat better than my past experience. We split every interview up into 3 parts.
1) 30 minute phone intro 2) Untimed take home programming exercise because nobody develops well like this https://cdn-static.denofgeek.com/sites/denofgeek/files/2/95/... 3) 1 hour follow to programming exercise (must explain submission in detail)
Here are my takeaways from our process and how we tried to rethink the process.
* Its actually hard to properly follow up with every single candidate with reasons you are passing. Doing it in a timely and respectful manor is also hard. I wish I had done a better job at this. * The coding exercise we provided was practical and gave us everything we needed to know about the candidate programming level. * The exercise was provided via github. It had 3 steps, each of which built on top of the previous, simple, medium, harder. * After the exercise the candidate was asked to explain the exercise back to us as if we had no prior knowledge and were not techies. Then explain the technical implementation. * Write at least 1 test case for each step because our actual code is heavily tested. * We gave the candidate at least a full 24 hours to complete and could request more if needed. Its more important to get the answer right than to rush it. People work at different paces. I'm personally a slow developer because I like to take my time thinking through everything. I like to think I usually get it right at the end of the day. That's how we write software, correct is better than rushed. * We valued curiosity and honesty. We devalued nudging experience. Admit when you don't know something. It probably won't majorly count against you unless its core to our project. * Consistent clean code that is readable is very important.
If I’m given a task to solve some weird algorithmic CS problem, the first step would be to go to google and research the problem. If it’s solved, I implement that solution.
When there is no solution, I will put pen to paper and work it out myself. But that could take an unpredictable amount of time, and doesn’t help if someone is constantly watching me work or forcing me to explain what I’m thinking, because I think much faster than I can explain, and some lines of thoughts lead to dead ends, which can make people grow impatient with pointless explanations of things that will never work.
Of course, in an interview you can’t just use Google to solve everything, because interviewers will snigger and say “tHiS gUy DoEsN’t KnOw sHiT”, never mind that this is probably how 99% of developers work given the amount of questions and code reuse that is out there. It’s just not realistic.