211–220 of 399 posts
The actual answer to avoid leetcoding is to go through the frontend engineer route in the companies which don't leetcode frontend engineers.
From my experience everyone else ask for leetcoding.
Good for you found a preferential way in but from what I've seen process generally trumps on bringing friends in.
Earlier quoted context omitted.
It also doesn't resemble "real" work with regards to gathering requirements, clarifying ambiguity, weighing up trade-offs, making sure code is clear, etc. It tends to be a rote regurgitation exercise.
LeetCode has no correlation with great software development. Great development is more about paying attention to the end users, having an eye for usability and design and great communication & the ability to execute. The current LeetCode churning explains why Google hasn't produced anything worth using since Brin & Page checked out and why so much of software today is absolute garbage - but it is what it is I suppose…
You can’t make blanket statements about software like that. Our field is way too varied.
For example, if you’re doing high frequency trading, then performance absolutely 100% matters. And knowing your data structures and algorithms backwards is part of that. On the other hand, if you’re building the website at a large company, the hard part of your job may be interfacing with the rest of the business. So networking and navigating corporate politics will be an incredibly important part of your job. And if you’re on a small team making a product for consumers, then your work will succeed or fail based on usability.
We could brainstorm dozens of other skills which might be important. Which of these skills matter the most depends entirely on the company and the role.
The problem is that "leetcode" is a definitely a thing that exists in "FAANG" interviews. The biggest stumbling block with leetcode is that you shouldn't be programming like that in real life. "make a linked list" no, just use a library like everyone else. "Implement addition in python but with string inputs", "no you can't use the built in x" All of that "clever" shit should be filtered out at PR/MR/diff review time…
Hiring should be a team level decision. Product roadmap should be an exec level decision. Google has it completely backwards. That's how you end up with hoards people gaming the hiring process by spending months on leetcode. And 3 chat apps from Google competing against each other.
I think the sort of more general point, rather than "build something great that someone at Apple notices", is that Graduate and Internship programmes are scale businesses. They get thousands of people applying and will hire atleast dozens, probably some FANG are hiring hundreds. So yes, we're all special snowflakes, but that's not what this process is for. It's about harsh rounds of easy to design problems to winnow…
Hiring managers will hire someone they already know or find themselves 9 times out of 10.
Do something that gets noticed or get to know people and network. Sending out cold resumes will have the lowest success rate of those three options.
Earlier quoted context omitted.
The comment you're replying to is saying there's 2 processes, and it matters which one you're in. System A optimizes for min(p(hire|bad_candidate)). System B optimizes for max(p(hire|good_candidate)). System A has resume screens, long lead times, and Leetcode out the wazoo. System B has a few convos, short lead times, and review of actual previous work product. Horror stories come from great candidates in system A. T…
Well, it describes what it's like to be in system B. All it says about how to get in is to build something (good? great? flashy?) and hope someone notices. This clearly does work sometimes, but it's not necessarily the best advice for everyone.
A lot of hires, even in companies like this, happen more from conversations that resumes and job postings.
As a hiring lead, there are a small handful of people I know well that I would try to create a job for immediately if they emailed me they wanted to join. As an employee, many job's I've had started something like that.
Earlier quoted context omitted.
Why would you want to become a wage slave if you've already built something that people want (thus can monetize it yourself)?
Using the word "wageslave" to describe 300k TC office workers is out of touch at best and downright offensive at worst.
Earlier quoted context omitted.
Why would you want to become a wage slave if you've already built something that people want (thus can monetize it yourself)?
Using the word "wageslave" to describe 300k TC office workers is out of touch at best and downright offensive at worst.
If you can make that much remote out in Nebraska then sure, fine.
There are people doing a lot worse. But when doing much better looks like that, what even is the point?
Earlier quoted context omitted.
can confirm, it's as simple PG says "just build something people want" it will open many doors :)
Why would you want to become a wage slave if you've already built something that people want (thus can monetize it yourself)?
The part in brackets isn't something to hand wave about. Depends a lot on how you want to spend your time, also.
Team dependent hiring is not “unique” to Apple, as the author posits. This used to be the norm before Google. It is fairly well known that Apple has a “hire different” approach that heavily values specific experience, which frustrates the Leetcode monkeys on Blind
It definitely has pros and cons though: I've worked on a handful of teams at Apple and was very lucky to have been able to work on super fun and interesting stuff on all of them, but an outsider confronted with 1000+ vague listings on jobs.apple.com is effectively playing the lottery of whether they'll get to interview for a team that's a good match for them.
Earlier quoted context omitted.
can confirm, it's as simple PG says "just build something people want" it will open many doors :)
Why would you want to become a wage slave if you've already built something that people want (thus can monetize it yourself)?
For example, if you had an idea about planting trees via drones and a big company said "come to our company and we can get this launched at scale as early as 2026". Then you think about how long it would take to do it on your own and you'd still have to convince investors and hire people and stuff.
If at the end of the day, what you care about is planting more trees quickly, you should probably join that big company. (of course there are risks too, where they cancel the project or divert its direction).
And also, not every startup found cares about achieving some grandiose mission. Some just want to get rich which is totally fine.