"Doing the work" meaning having to study to relearn a thing that I'll maybe use sparingly in my work means the interview process is broken, not anyone's motivation.
I used to think this too, but as a filter I think it's having the desired effect. From the outside looking in Life at a FAANG seems competitive in nature and they are optimizing for the people willing to push themselves that far to learn something.
The added bonus is all new hires at least know the effects of space/time complexity and how to make space/time trade-offs deeply well. Given they operate at the scale they do, mistakes with those concerns are more likely to have a material impact. Requesting that you know it _now_ and now that you _used_to_ know back in the day seems reasonable.
The upside from the candidates perspective, as ridiculous as leetcode study is, is one set of study applies across multiple companies, so candidates don't have to expend much energy on trying to optimize for how to study for a particular companies interview process.
If that's the way in and you want in, that's just what you have to do. If you aren't prepared to do it, you won't be getting in. If you are prepared to do it, and you do, it seems achievable.
A. Because that's the way we've always done it.
I can't speak for SV companies, but my experience of data is that it can just as easily rationalize preconceptions as be used to inform decision-making. Somebody has to interpret that data, after all.
One of the rules is that you automatically fail the test if you bump a curb with your wheels. That means, when pulling into a spot, you can't inch forward until your front wheels come to rest on the curb. Fail!
At first glance it seems like a trivial thing to fail someone for. I know in normal driving, I use curbs like this all the time. On purpose, and with no hazard to myself or others.
But the fact is, you're told this explicitly up front. "Don't do this, or you fail." Given that you're warned about it—and know this is the one thing you cannot do—if you still contact the curb, then you've demonstrated that you don't know where the boundaries of your vehicle are. (Or maybe that you're not so good at comprehending instructions?)
It works as a simple filter.
(EDIT: I checked with the DMV's test criteria[0], and I don't see this mentioned in there. There's an automatic fail for driving over a curb, but it's not clear if simply contacting it counts. Not sure if my examiner was a sliderule, or if the rules have changed since I first got my license.)
[0, p. 24] https://www.dmv.ca.gov/portal/uploads/2020/04/dl955.pdf
I suspect that people happened to have just zoned out during this part of the class, although a friend of mine recently said he was never taught that one is suppose to stay as far right as needed to allow people to pass on the left either.
And its not just random drivers, the more esoteric parts of the law (driving on the shoulder in TX, free right turns, uturn laws, center turning lane, etc) aren't even understood by many traffic enforcement officers.
In California, for a single left turn lane, you're allowed to complete the turn into any of the lanes you choose.
The driver handbook doesn't go into detail about double turn lanes that feed into a 3-lane cross street. My own rule is that only the inner lane (leftmost) must complete the turn in the matching innermost lane. The outer lane can end their turn in the #2 or #3 lane. I tend to choose the #3 lane just to put as much space between me and the car next to me, in case they incorrectly go for the #2 lane. Unless there's an opposing right-turning car that I trust less :)
Regardless, not touching the curb, even if arbitrary, can be an indicator of competence. It demonstrates control and awareness of the vehicle.
Memorizing an algorithm is a potential indicator of many things, not all positive, but I don't think it says anything at all about competence.
> ...you can't inch forward until your front wheels come to rest on the curb. ...if you still contact the curb, then you've demonstrated that you don't know where the boundaries of your vehicle are.
This demonstrates one reason why whiteboard interviews aren't great. They don't mean what people think they mean, and people think of them in very black-and-white terms. X always implies Y, or at best they say, "Well, maybe not, but..." and then justify the exact same result with only superficially different reasoning.
In your example, the driver might have demonstrated he doesn't know where the front or rear of the wheel is exactly. But it could also be he was just nervous or driving a vehicle he isn't used to using. Maybe he had to borrow his older brother's car when mom's broke down at the last minute. Saying he doesn't know where the boundaries of his vehicle are goes against all the other evidence: he didn't strike anything with the boundaries of his car. The curb is already inside those boundaries, intentionally and by design of the test.
Do they?
In my experience this was true in the early days of white board interviews where the only people that even thought about this stuff were people deeply interested in algorithms and computation.
But in the post-"Cracking the Coding interview" era (including the transition into the full leetcode era) people seem to be able to pass these interviews without really understanding anything in the same way college students can ace calculus while have literally zero intuition about derivatives.
I don't mind whiteboard interviews, they're a fun game you can train for and the practice is interesting. But the big tragedy now is that I feel almost nobody understands algorithms anymore since everything has been reduced white board coding drills and everyone believes they have an understanding of something they don't.
As a great example of this almost nobody today knows any heuristic optimization techniques (think the old ITA software puzzles), which used to be near and dear to anyone that cared about algorithms. But since you can't test for heuristics they same as you can established algorithmic solutions nobody studies them.
Is it though? I'm a hiring manager and don't ask such questions and yet have had no problem hiring really talented engineers.
The reason I don't ask those questions is because I know that cranking up the interview pressure and asking arbitrary, revisable, common interview questions doesn't actually prove anything aside how good the candidate is at being interviewed.
And, it may be some people don't need to be any extra studying work. There are people who do programming competitions for fun, and there was prior discussion of Google saying those people did worse on the job: https://news.ycombinator.com/item?id=9324209
"If X aren't motivated enough..." usually ends up being a really horrible take for most values of X. I'm not so sure it's different for X=employees, specially when the type of interview we're talking about is more burdensome to older folks, folks with certain personality types or anxiety issues, arguably most women, etc. Why should the burden be theirs alone, while employers get a complete pass on setting up whatever arbitrary hurdles they want?
All exams can be crammed, and having crammed into plenty of gated opportunities in life before, I believe you're mistaken if you believe that it produces more knowledgeable workers as a result.
At the end of the day, it's a market like any other. If there is someone who is more willing to do X for Y reward than you are, then they will get that something instead of you. And if you find that there is a shortage of people willing to play ball, you can always work towards bringing in more people who are willing to play ball.
Agree with your last sentence. If you want something, you have to go get it. If employees aren't motivated enough to organize and close the power gap, then employers will continue to be motivated enough to push for and work towards their own goals.
But the parent was on his 30-something when he did the interview, and i bet he had a lot in his curriculum to show for, so in this case the company dont have to guess anymore.
I think it says a little bit that the HR is failing somehow. Failing to adapt to different kinds of human beings.
By the way, there are a lot of psychology into this. Sometimes the right kind of people to do some sort of task is the one that are avoiding the whiteboard tests.
In the end it will lead to an unbalanced company with people very similar and optimized for a couple of areas, but lacking in others.
They are optimizing for people in one of two groups. One is people freshly out of college who still have that stuff at the top of their mind. The other is people who have the free time/energy to bring it back to the top of their mind instead of needing a few extra minutes to go back that far in their memories. Pick your privilege, in other words.
> all new hires at least know the effects of space/time complexity and how to make space/time trade-offs deeply well
In my experience, this advantage fades within their first evaluation cycle. And what they certainly don't seem to learn is when to do these kinds of evaluations. Oh, the number of times that I saw one of my coworkers hyper-optimize some part of a system where both N and K were too tiny to matter, then just cargo-cult a crappy higher-level algorithm where such analysis really would have moved the needle.
BTW, since I know someone will launch a "sour grapes" personal attack (and get a free pass for doing so because I'm on someone's target list) if I don't address it, I passed such interviews at 52 with zero preparation and zero trouble. So no, I don't take it personally. I just recognize this approach's flaws. It's why I refused to do interviews at that company, taking a hit for that every half until I left. Some of us stick to what's right instead of rationalizing what's wrong.
But I also think they only make sense in FAANG scoped companies where all the stack is proprietary. Small companies or companies using opensource tools don't really have this rampup and doing such interviews mostly because others (FAANG) do it.
It is possible (and in fact common) to lead a full and successful career as a dev, where A.) you don't ever work for FAANG or SV, and B.) You make plenty of money, have plenty of freedom, build high profile, successful technology, have plenty of career mobility.
So, if you believe those things, "Learn these things that you learned in college and then never really touched again directly" seems like an absolute waste of time. You've seen them, and you've seen that while you were _actually building things_, they didn't really come up, or at least directly. And when the value add is "Work for big fancy company for a couple % more money per year", it doesn't really seem like that much of a value add.
I’d never make a bet like that on myself by choice, but in hindsight it would have been an excellent investment years ago. My quality of life is immensely better working for a big tech co than it was at any startup.
There are plenty of big tech companies that pay well, offer a lot of freedom, interesting tech, but are also not FAANG companies with silly interviewing practices.
IMO if a company messes around with soft skills, take homes, techno chit chat, long lunches, brutal arcane automated domain knowledge screenings, shibboleths, “day in the life”, present your solution to the group, heuristics, or some other creative way to justify their own biases, I can be fairly confident that I’ll have at least a few co-workers that really just can’t code very well.
I have not met an engineer at my current company who didn’t impress me when I dig into their code a little. There are low performers, but even they produce excellent code when they feel like it.
Nothing is more frustrating than taking a day to interview and getting maybe 30 minutes of watery technical challenge.
edit Also, to be clear, you seem very proud of your interview, your company and coworkers, and I do not mean to discredit your pride or success. I am simply pointing out that your experiences are not universal experiences and might be due to lots of other factors, totally unrelated to interview methodology (healthy attrition rates, supportive teams, constructive code review, etc).
This is regardless of outcome, including many offers and years of working at companies with broken interview processes.
I don’t think whiteboarding is a great methodology, but the other methodologies are worse.
As an interviewer, I find it stressful to give whiteboard problems and my data point usually feels fairly noisy. At startups I preferred giving a tiny take home and working with the candidate on extending it in an open ended way.
As a candidate, I refuse to do take homes (known too many take homes)
I’d imagine it’s very hard to distinguish between a good talker and a good worker. Maybe some people can do it, but this is not a skill set I’d expect everyone conducting interviews to possess.
The data shows that humans are terrible at every kind of interview assessment. This is why I appreciate an approach with mechanized layers such as “ask problem with known answer, take notes”
I think the problem with whiteboardy-type interviews is they've become closer to trivia. The fact that you grinded LeetCode and others read CTCI kind of prove that, no? As in, people go far out of their way to learn a skill _just to pass the interview_.
> I’d imagine it’s very hard to distinguish between a good talker and a good worker. Maybe some people can do it, but this is not a skill set I’d expect everyone conducting interviews to possess.
Interviewing is a skill and should be treated as such. This means possessing a set of skills any dev off the floor won't necessarily have, and that should be expected. 99% of devs don't have the skills required to conduct a whiteboard interview as an interviewer correctly either, and yet that seems to be generally accepted as okay.
> The data shows that humans are terrible at every kind of interview assessment.
Exactly, which is why, in my posts above, I pointed at things other than the interview as reasons you might be very happy with the quality of your coworkers work. It seems silly to say "The data shows that humans are terrible at every kind of interview assessment", but then also attribute anything from your job to a specific style of interview assessment, right?
You'd get further as a company by investing in training, code quality (review, analysis, etc), leadership, and healthy firing processes.
Names? I’m genuinely interested in places paying near 400k/yr but without stringent whiteboard exercises. Haven’t seen them tho...
Are you currently making 400k a year?
My personal situation doesn't seem relevant to the question. Depending on how you look at it - I am. It's just that over half of it isn't liquid right now - but will likely be next year or the year after.
Very much aware what they pay.
> I'm only going to be joining FAANG or similar if they pay that much as I have no incentive to otherwise
If this is your perspective, best of luck to you, I hope it works out. You've ignored most of what I was trying to say, which is fine. I hope you find the success you're looking for.
And yes, I meant that seriously. Every fortune 500 company is held together at some level with bandaids and bailing wire. Being able to deal with things like that might be important.
In my firm, I know we place a much higher emphasis on being able to just roll with it than technical perfection. But my firm is but a drop in the ocean compared to everyone else.
Companies also need a lot of people that are creative and "think outside the box". With this you are optimizing for conformists and people that "think inside the box", and that optimize to fit the game.
No wonder the big companies have a hard time to create things..
Western society need badly to know how to deal well with impermanence, and this are such a case were there's not much prediction that can be done.. its just like dancing expecting the rain will come.. sometimes it will, and we will gladly think it was because we danced.
The best tip for hiring is someone that you know that knows a little bit to point a couple of good people for you. Because those things are pretty hard to know, and there are very little we can do, without the experience to show for some specific characteristics we need.
I don’t know why people think this. Is there some data to back this up...? I’ve seen great engineers go onto the open market and have to go through the hoops...
Meanwhile I’ve seen plenty of terrible ones have no issues getting through side doors.
After a decade of software being a desirable job and everyone trying to get into it, we can bet good money that it's now a buyer's market rather than a seller's market.
Create a Job Seeker profile to help the website overcome the chicken-and-egg dilemma - As with any job site, it's free for job seekers and I've tried to streamline the signup as much as possible.