[HN Gopher] Getting a job at Apple without going to college or d...
___________________________________________________________________
Getting a job at Apple without going to college or doing LeetCode
Author : aheze
Score : 248 points
Date : 2023-08-17 07:33 UTC (15 hours ago)
(HTM) web link (aheze.substack.com)
(TXT) w3m dump (aheze.substack.com)
| boobalyboo wrote:
| [flagged]
| qaq wrote:
| They have a decent product portfolio for company producing
| nothing of value
| pkteison wrote:
| Going to college is still the most successful route towards
| landing an interview. My managers generally won't let me schedule
| an interview with somebody with no degree, even with personal
| recommendations. And all of my coworkers have college degrees. I
| hope people don't read stories like this and draw general
| conclusions based on rare outliers.
| monocasa wrote:
| That's pretty uncommon in the industry to wholesale only allow
| those with degrees. I've even seen people without degrees in
| defense and aerospace, probably the most hard ass niche
| concerning degrees.
| cortesoft wrote:
| Even if they have years of experience in the industry? I
| understand for people without experience, but it seems crazy to
| not hire someone who has been doing the work for 20 years just
| because they don't have a degree.
| costanzaDynasty wrote:
| I stopped reading after intern.
|
| I find LeetCode type sites good for warning up my brain in the
| morning. I start one or two every morning and it really good for
| batting practice. As a tool for hiring, Im not so sure.
|
| The same industry that will tell you how discriminatory
| standardize testing is, will also force you through a gauntlet of
| tests.
|
| Do as I say, not as I do tech.
| walthamstow wrote:
| Nice work. I also learnt by doing instead of following endless
| tutorials and videos, took me 9-12 months and got hired in Dec
| 2021.
|
| Personally, I'd consider taking the joke reference to extreme
| pornography out of the article.
| nottorp wrote:
| > Well, not at Apple. I was there from 8 to 8, to catch the
| shuttle.
|
| Hmm? More reality distortion field?
| aheze wrote:
| Work hours was more like 9-5 but I got breakfast at the
| cafeteria in the morning, and went to the gym after work
| BrianHenryIE wrote:
| Nice to see the app that highlights dietary restrictions in real-
| time in the camera view.
|
| I tried to make that in 2017, before Apple had their own OCR API.
| It was using Tesseract (via gali8/Tesseract-OCR-iOS) but the
| performance just wasn't quite there yet.
| shever73 wrote:
| The point about learning Swift and directly building an app is a
| good one. I was thinking recently that a general rule of thumb
| should be "don't learn a programming language unless you have a
| project in mind". I have learned so many languages, Swift
| included, that I just didn't have a project for. As a result, I
| either gave up or just forgot what I'd learned.
|
| I'm happy for OP that his hiring process went this way, wasn't
| this also how John Calhoun got into Apple?
| nvarsj wrote:
| I know senior engineers at Apple who didn't do a single technical
| interview. They got the role purely through networking like the
| OP did. Apple is pretty unique in this regard among big tech -
| teams have a lot of leeway in how they hire.
|
| On the flip side, I'm fairly sure the hardware / system software
| teams have rigorous hiring processes.
| cmrdporcupine wrote:
| Speaking from experience the problem with landing in at a FAANG
| without having gone through the usual Google-style interview
| process and all the academic pre-reqs and so on that everyone
| else around you went through is that, depending on your
| personality type and experience, the imposter syndrome can just
| go off the charts.
|
| I came into Google through an acquire, and one where the usual
| interview process was waived. They needed us to continue working
| on the thing we worked on, and they went through our job
| histories and talked to our mgmt and slotted us where we would
| fit and for people that didn't "fit" they were mostly given 1-2
| year contracts instead.
|
| And while I lasted there 10 years after that, it really didn't do
| me any favours. Going through the process and succeeding would
| have been far better for me. A lot of people around me at Google
| had imposter syndrome, _but I was an actual imposter_ ; didn't do
| the interview, and didn't have a CS degree. Made worse by the
| fact that I was a site (Waterloo) where the vast majority of
| people -- including all the mgmt and site leads -- went through
| the rather rigorous program at U Waterloo, and were damn proud of
| it, and so ...
|
| Just sayin', this is not a path I'd recommend. Google in
| particular is kind of run like a big university. Complete with
| their own equivalents of thesis committees (promo/calibration
| etc. etc.), an obsession with publish-or-perish, and campus
| cafeterias (and even equivalent of dorms). And their interview
| process is highly highly biased towards recent college grads who
| studied hard and recently in their algorithms and datastructures
| classes and are ready to whiteboard that up with confidence...
| It's a shared culture, with a high degree of conformity (that
| most of the people there wouldn't see/admit-to because of their
| conformance.)
|
| I'm glad to hear Apple doesn't fit that mould entirely? Myself,
| at Google... if the money hadn't been so far beyond what I could
| get elsewhere, I would have walked after 6 months to a year.
| usrbinbash wrote:
| > and you need LeetCode for backend.
|
| Interesting. I have never done a single leetcode question. 70% of
| my job is writing backend code in Golang and Python with the odd
| bit of C and shell scripting every now and then.
|
| What am I doing wrong?
| and0 wrote:
| Nothing! Quite the opposite. You've avoided the typical modern
| meat grinder approach to hiring devs. If you've been at the
| same company for 5-6 years or just slotted into a comfy niche
| then you'll have avoided it. Congrats
| smt88 wrote:
| The headline is a little misleading, although it's still an
| impressive accomplishment either way.
|
| It wasn't a job, it was an internship. OP is also planning to go
| to college.
|
| A more accurate (and less shocking) headline would be: "Getting
| an internship at Apple before going to college".
|
| It would indeed be surprising if Apple routinely hired FTEs with
| no undergraduate degree.
| [deleted]
| doomlaser wrote:
| When I was an intern, we had to pay $1200 a month for corporate
| housing, and they put 4 of us in a 2 bedroom apartment, walking
| distance from IL1 in Cupertino. They also gave the 4 of us 2
| bikes. Apple's cafeteria may not be free, but at least they're
| paying for intern housing these days.
| BossingAround wrote:
| That's horrible. If I needed more reasons to not work for
| Apple, this'd have definitely been a dealbreaker for me. Of
| course, Apple with their forced RTO and, in general, disdain
| for remote work, provides many reasons for me not to work for
| them anyways.
| doomlaser wrote:
| I wouldn't take it back. It was a singular experience in my
| career. I learned a lot. One of the cool things they did was
| have monthly talks for the interns from the executives. One
| of these was an off the cuff talk from Steve Jobs himself.
| Austin_Conlon wrote:
| What did he talk about?
| robbywashere_ wrote:
| Leetcode interviews are a zero interest rate phenomenon.
| neon_electro wrote:
| Praying you are right and it's just a lagging indicator
| georgeburdell wrote:
| 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
| ladberg wrote:
| I think "unique among big tech companies" and "used to be the
| norm" can both be true!
|
| 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.
| ecshafer wrote:
| I can't speak for Apple. But team specific hiring does have
| some big downsides. It allows some managers to brings friends /
| family in that are not really qualified. I once worked with a
| team that every single person on the team lived in the same
| town, and had some personal connection to the manager, they
| were not good. Without some standardization or minimum bar, it
| leaves teams to figure out how they hire, and that might not be
| good.
| machdiamonds wrote:
| From what I've observed, companies lean on Leetcode primarily to
| discern one of two things about a candidate:
|
| 1. They're inherently adept at problem-solving and can navigate
| these challenges with negligible practice.
|
| 2. They've got the grit to persistently grind through even the
| most monotonous tasks.
|
| Companies are on the lookout for candidates exhibiting either of
| these traits. Personally, I'm not a fan of these interview
| styles.
| suyash wrote:
| Nice to read this story - congrats to OP!
|
| More of this should be the norm not just for an 'intern' role
| where the bar is much lower but specially for senior engineers
| where experience on the relevant technologies should matter more.
| zengid wrote:
| This should probably be titled "getting an internship" at apple?
| johnnyanmac wrote:
| I'm still confused on how the author got discovered. It's very
| impressive for what I assume is a 18-21 year old who hasn't
| even gone to college yet. Made a photos IOS app, got 600 likes,
| and happened to find the eye of someone at Apple.
|
| Good eye on the manager/employee, but it almost feels like
| winning the lottery.
| aheze wrote:
| Yeah it didn't happen overnight or anything. I've been
| posting for about a year straight with WIP screenshots and
| fancy animations (https://twitter.com/aheze0) and also I've
| been doing a bunch of side projects on GitHub
| (https://github.com/aheze). Someone from the SwiftUI team
| also reached out, but I was further along with Photos so I
| went with it.
| toyg wrote:
| As long as you're young and willing to put the work in (which is
| demonstrated by building things like nice apps), the software
| industry will always have space for you. No commitments, high
| stamina, inexperience in contract negotiation, willingness to
| believe in corporate ideals, willingness to live in corporate
| accomodation... what's not to like?
|
| Microsoft and Apple were the first companies to understand this
| truth so deeply, so I'm not surprised Apple is still into these
| practices. If you are young, use them to your advantage; just -
| please go in with eyes wide open, because the industry doesn't
| really have your best interest at heart and never will.
| iguana_lawyer wrote:
| I'll save you a click: be lucky
| Invictus0 wrote:
| Apple recruiters HATE him! Get in with this 1 weird trick!
| sakex wrote:
| > I haven't been to Google, so I'm not sure, but you might
| actually need LeetCode to get a job there
|
| You do
| sacnoradhq wrote:
| Partially why I cooled the jets of SRE/SRM HR teams around
| 2016. The Googlyness was becoming less Googly classic formula
| and more political, corporate, and insane.
| jd24 wrote:
| ehh... feels like click bait. when people say "job" they
| generally refer to fte, not internship.
| lawgimenez wrote:
| I don't get it, I am not in the US. OP is an intern and what
| percentage will OP get a formal software engineering job after
| internship? It's confusing
| aheze wrote:
| A good percent, a bunch of full time people in my team used to
| be interns. But I could have started out as full time if I
| talked with my manager, I just didn't want to get stuck in a
| big company without trying other stuff first
| r0m4n0 wrote:
| I think most people here understand that this is a great story
| but not a realistic approach to how to get into big tech.
|
| The part that had me laugh a bit is:
|
| > Is it a coincidence that Apple was the only Big Tech company
| that didn't do layoffs?
|
| I will say no it's not a coincidence but it's a direct
| relationship to growth and spend, like any heartless corp. Apple
| continued to have the growth curve they wanted so they didn't
| need to. One day that will not be the case and they will fire
| people to keep it. The company is owned by shareholders
| pb7 wrote:
| Apple also uses contractors for core products way more than
| other big companies and letting those go doesn't make
| headlines.
| bsuvc wrote:
| Question for those involved in hiring:
|
| Do you have DEI metrics and objectives and if so, does that
| factor into the interview process and style?
| thenoblesunfish wrote:
| As usual I feel I have to defend leetcode, despite the problems
| you can read in other comments. I learned a lot doing those
| problems, and they gave me the chance to demonstrate my talent
| and dedication directly, despite my resume in an adjacent field.
| Leetcode may be necessary, but in my case it certainly wasn't
| sufficient, and I am ultimately very happy with having done it.
| [deleted]
| suyash wrote:
| Side question: Is it still true that if you work at Apple, you
| can't be doing side projects etc? I've heard some stories rules
| from Big tech companies specially Apple that they restrict
| heavily what can and can't be done even in your free time.
| amelius wrote:
| Are most Applers even allowed to speak in forums like this one?
| Did OP follow the rules?
| yodsanklai wrote:
| I've always found strange that we don't hear more about Apple
| in the comments here (tech, working conditions...), compared
| to other big companies. Are they so scared about Apple that
| they don't dare posting on an anonymous forum?
| aheze wrote:
| Well I just finished my internship so I'm more or less free,
| as long as I don't disclose anything confidential.
| loxias wrote:
| Based on what I know of the rules (which is out of date by
| roughly 10 years), no, OP did not follow them.
| amelius wrote:
| I don't know about others, but I feel that it must suck
| working for a company that is so closed that you can't even
| express yourself normally. And this while the company still
| reaps the benefits of society, like the results of hundreds
| of years of scientific advances, and of course open source
| software.
| [deleted]
| rcarmo wrote:
| At least two years ago, yes. You're not barred from social
| media or blogging, but you can't do it about tech or contribute
| to Open Source work without very specific clearance.
| BossingAround wrote:
| On the whole, it might be easier to grind LC than to create many
| side projects that you actually care about. This is all about
| one's internal motivation.
|
| For example, I don't really want to code in my free time. I have
| long accepted that I don't care. I don't have energy for anything
| but small-size side projects.
|
| I do, on the other hand, like solving puzzles, so LC is somewhat
| preferable to me, out of the two choices. To each their own.
| thenoblesunfish wrote:
| Agreed. And building your own greenfield project might actually
| be futher sway from most people's job than learning how to
| solve problems in a specific style..
| jhatemyjob wrote:
| Similar thing happened to me, except I was 3 years into college,
| and I turned down the offer because someone gave me the horrible
| career advice that Apple is evil and you should never work for
| FAANG.
|
| Now it's 8 years later. I am working at another FAANG, working on
| something far less interesting than I would have at Apple, have
| way less money, and am probably 5 years behind where I would have
| been if I took the job
| inconfident2021 wrote:
| I call this survivorship bias. No matter what you make, only few
| care enough. Find this few is hardest part. Because there are
| millions others doing the same damn thing.
|
| Everyone has a kick for the survivorship bias. At the end it is
| just that.
|
| How about other who made similar apps? How about all those
| aspiring game devs who actually put games, web developers who
| launched products or even some guys who made something apple
| would want?
|
| The OP managed to get lucky.
| retskrad wrote:
| Do Apple attract the best software engineers? If I were a
| talented hardware engineer, chip designer, hardware designer -
| I'd want to work at Apple because Apple attracts the best people
| in these fields. I imagine that Google, Microsoft, Meta, Amazon
| get the lion share of the best software engineers. No one has
| ever said Apple services, like the iCloud and Apple Music
| backend, or Siri, are quality piece of software engineering.
| lnsru wrote:
| Best? Probably no. But the good ones willing to have high
| salary for sure. The best work for niche companies where they
| have comparable or even better conditions. Ex colleague just
| rejected offer from Apple and picked 30 person very specialized
| company.
| thebruce87m wrote:
| The fact that you don't think about them probably tells a
| story.
| smt88 wrote:
| Siri is the worst piece of software I'm forced to interact
| with daily. iOS is also near the top.
|
| GP didn't seem to be saying they didn't think about that
| software. They were saying they didn't have a good
| reputation, which is true.
|
| Apple is actually astonishingly bad at software considering
| the amount of money they have to do it properly. Even Google
| eventually got Android to a place where it's very resilient
| and rarely buggy, but iOS has bugs for me almost daily where
| I have to reboot to fix it.
| thebruce87m wrote:
| I have no reason to doubt you, but that does not mirror my
| experience. I generally don't have to think at all about
| iOS. It just silently does everything I need, including
| backups with no fuss. The only time I have to think is
| every three years when I upgrade, but that has always gone
| seamlessly.
|
| Siri being bad is probably more to do with data collection
| / privacy. I've not looked into it, but that's my
| assumption.
| alpaca128 wrote:
| I switched to iOS not long ago because Android got more and
| more annoying, at some point I even got popups from Google
| telling me to rate the preinstalled phone app on the play
| store (the app isn't on the play store btw). Now that iOS
| has important features like widgets it's fine. You may be
| right that Android runs stable, but many parts of it are
| still just badly designed. I used Android, iOS, Windows
| Phone 8 & 10 and Blackberry 10 OS and each time going back
| to Android was a disappointment. And contrary to your
| experience I never had to reboot iOS except for installing
| updates.
|
| However some preinstalled apps on Macs are indeed terrible.
| Within a week of getting my Macbook I found ways to crash
| two apps with normal UI interactions. And it kind of
| baffles me how much the app for displaying pictures has
| trouble with opening pictures.
| sneak wrote:
| iMessage and APNS is one of the largest and most reliable
| webscale services run by anyone. Apple's cloud product design
| is crap (really, you're gonna try to sell me a $5 storage plan
| ten minutes after buying a $2000 phone?!) but iMessage and APNS
| are used by hundreds of millions of devices daily and is down
| less than S3. Credit where credit is due.
| 3cats-in-a-coat wrote:
| Apple has pockets of excellence. It used to be most of the
| company, something about how Jobs ran it, inspired people much
| overqualified to apply, and not even for very high salaries. At
| NeXT infamously a PhD (EDIT: in comp-sci, or physics?) worked
| as a janitor as he simply wanted to be around Jobs and cool
| smart people.
|
| Currently entropy is getting to Apple in many ways. iTunes and
| Apple Music didn't use to be mediocre, but are now. Siri is
| very mediocre. OS quality is declining although still pretty
| good. Hardware division is excellent, but most hardware
| divisions are.
| Apocryphon wrote:
| Hasn't iTunes been mediocre since the mid-2000s?
| atribecalledqst wrote:
| I used it for years (basically since its inception) without
| issue through High Sierra. The only really annoying thing
| they did in all that time, IMO, was remove the ability to
| easily view artwork. I still haven't figured out how to see
| artwork in larger than a thumbnail view.
|
| I only recently upgraded to Monterey and I find Apple Music
| borderline unusable in comparison. There are lots of tiny
| little bugs like how if you sort a column it no longer
| holds your position in the library -- previous versions
| would ensure that the song you had highlighted remained
| highlighted and in view. There's larger bugs like how Home
| Sharing doesn't work with wireless headphones.
|
| (I have no point of comparison with other programs like
| Foobar2k, I'm just comparing how bad Music itself has
| gotten over the years)
| Apocryphon wrote:
| iTunes has been notoriously bloated for years, though
| maybe that's predominantly for Windows users.
| clouddrover wrote:
| > _At NeXT infamously a PhD in comp-sci worked as a janitor
| as he simply wanted to be around Jobs and cool smart people._
|
| What did he get out of that in the end? Just more janitor
| work?
| Austin_Conlon wrote:
| Cleaned up some Objective-C code maybe.
| 3cats-in-a-coat wrote:
| I don't know whether when you do this, you think about
| career opportunities. You're on a "mission by God" (to
| clean, I guess, lol). You want to be there when "it
| happens". And frankly, looking back, those folks had a
| legitimate reason to be excited. History was made.
| smt88 wrote:
| Under Cook, Apple products have become bland and overpriced
| in most categories (the M_ processors are a huge exception),
| but it's also wildly successful. The stock price is 7x what
| it was when Cook took over. He's one of the most successful
| CEOs of all time.
|
| Unfortunately the only conclusion we can draw is that
| consumers don't care about:
|
| - software quality
|
| - bugs
|
| - voice assistants
|
| ...and _do_ care about:
|
| - hardware quality
|
| - integrated ecosystems
|
| - cameras
|
| - battery life
| 3cats-in-a-coat wrote:
| I don't agree customers don't care about bugs, software
| quality and voice assistants, you can hear them complaining
| in literally every forum for Apple users.
|
| An ecosystem has stickiness, so many things go wrong, that
| people strongly care about, but the overall equation still
| tips in favor of "I'll stay".
|
| The UI design went completely downhill in iOS7 with
| Forstall leaving and Ive taking over. I love Ive, but he's
| not perfect at all. Currently it's almost as if it's
| slowly, slowly, slowly recovering, but we'll see. Vision
| Pro's OS also shows some excellent design sensibilities,
| although the product as a whole is a solution in search of
| a problem.
|
| Tim Cook needs a "product guy" to help him round out the
| management team. He was/is an insanely good COO, though.
| nkotov wrote:
| I really respect Ives as a great product designer but not
| a great UI designer in my opinion. iOS 6 Skeuomorphism
| was taken to the extreme so that iOS 7 felt like a
| breathe of fresh air. Now everything just feels bland.
| 3cats-in-a-coat wrote:
| There was a lot of air in iOS 7, and the fonts were so
| thin they were waving in the open breeze.
| smt88 wrote:
| > _you can hear them complaining in literally every forum
| for Apple users_
|
| My layperson friends seem not to know iOS has any bugs at
| all. They just seem to think software in general is
| flaky.
|
| And all those complainers still keep buying these things,
| so they don't care enough to switch.
|
| > _Tim Cook needs a "product guy" to help him round out
| the management team._
|
| Why? Objectively speaking, why does he need a product
| guy? The company has been performing incredibly well as-
| is, and that's all he cares about and all he's paid to
| care about.
|
| Their brand doesn't seem to be suffering either, so
| they're doing well in the short and long terms.
| 3cats-in-a-coat wrote:
| You're describing Tim Cook as some automaton who only
| cares about performance indicators and believe me you
| don't know him well if you think that. But the fact is
| he's good at operations, and not great at products. Not
| everyone can be great at everything.
|
| Product design is, at this level, about your overall
| philosophy of product, and product portfolio, how they
| feel, how they fit together, and what is important, are
| we going pros, are we going consumers, why, how, etc.
| What do we want to see more of in the world, what is
| useful, how can we make it useful, and humane, and
| intuitive yet powerful. That's the product guy's job.
| Jobs, Ive, Forstall were product guys. Ive unfortunately
| kind of sometimes leaning into odd obsession with
| minimalism.
| nottorp wrote:
| > I don't agree customers don't care about bugs, software
| quality and voice assistants
|
| I care but once in a while I have this project I need to
| run Windows 10 for and I'm reminded the grass _is_
| greener on my side.
|
| Same for Android tbh.
|
| Edit: to summarize, Apple is still the least shitty
| option.
| eternalvoyage wrote:
| I think a combination of problem solving skill and experience
| with some specific language and/or framework is a great option
| for passing interviews. On some interviews, I only had to answer
| leetcode like problems. On others, I was grilled on the language
| or framework that the job requires. And the behavioral part
| always depends on the context.
| paxys wrote:
| Eh, you didn't get a "job" you got an internship. The hiring
| process for that is obviously more lax than for a full time
| position.
| sithlord wrote:
| its generally not, because they fully want to convert you to
| fte.
|
| sure, they have extra time to see you work before the
| conversion, but its still very expensive to host interns,
| especially ones you aren't confident in converting.
| olnluis wrote:
| Eh, well I'd like to agree, I know more than a few people that
| had harder internship interviews compared to their fulltime
| ones.
|
| Luck is definitely a factor in interviews. You can never be
| fully prepared even if you 100% match the posted job
| requirements, so you better hope your interview relates to
| stuff you are prepared for....
|
| This is, of course, just anecdote, but one of them was a good
| friend who failed their internship interview and passed a
| fulltime interview just 6 months later, both at Google... so
| there wasn't that much of a skill difference in-between.
| [deleted]
| Cthulhu_ wrote:
| Is a 3 month internship considered a job? I don't think it is;
| it's a great booster for one's career and an opportunity to get a
| fulltime / permanent position, but from the employer's point of
| view, it's a cheap trial period.
| bsuvc wrote:
| And they will almost certainly be leetcoded once they interview
| for a full time position.
| aheze wrote:
| It was paid decently, so by definition I guess? And there was
| free housing, definitely cost Apple a chunk of money.
| lazyasciiart wrote:
| As a teenager, yes, certainly it is. Other teenagers have a
| three month job as a lifeguard, or camp counselor, etc.
| dustincoates wrote:
| This is a great post, and it's good to hear from someone who is
| doing great things so early. I know HN is often down in self
| taught or bootcamp programmers, but I'm happy to see people who
| willed themselves through.
|
| On this point regarding the lack of leet code at Apple versus
| other big tech:
|
| > Is it a coincidence that Apple was the only Big Tech company
| that didn't do layoffs?
|
| Yeah, I do think it's probably a coincidence. On the whole, a
| higher focus on leet code in hiring is probably a negative thing,
| but I doubt it has such big effects as to cause layoffs.
| boppo1 wrote:
| >I do think it's probably a coincidence
|
| I dunno, I don't think the size of their cash-on-hand account
| is luck.
| dustincoates wrote:
| I was speaking about the connection between leet code in
| hiring and layoffs. Unless you mean that there's a connection
| between leet code and cash on hand is due to not using leet
| code in interviews, in which case I'd love to hear that
| theory!
| Cthulhu_ wrote:
| It depens on what they did before, because a lot of the big
| tech companies had a hiring spree in the years preceding the
| mini-crash.
| johnnyanmac wrote:
| I don't think it's a coincidence. To my knoledge, Apple also
| wasn't trying to hire like crazy over the pandemic. So it's no
| surprise that when that "hot streak" ended they weren't
| affected as strongly.
|
| And as others have said, Apple does rely much more strongly on
| contracting than the rest of the Big Tech.
| jpgvm wrote:
| I do think there is a large gap between truly self taught and
| bootcamp programmers. Most self taught programmers have bounced
| through several languages, frameworks and different attempts to
| "crack" programming. Bootcampers in my experience have a very
| narrow slice of knowledge and crucially almost no
| understanding. This is a generalisation and I'm sure there are
| counter examples but by and large this has been my experience.
|
| I actually prefer hiring and working with self taught
| programmers especially when it comes to juniors vs CS grads.
| They have less bad habits usually and a stronger appetite to
| work things out for themselves.
|
| Though this could be just my own bias having not graduated in a
| CS degree, anecdata and all that.
| mmmeff wrote:
| I hung up on my Apple interviewer last year for giving me a
| horrendous leetcode question.
|
| I asked the interviewer if it was typical work for someone
| working on the iCloud web app platform and he lied through his
| teeth, swearing it was.
|
| I've got better shit to do.
| jokethrowaway wrote:
| The barrier to get an internship is generally lower than getting
| a FT position. The author of Brew got famously asked by Google to
| reverse a binary tree and failed the interview.
|
| 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.
| eclectic29 wrote:
| This is just "one" experience, certainly not the norm. Even as an
| experienced engineer of 15 yrs I'd to solve leetcode (LC) style
| problems on the whiteboard a few yrs go. For better or worse
| (depending on whose perspective you see), LC allows companies to
| judge you based on a common framework of solving algorithmic
| problems using computer science fundamentals (data structures and
| algorithms) in a language of your choice. Obviously, the problems
| vary in difficulty and many are trick problems which is what
| makes them frustrating, but it's the unwritten sad truth of this
| industry and I believe it's here to stay _if_ you're vying for
| very high salaries.
| pocketarc wrote:
| I think it makes sense to use LC or something like it. Is there
| a better way to judge the 100 random developers who've applied
| to your position?
|
| - They may not have formal education, you can't judge on that.
|
| - They may not have active GitHub projects, you can't judge on
| that.
|
| - They may not be active on social media or have any kind of
| fame, you can't judge on that.
|
| - They may not have built anything they can show off like this
| `Find` app, you can't judge on that.
|
| So what can you judge them on? LC makes that pretty simple:
| "can they answer some standardised questions about algorithms
| and data structures, showing that they have at least some basic
| knowledge of what's going on in computers?"
|
| It's not without downsides, but I also struggle to see a better
| option that can scale to the armies of devs that Amazon,
| Google, etc, all hire.
| neon_electro wrote:
| The problem is when the companies that are absolutely not
| hiring "armies" of devs start doing the same thing.
| djcapelis wrote:
| It's simple: don't hire devs by the army.
| havnagiggle wrote:
| How is that an answer? Obviously they need bodies to turn
| the cranks. The machine must continue!
| Keyframe wrote:
| it's not as simple, but sometimes is - as anything in life.
| You might not be networked well (for whatever the reason)
| and then you have to cast a wide net or go through hiring
| agencies to pull in candidates.. it's still going to be an
| unknown group.
| robryan wrote:
| Even if you aren't, it is still going to be roughly driven
| by how many hours of recruiter/ interviewer time you want
| to allocate per hire.
| ignite wrote:
| The problem with leet code is what it really measures is how
| long you have spent on leetcode. Yes, you can solve the
| problems if you have experience, but you are not going to
| look as good as someone who had done that specific problem on
| leetcode and could just write down the optimal answer.
| dubbel wrote:
| Especially for Senior Developers I think systems design
| questions are more interesting. They usually don't just have
| one right answer and you need to discuss the advantages and
| disadvantages of the different approaches. They require
| knowledgeable interviewers of course. Then again, I'm not
| working in a huge corp, so I don't know if this scales.
| fatnoah wrote:
| > Then again, I'm not working in a huge corp, so I don't
| know if this scales.
|
| As a grizzled veteran, I LOVE System Design interviews. I
| love giving them and I love taking them. At large
| companies, System Design is definitely part of the process.
| In the world of FAANG, multiple coding rounds with a System
| Design is common for more junior developers, where a senior
| interview would have multiple System Design rounds with a
| single coding round.
|
| > They require knowledgeable interviewers of course. In my
| round of FAANG interviews, the best System Design rounds
| were at Google. One was a more typical "design service x"
| scenario, and the other was "improve and upgrade service y
| w/out any downtime". Both were related to technology there
| and were things the interviewers played major parts in
| designing. Awesome conversations all around and I'd
| probably do them again just for the fun of it.
|
| The most awkward one was at Facebook. The first design
| interview was good. It was a little uncomfortable because
| it was related to technical area I knew little about, but I
| enjoyed boiling it down to goals & principals and working
| from there and having the conversation with the senior
| engineer giving the interview.
|
| The second was given by someone far more junior who was
| both an inexperienced interviewer and who had clearly not
| ever designed a system. It was obvious that they were going
| from a script, so there was little to no discussion or
| feedback about anything not covered. As a result, I
| "succeeded" more through guessing what was on the script
| vs. having an actual system design discussion.
| bradlys wrote:
| The issue with system design is that it doesn't always have
| a perfect answer and a lot of things are arbitrary about
| it. This leaves a lot of bias with the interviewers as to
| how to interpret the answer and question. This is less the
| case with Leetcode where there is usually only one or two
| optimal ways to solve a problem and you can just argue over
| time and space complexity as a means of what "optimal" is.
|
| System design has a ton of bias in it and it's my least
| favorite type of interview because of it.
| monocasa wrote:
| I guess at this point in my career the soft side of
| system design questions are a good thing. I'm
| interviewing the team as much as they're interviewing me.
| The inability to have a soft discussion about something
| like system design that shouldn't have one right answer
| is them failing.
| kubrickslair wrote:
| Some of the highest salaries I know are in core ML at big tech
| or some of the foundational labs like Allen AI. While
| whiteboard coding interviews are often part of the process, it
| is generally pretty basic LC.
|
| The crux of the evaluation often revolves around have you built
| something amazing before? For most new grad folks it is the
| work done as part of their PhD thesis, but for non PhDs it
| often boils to amazing past work. And it's a similar process
| for more experience folks except the reliance on LC fades even
| more.
|
| If this works well for cutting edge ML why shouldn't it work
| for everything else?
| thrawa8387336 wrote:
| Allen AI pays well?! Do they ever hire vanilla engineers or
| just researchers, applied scientists?
| farseer wrote:
| Yes as a janitor, security guard or if you get lucky a
| receptionist or PA
| bennylava wrote:
| [dead]
| sakopov wrote:
| Do tech companies still do old-school interviews where you just
| sit down with the hiring manager and talk about tech? I just did
| a few interview rounds, at some relatively obscure SAAS
| companies, after a very, very long break and they were all
| leetcode-type challenges. Is this the new norm?
| conor- wrote:
| You might find this helpful
|
| https://github.com/poteto/hiring-without-whiteboards
| cebert wrote:
| The interview process for software engineers is needlessly
| complicated compared to other industries. Even if you've been
| successful working in the industry for years, you're subjected to
| Leetcode and the interview grinder. There's very little emphasis
| on the candidate, past experience and projects, and personal
| traits. We can do better.
| didibus wrote:
| > Some teams might ask you to do LeetCode, but in my case, I
| didn't even have a technical interview
|
| I'm a bit surprised and in denial about this.
|
| Maybe this was exceptional hiring practice during the COVID craze
| which has also resulted in most of the recent layoffs?
|
| I say that simply because I've personally and of everyone I know,
| have never encountered an interview that didn't involve that.
| pulisse wrote:
| It's not so surprising: The position was just an internship,
| and the hiring manager was already familiar with the work
| product of the candidate (the app that drew their attention in
| the first place).
| didibus wrote:
| Oh, internship, I missed that, because part of the article is
| behind some sign-up wall.
|
| That detail is so important, should be in the title.
|
| Internships are the exception. Good grades, good projects to
| show, sometimes connections, and a bit of luck is what you
| need. Then good performance during the internship and being
| on a team that still has head count to make an offer at the
| end of it.
|
| But internships tend to be ageist. If you're too old, or are
| past that fresh out of school phase, you probably won't
| qualify for them.
| Apocryphon wrote:
| Apple is an incredibly heterogeneous company and conditions
| from interview practices to tech stacks vary incredibly from
| team to team.
| didibus wrote:
| Yes, but I speak from experience at Google, Amazon, Microsoft
| and Facebook. Where I have personally worked for, applied
| too, or know people who did both.
|
| To be fair, and somewhat surprisingly, I never have
| personally or know anyone that applied at Apple. So I do have
| a gap in first hand experience withe regards to Apple
| specifically.
|
| Still, I would be very surprised if it was so different.
|
| And as another commenter responded to me, it wasn't, the
| position was for an internship, so it makes sense now.
| foobiekr wrote:
| Pretty much anyone who interviewed before the 2012 never did
| stupid code tricks like leetcode interviews. Instead, we asked
| how things actually worked.
| inparen wrote:
| This is n = 1. What is usual hiring process followed at apple ?
|
| If everyone start practicing leetcode and similar questions used
| in interview, then whole filtering talent process seems moot.
| rvz wrote:
| Looks like the majority of HNers commenting here are showing
| clear signs of envy or resentment over this person's achievement.
| That's all I need to know about HN right here.
|
| So you know what?
|
| Massive congratulations to this student being so good that they
| don't need to take a LeetCode interview. Leetcode is not the only
| way.
|
| Perhaps the ones that do have to take the coding interview
| probably haven't built something interesting themselves...
|
| Either way, Leetcode, Hackerrank tests for hiring etc are all
| garbage. Great that this student's work speaks for itself enough
| to get an internship at Apple.
|
| Well done for them!
| SilverBirch wrote:
| 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 the field.
|
| This _totally_ changes when you 're a specific candidate with
| skills Apple values. What this guy experienced wasn't an
| interview process. They had already decided to hire him before
| what he described as the interview process. They already know
| he's good, he experienced the talent acquisition process. The bit
| that happens when the company has already decided to hire you and
| is now doing everything it can to sell you on the job.
|
| If someone outside of recruiting contacts you about a job at a
| company, you will not experience a normal interview process,
| because they're already quite likely to want to hire you.
| yieldcrv wrote:
| This is a weird take because the whole point of the last decade
| of leetcode was that people with special skills or that built
| something great can't even get hired. which was dumb. but
| reinforced the supposed uniformity of that process.
|
| I'm glad people aren't just continuing the practice simply
| because they experienced the practice.
| didibus wrote:
| To be honest, building something on your own time is very
| different, in that, it's much easier.
|
| You start from scratch, you can pick something you're
| interested in building and maybe also feel you can succeed
| at. You make up your own requirements, as you see please, so
| things aren't ambiguous or changing in requirements
| constantly.
|
| There's no prior legacy constraints, there's no time
| constraints, it doesn't require finding ways to deliver
| faster by leveraging other developers.
|
| You get to spend as much time as you need, go watch
| tutorials, take a hiatus, come back to it when refreshed,
| fail multiple times and try again, etc.
|
| You can choose the programming language, framework, library
| ecosystem, that you're more familiar with and comfortable
| with.
|
| And so on.
|
| So having someone that can show some cool personal projects
| I've found isn't always a great way to know if they'll be
| good in a work environment and on a team.
| nitely wrote:
| How can you test all of that? through leetcode kinda
| questions you surely cannot. Maybe behavioral questions are
| close, but you would do those in both types of hiring
| processes, no?
| didibus wrote:
| Leetcode questions have their own set of issues. Just
| wanted to say, not sure a portfolio of personal projects
| is all that better either.
|
| A candidate that has a good portfolio and can pass an
| algorithm and design interview, and described prior work
| experience on projects that seemed involved is your best
| bet of course.
| sdfghswe wrote:
| > This is a weird take because the whole point of the last
| decade of leetcode was that people with special skills or
| that built something great can't even get hired.
|
| No, it looks like you're missing the point. Leetcode is not
| for people with special skills. It's for people with NO
| SKILLS other than "can code". Well if the only thing you can
| do is write code, you better be really good at writing code.
| Eddygandr wrote:
| Didn't the guy who made Homebrew fail his interview at
| Google because he couldn't invert a binary tree? That's a
| guy who has built a popular product in the wild and can
| clearly code but failed because of the leetcode barrier at
| all IC levels.
| sdfghswe wrote:
| You sound like you're trying to make a point. Make a
| point.
| 121789 wrote:
| I agree. Every hiring process will have false negatives.
| Pointing out every one doesn't invalidate the
| effectiveness of the process
| thejazzman wrote:
| Effective for whom? And at doing what?
|
| SV is full of mediocre engineers; so it fails at
| guaranteeing you got yourself a star. And I don't think
| anyone needs more anecdotes to think great candidates
| lose for arbitrary/subjective/misunderstanding/random
| reasons
|
| --
|
| I'm 15y into my career with a degree from CMU; I am
| treated like royalty everywhere I work ... and yet I
| still absolutely dread, hate and repeatedly have bad
| experiences interviewing for jobs.
|
| I've considered switching careers numerous times because
| of the emotional distress I go through just interviewing.
| And that's before we even talk about the insane amount of
| time every prospective employer demands of you!
| MichaelZuo wrote:
| Who's forcing you to stay in SV?
|
| If it's making you so stressed out as you claim, then the
| obvious step, to me, would be a change of scenery.
| HeyLaughingBoy wrote:
| > insane amount of time every prospective employer
| demands of you
|
| I have worked an average of 40-hour/week jobs for my
| entire 30-year career. What's this "demand" nonsense?
| brookside wrote:
| I believe parent is talking about time demands of the
| interview process, not the job.
| HeyLaughingBoy wrote:
| ah!
| devoutsalsa wrote:
| If you can't invert a binary tree, how can I trust you to
| change my website's favicon?!
| seanmcdirmid wrote:
| You would be surprised how hard it would be to invert a
| binary tree, or really just what the question is asking
| for, if you didn't at least study up on the concept in
| the last decade. It is conventional enough to sound
| mundane, but how often are we inverting binary trees in
| practice?
| monocasa wrote:
| It came out that by inverting a binary tree just meant
| swapping the left and right children of all nodes of the
| tree. It's pretty much 'can you iterate through a tree?'
| which comes up a surprising amount.
| seanmcdirmid wrote:
| Sure, but try coming up with that without even
| remembering what invert meant (it isn't a word that is
| commonly used in practice outside of CS education and
| l00tcode). Most of the problem in l00tcode question is
| just figuring out what is being asked for, not in doing
| the ask. That's why studying and understanding lots of
| l00tcode problems as prep is very effective (even if you
| haven't seen the problem, the problem is probably
| adjacent and you can understand it more quickly during
| the interview).
| monocasa wrote:
| 'Invert' is a pretty common word.
| seanmcdirmid wrote:
| Yes, but the common slang it is used for isn't the
| meaning we are using for l00tcode questions.
| monocasa wrote:
| There isn't one meaning in leetcode questions; it could
| mean a bunch of things. That's why you ask questions in
| an interview.
| hotnfresh wrote:
| The common meaning isn't _slang_. The (multiple!) math
| /CS senses of the word are jargon. Which is fine--nothing
| wrong with jargon--but their existence doesn't make the
| ordinary sense slang.
| ant6n wrote:
| Yes but is it Referring to the additive or multiplicative
| inverse?
|
| Or maybe it's making the tree upside down, so all leaves
| become roots, and the root becomes a leaf. But when we do
| that, do we just invert all the edges or transform the
| whole tree?
|
| Maybe it's referring to changing a red-black tree into a
| green-white tree? Or turning a splay tree into a merge
| tree?
| monocasa wrote:
| It can mean a lot of things, so you ask questions.
|
| Howell (the homebrew 'google didn't hire me because of
| inverting a binary tree' guy) confirmed that they meant
| swapping right and left children of all nodes.
| slt2021 wrote:
| you can always ask interviewer - define invert what does
| it mean - and interviewer in 100% cases will explain and
| even provide test cases.
|
| in fact any candidate that doesnt ask clarifying
| questions and goes deep into coding right away - has a
| chance of going into wrong direction and is flagged as
| red flag.
|
| As an interviewer I always lookout for candidates that
| dont ask questions, dont start with test cases, assume in
| their mind what is their understanding of ideal solution
| - and start coding. These are very inexperienced people
| who do that
| ahoka wrote:
| But inverting a binary tree is trivial. It's not like
| finding the shortest path in a graph, or something
| similar that requires recalling an algorithm on the spot.
| Go and look at the actual problem if you don't believe
| me.
| nonameiguess wrote:
| It's amusing the answers so far are mostly all "well this
| is an easy question and he should have gotten it." I
| actually agree with that, but even so, he got rejected by
| Google but did get a job at Apple, which is what this
| article is about, and that seems like a far more relevant
| fact to me.
| TrevorAustin wrote:
| To be fair, Homebrew is great product design, but
| actually pretty janky software engineering. Anyone who's
| had it wreck their PATH a couple of times isn't going to
| be an automatic yes vote on a technical screen.
| hotnfresh wrote:
| As if average FAANG quality in customer-facing software
| is better.
|
| If that's the hang-up on hiring him, they need to get the
| log out of their own eyes first, because shifting to the
| quality level of Homebrew would be a big _improvement_
| for a whole lot of their software.
| dehrmann wrote:
| Long ago, I switched to MacPorts because its path and
| directory story is better, and I didn't find myself
| having to run chown to fix things.
| thereisnojesus wrote:
| Yes, we are aware companies hire privileged losers
| instead of skilled employees
| raydev wrote:
| I'm pretty sure I have some kind of skill having been in
| the industry for more than a decade, and jumped to higher
| paying jobs several times.
|
| Even at the staff/senior staff/principal levels you will
| still have to face the same LC gauntlet they give to new
| grads.
| angarg12 wrote:
| I'm a Machine Learning Engineer with 5+ years of experience
| at FAANG. I have designed and built real time ML systems
| that support millions of QPS with < 10 ms latency. I also
| have a variety of other skills.
|
| And yet I can't escape leetcode interviews. In fact I
| recently sent a spree of CVs and got automated rejection
| emails for most of them.
|
| I don't buy your take.
| thereisnojesus wrote:
| This is privilege if you think 3 CVs is a lot. I applied
| for 100 yesterday.
| HeyLaughingBoy wrote:
| At 100 resumes/day it's hard to believe that you're
| optimizing them for the position or for that matter,
| doing anything other than shotgunning.
|
| You're far more likely to get 100 rejections doing this
| than if you research a handful of the positions and send
| targeted resumes to those.
| wonderwonder wrote:
| OP said spree, not 3
| [deleted]
| FirmwareBurner wrote:
| I feel like 100/day is swinging the pendulum in the
| opposite direction. I apply like 3-5/week and I feel like
| that's a lot.
|
| Granted I don't live in a tech hub so my options are
| limited but 100/day feels like you're just spamming
| aimlessly and wasting your energy on quantity instead of
| quality.
| curiousllama wrote:
| 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. This
| article is describing how to get into system B.
| jkaptur wrote:
| 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.
| zem wrote:
| there's an old joke about a company owner who would
| routinely throw half of every stack of resumes he
| received straight into the bin, because "who wants
| unlucky people working here?". i think a large part of
| why it's funny is because it really does take a
| considerable amount of luck to get hired at all, and
| especially through the system B process.
| curiousllama wrote:
| Yea fair point, totally agree. Big selection bias.
|
| Still, I think a lot of folks could benefit from thinking
| through "how do I get into system B?" - because those
| skills are tremendously helpful in System A, too.
| ska wrote:
| Build good things and develop a good network of people
| who know what you can do.
|
| 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.
| jkaptur wrote:
| Yep. Also learn like 5 data structures and 7 algorithms
| in case the relevant manager can't just unilaterally hire
| you.
| intelVISA wrote:
| can confirm, it's as simple PG says "just build something
| people want"
|
| it will open many doors :)
| zerr wrote:
| Why would you want to become a wage slave if you've already
| built something that people want (thus can monetize it
| yourself)?
| kaashif wrote:
| Using the word "wageslave" to describe 300k TC office
| workers is out of touch at best and downright offensive at
| worst.
| ericsoderstrom wrote:
| I do think it's still true in my experience that someone
| with the the capabilities to build useful things on their
| own tend to not stay very long at these giant companies,
| unless for specific visa reasons
| johnnyanmac wrote:
| depends entirely on the person. The startup life isn't
| for everyone, especially people with families that value
| stability and life balance over the idea of millions.
| deckard1 wrote:
| ah, yes. The American Dream of living in a 50 year old
| shitbox fixer that costs $2M in the suburbs of Cupertino.
|
| 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?
| gretch wrote:
| > But when doing much better looks like that, what even
| is the point?
|
| Cupertino is an hour away Santa Cruz beaches. 3 hours
| away from skiing (or boating) at lake tahoe. 1 hour away
| from one of the best NBA teams (GSW). 30 minutes away
| from Stanford. 1 hour away from Berkeley. Some of the
| best average temperatures in the country.
|
| Maybe they live in a "shitbox fixer", maybe they don't.
|
| You might consider that people like and care about those
| other properties though.
| pb7 wrote:
| Living in Nebraska when you have the means to live in
| civilization is a punishment. Why would someone _choose_
| to live in a place where the nearest restaurant is a
| Denny's 45 mins away?
| opan wrote:
| Quiet and peaceful, cleaner air, you can play loud music
| and stomp around without upsetting neighbors, and for
| many people most of their time is spent on a computer
| anyway.
| slt2021 wrote:
| do you seriously think that tenderloin, Oakland,
| richmond, hunter's point, bay view is civilization?
| slt2021 wrote:
| people choose to live in bay area not because its housing
| situation, but despite of it.
|
| mainly because cutting edge R&D type technology has been
| developed in the area and alternatives to SV have not
| developed yet. its not even pay - I would say bay area
| pay is bad, because of cost of living & taxation.
|
| But opportunities for growth are unmatched in bay area
| ryandrake wrote:
| The point is you can't adequately judge whether a job
| counts as "wageslave" just from the salary. A $300K job
| where houses cost $2M is like a $30K job where houses
| cost $200K.
| kaashif wrote:
| This is incorrect. If my income and expenses both
| increase by 10x, my savings increase by 10x. After just a
| few years of saving, I have the option of moving
| somewhere cheaper and living like a king.
|
| It's not like your savings and investments are adjusted
| for the cost of living when you move.
|
| In the extreme case, you can earn as much as possible and
| accumulate enough to live on indefinitely in a cheap
| country. This is obviously better than just earning a low
| salary in the cheap country for the same amount of time.
| slt2021 wrote:
| you are more than right, it is actually objectively
| worse.
|
| because $300K will demand much much more than 30k job.
|
| 300k job leads to stress, anxiety, performance
| calibrations, mental breakdowns, overwork, competition,
| lack of job security etc.
|
| 30k job could be very relaxed, could be part-time gig
| where you work few hours in a week.
|
| so work-life balance is really tilted worse for higher
| paying jobs
| kaashif wrote:
| I mean, not necessarily. A 300k job at a tech company may
| be less stressful than e.g. a 150k job at a non tech
| company with a toxic culture.
|
| To be clear, it can be true, there are lots of stressful
| high paying jobs, my point is that it's not necessarily
| true.
|
| I know low paid people with stressful jobs and highly
| paid people with less stress.
| Clubber wrote:
| >downright offensive at worst
|
| People are so easily offended these days.
|
| Having said that, if you work for a company and you get
| fired and blacklisted, you still don't eat. If you work
| for a wage, you _HAVE_ to work for somebody or you
| starve. If you work for somebody, that somebody has a lot
| of sway over how your life looks. Better be good at
| kissin ' ass.
|
| Also, if you don't think the US healthcare industry will
| take every penny of your life's earnings upon your
| eventual and inevitable deterioration, you're fooling
| yourself.
|
| FWIW, I'm a wage slave too.
| Eisenstein wrote:
| > If you work for a wage, you HAVE to work for somebody
| or you starve.
|
| You really don't. There is no way you can starve in the
| USA unless you do it on purpose.
| jononor wrote:
| 5 million households in the USA constantly have poor food
| security. About double that had intermittently poor food
| security. I do not think they are doing it on purpose.
| Eisenstein wrote:
| And if they went to any hospital starving they would get
| fed.
|
| Please note the literal use of the word 'starve'.
| pb7 wrote:
| You're a wage slave when you work for yourself too,
| probably even more so. You can't even completely take a
| week or two off in most cases. Your work eats your entire
| life.
| Clubber wrote:
| >You're a wage slave when you work for yourself too,
| probably even more so.
|
| It certainly can be like that especially early on.
| Hopefully you would grow enough to hire good people to
| manage the business. If you work for somebody though,
| that will never happen.
| pb7 wrote:
| >It certainly can be like that especially early on.
|
| All the slavery with none of the wage.
|
| >If you work for somebody though, that will never happen.
|
| The alternative to starting a business that you'll hope
| will be self-sustaining and still earn you a respectable
| living is to work for the highest bidder, invest, and
| become financially independent. Odds of the latter are
| much higher for the average software engineer than the
| former.
| yunwal wrote:
| There's also quite a few jobs where programmers can
| automate away a good portion of their work
| distant_hat wrote:
| So the goal is to go from wageslave to wageslave owner?
| geodel wrote:
| Huh, its like calling couch potato is offensive to
| someone is offensive who watch TV and sit in couch all
| day because their TV is 77" OLED, couch is full grain
| leather and beer artisanal.
|
| If someone with 300K+ TC gets offended by this term,
| playing world's smallest violin for those snowflakes
| would be most appropriate.
| namdnay wrote:
| Offensive as in "offensive to real wage slaves"
| coeneedell wrote:
| It's more about the people making 30k a year putting up
| fencing and barely scraping by watching those 300k a year
| SWEs complain about how they're wage slaves.
| tylerfontaine wrote:
| HN moment.
|
| Software jobs, especially at the kinds of FAANG companies
| largely being discussed here, are quite a stretch for the
| term "wageslave."
|
| Entrepreneurship isn't for everyone, even those who've
| tried it before.
| zerr wrote:
| Golden handcuffs if you will :)
| ska wrote:
| > 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.
| gretch wrote:
| If you care about achieving a particular mission, you could
| view joining a large funded organization as an opportunity
| to achieve that mission with higher likelihood or speed.
|
| 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.
| zerr wrote:
| Decoupling an income from the time spend on work.
| afavour wrote:
| Your hilarious perspective on highly paid FAANG jobs aside:
| because now that you've made it and demonstrated there is a
| target market it's trivial for the billion dollar company
| to make their own version and eat your breakfast. If
| they're offering you the chance to join them as they do so
| it's very often in your interest to do it.
| bdcravens wrote:
| Building is the easy part.
| TaylorAlexander wrote:
| Running your own business kinda sucks. I did it and failed
| and it was extremely painful. Now I'm building my dream
| product working for a philanthropist who pays my wages. SO
| MUCH easier than doing it myself.
| nlunbeck wrote:
| Something I've noticed over the past 5 or so years is a
| "hobby project" is increasingly becoming the standard. Your
| GitHub portfolio is almost as important as your resume itself
| in many cases. It starts the conversation and grabs attention
| with potential employers, but doesn't act in lieu of a
| technical evaluation. Almost every competitive applicant at
| the intern level has some tool or webapp that they've built
| out extensively.
| sjf wrote:
| Do you actually have any evidence for this? While having
| _zero_ personal projects is probably a red flag, in my last
| job search I saw almost _no_ clicks on links to projects.
| From personal experience, most hiring managers are so busy
| they barely even read the resume. They are definitely not
| going to comb through someone 's github submissions.
| returningfory2 wrote:
| This has been my experience on the hiring side too.
| Nowadays almost all resumes have a link to GitHub, but
| 80%+ of the time the accounts have been dead for
| months/years. My favorite was a candidate whose GitHub
| was totally empty - they had just created an account,
| done nothing on it, and still included it in their
| resume!!
| PartiallyTyped wrote:
| I can confirm that AWS has done this as well, I know of at
| least 1 person who has been hired in this manner, and it was
| because they were excellent OSS contributors.
| flashgordon wrote:
| Most of this is correct - But Faangs have also been having
| their managers (eg EMs and PMs) do reach outs to make it look
| authentic - only to forward you to a recruiter and a standard 6
| hour interview round (I know because I am not special and have
| fallen and almost fallen for this trap dozens of times)
| ChipSkylark wrote:
| Always nice when the startup CEO emails you directly via CRM
| automation about your unique potential at the company and
| when you agree to chat he hands you off to the "senior
| technical recruiter". Always makes me feel extra special :)
| jackson1442 wrote:
| As a data point on the scale of internships, Amazon hired
| approximately 15,000 interns last summer (not including winter
| interns). While I don't have a number for how many get full
| time offers, a large portion do since the internship serves as
| on-the-job training.
| CoastalCoder wrote:
| There a wonderful Corecursive podcast [0] that touches on
| unexpected ways to work with Apple.
|
| [0] https://corecursive.com/shipping-graphing-calculator/
| ajkjk wrote:
| Got a summary for those of us who can't listen right now?
| CoastalCoder wrote:
| Guy long-term sneaks into Apple buildings to get his
| passion project shipped with Apple's first PowerPC Macs.
|
| But my summary really doesn't do the interview justice.
| Highly worth listening to.
| KerrAvon wrote:
| Note that the Graphing Calculator story is not something
| that could work after approximately the turn of the
| century. Security tightened up considerably sometime
| around then.
| Retric wrote:
| Possibly, but a great deal of security only works because
| people never really tests it.
|
| There's a few cases of people walking into 'secure' data
| centers plugging in their laptops only to realize they're
| at the wrong company. People while swipe badges, act
| befuddled because it didn't work, and then get let into
| the building. Or get out of an elevator with a bunch of
| people and just walk in as part of a crowd which holds
| the doors for each other.
| ryandrake wrote:
| The "badging" culture at Apple is pretty extreme. It is
| routine and totally expected for a low-level worker bee
| to watch and call out a VP behind him who fails to badge
| through any external or internally locked door. One of
| the highlights of my time there was once having to remind
| Craig Federighi that he forgot to badge into a secured
| area.
| r00fus wrote:
| Also related to the "secret projects" culture there.
| Being high on the hierarchy doesn't matter to secret
| project roster. Security is that key to how Apple
| operates.
| gumby wrote:
| You can just read his story (which has been on HN several
| times): http://www.pacifict.com/Story/
| azinman2 wrote:
| That was a _very_ different time.
| asielen wrote:
| This can also apply to networking and having a good narrative
| about your experience.
|
| 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.
| kmano8 wrote:
| This is my experience. Path in the door for every job I've
| had since I finished undergrad in the mid-aughts: - 1st job
| .. I answered a craigslist ad. - 2nd .. HN who's hiring post.
| - 3rd .. reached out to an engineer on the team on linkedin.
| - 4th .. referral from ex-coworker's partner. - 5th ..
| browsed the website of the VC firm that's funded a few of my
| previous companies, and I reached out to the CEO on linkedin.
| vpastore wrote:
| [dead]
| decherneyge wrote:
| Heck yeah! That's an awesome experience for you! Glad to see you
| went after something you wanted! I had a similar experience when
| I tumbled my resume and it landed me an internship at Tumblr.
| Thank you for sharing it and reminding us that there is always
| more than one path to success in the CS field.
| KaiserPro wrote:
| 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.
|
| All of this "clever shit" is exceptionally bad programming. We
| don't live in the 80s anymore. we don't need to make our own sort
| algorithms. just. use. a. Library.
| hardware2win wrote:
| You realize that somebody wrote that lib and maybe they want
| ppl with skills to build stuff instead of just reusing?
|
| People always make weird arguments about lc, but whats the
| point?
|
| Just put effort into it or not, no excuses needed
| PartiallyTyped wrote:
| My team is doing things for which libraries do not exist,
| things that are very much leetcode-esque, deeply into
| theoretical CS, lots of applied science. Some other teams
| here are doing data plumbing others do UI stuff.
|
| Our team can get to be very picky about people because ...
| well, we need to be.
| TillE wrote:
| If you can't explain in detail how a linked list works, that's
| an enormous red flag that you've probably never studied data
| structures. It's a FizzBuzz level question.
|
| I'm sure some companies have lousy interview practices, but
| algorithms and data structures are super important if you want
| to hire someone who's actually competent, who can think for
| themselves.
| hotnfresh wrote:
| What's funny is that in most positions the hard work has
| nothing to do with any of that. It's communication, empathy,
| navigating people-problems and organizational dysfunction, and
| working with/around awful systems that you can't change, while
| limiting their blast-radius to protect the business (and your
| own sanity).
|
| You can always just google how to invert a binary tree or
| whatever and get a solid answer in no time. Which means it's
| easy shit. Unless you're one of a few devs doing PhD level work
| in the industry, that CS-heavy "mathy" stuff's not the hardest
| thing you're dealing with, and being good at that indicates
| _almost nothing_ about your ability to deal with the hard
| problems you _will_ encounter on the job.
|
| (or else you're greenfielding at a startup and are doing
| everything on easy-mode anyway, aside from problems you create
| for yourself on purpose or by accident)
| remich wrote:
| In fairness, the ratio of "just write code" to everything you
| listed above changes quite drastically as your seniority
| increases.
|
| To be sure, there will always be some senior/staff/principal
| engineers who sit in a room by themselves and code all day
| without talking to anyone, but, typically, the more senior
| you get in an organization the more your job consists of
| things other than writing code. When you're a junior or a
| mid, however, writing code makes up the vast majority of your
| day.
| hotnfresh wrote:
| I was thinking about "just writing code" with the
| communication and empathy parts, especially, in fact,
| though you're right that they also apply (differently,
| though I'm not sure if it's _more_ ) to more-senior work.
| nh23423fefe wrote:
| Sure, you can pretend developers don't read and write code.
| Just like people who complain about leetcode pretend the
| questions are hard and that performance is uncorrelated
| somehow.
| hotnfresh wrote:
| > Sure, you can pretend developers don't read and write
| code.
|
| Weird. Why would someone pretend that?
| varjag wrote:
| Communication, empathy and navigating people is easy: there's
| a deluge of people capable of doing that. Writing code is
| hard. Not many people can code at all; even fewer are any
| good at it. This is why you can easily be unemployed after BA
| in Communications but have little problem getting a job after
| high school if you can code.
| remich wrote:
| In my experience, it's relatively rare among software
| engineers. So, even if it's over-represented in the general
| population (which I'm skeptical of), having actual skill at
| that makes you leaps and bounds more effective than others,
| once you get up to senior+ level.
| fnands wrote:
| My understanding is that they use it to filter candidates a
| bit. FAANG positions get loads of applicants, so they have to
| find efficient ways of thinning the herd a bit. The correlation
| between people who are willing to grind leetcode and who turn
| out to be good engineers is high enough that it's worth it for
| them to keep as a tool to sort the massive pile of applicants
| they get.
|
| Of course, hiring someone purely on how good they are at
| leetcode would be... dumb.
| dkdbejwi383 wrote:
| > The correlation between people who are willing to grind
| leetcode and who turn out to be good engineers is high enough
| that it's worth it for them to keep as a tool to sort the
| massive pile of applicants they get.
|
| One "subtlety" this misses is that leetcode-style trivia
| tests only work for those who are willing _and able_ to grind
| leetcode etc.
|
| There are many who have the aptitude and experience but have
| e.g. children, or interests outside of programming which
| means they do not have the required free time to spend
| rehearsing for this kind of interview.
| Aurornis wrote:
| > One "subtlety" this misses is that leetcode-style trivia
| tests only work for those who are willing _and able_ to
| grind leetcode etc.
|
| As a parent of young children, I think this is greatly
| exaggerated.
|
| If you're a skilled developer with several years of
| experience then you shouldn't have "grind" leetcode for 10s
| of hours per week for months on end. It's trivial enough to
| do a few problems per week on a break or during some down
| time.
|
| I think too many people refuse to even start because the
| difficulty has been exaggerated to the extreme. When I was
| mentoring college grads some of them would grind leetcode
| for months and months and even delay their interviews, then
| walk away dumbfounded when their interviewers didn't ask
| them anything resembling a Leetcode Hard. Many of them got
| questions that were basically Leetcode Easy questions.
|
| They had all been convinced by the internet that they
| needed to grind Leetcode until they were miserable, but
| it's not really true unless maybe you're starting with
| almost zero knowledge of algorithms and data structures.
| fnands wrote:
| The cynical part of thinks that that might be a feature,
| not a bug.
| comprev wrote:
| It is a feature.
|
| FAANG want dedicated engineers who don't have the
| distraction of family and/or sick relatives.
|
| They don't want people who need to finish _promptly_ each
| day to put their kids to bed.
|
| They want their pound of flesh in exchange for a high
| salary and ability to add "Worked at FAANG" on their CV.
|
| If you have the time and dedication to grind leetcode for
| months the you've passed their requirement.
| Aurornis wrote:
| > FAANG want dedicated engineers who don't have the
| distraction of family and/or sick relatives.
|
| This is hilariously out of touch.
|
| Most of the FAANG people I know have kids.
|
| Nearly all of their managers have families.
|
| The one person I know who has _two_ special needs kids
| specifically sought out a FAANG job for the stability,
| compensation, and work life balance it afforded.
| remich wrote:
| Yeah, this sounds more like a late-00s startup mentality
| than anything else. Maybe the FAANGs were this once upon
| a time, but nowadays they are firmly in "stable grownup
| job" territory.
| slt2021 wrote:
| this is a feature, not a bug. Companies absolutely want
| people with minimum outside job responsiblities, so that
| they can work them during the day, and pagerduty them
| during the night when stuff breaks.
|
| or overwork with boat load of feature requests and bug
| fixes and Ops workload - this is the reason why faang's
| offices are so fancy, have free food, laundry, massage, and
| bunch of other stuff.
|
| These fancy offices are for engineers to pull all nighters,
| not for tiktokers to show off in social media.
|
| if you are 9-5 with 5 kids - you are not gonna make it in
| venture capital funded Silicon Valley world. 9-5 is for
| regular "enterprise" engineers at Initech or Dunder Mifflin
| Paper Company in Lubbock TX
| stcroixx wrote:
| I did it for 10 years with 4 kids. Multiple startups.
| Very few work off hours and none did in my experience.
| HWR_14 wrote:
| Did you found a startup with 4 kids, or were you an early
| hire, or just one of several worker bees?
|
| Serious question, not rhetorical, in case it doesn't come
| across.
| josephg wrote:
| > One "subtlety" this misses is that leetcode-style trivia
| tests only work for those who are willing _and able_ to
| grind leetcode etc.
|
| This is simply not true. The smartest people I graduated my
| CS program with can pass leetcode style interviews without
| practicing. They live and breathe this stuff.
|
| Are these problems overemphasised? Absolutely. But they
| don't expect you to grind. They exist so they can find my
| smart classmates to make sure they get offered a job.
| a_humean wrote:
| The only justification is that its a filtering mechanism. You
| likely won't use any of this, but its a proxy to certain
| characteristics you might find desirable in a candidate - some
| baseline intelligence and motivation.
|
| That you have the capacity to sit down and rote memorise a
| bunch of different techniques and practice completing a these
| kinds of tests indicates the likeliness of success in absence
| of other hard evidence of likely future performance. In a way
| it is the same function as university entrance exams.
|
| That these companies continue to do this for experienced
| candidates and not just recent graduates without a track record
| in employment is more perplexing.
| shagie wrote:
| > That these companies continue to do this for experienced
| candidates and not just recent graduates without a track
| record in employment is more perplexing.
|
| This assumes that they don't get similar number of people
| applying to the experienced positions who are lacking skills.
|
| For example, I know some Java devs who could put down 5+
| years of professional experience but are still _very_ junior
| when it comes to problem solving skills. They are capable of
| following precise instructions and there 's enough work of
| that nature to do - but an open ended "there's a bug that has
| a null pointer exception when running in test but not dev or
| production" is something that they're not capable of doing.
|
| If they were to apply to a position that said senior java
| developer based on their years of experience and there was no
| code test as part if it, they might be able to talk their way
| through parts of it and there is a risk that they could get
| hired.
|
| For a senior java developer position at Google, would it be
| surprising if they got 500 applicants with 5+ years of
| experience?
|
| How would you meaningfully filter that down to a set of
| candidates who are likely to be able to fill the role?
| gaoshan wrote:
| Agreed. At our company the technical interview involves walking
| a dev through a working app that uses the same stack we develop
| with. There are bugs to solve, potential optimizations that
| exist and the dev explains and walks through the
| client/server/database portions (leaning into one or the other
| as needed). No tricky questions or puzzles... just actual code
| (a simplified subset but still real, working code).
| jeffbee wrote:
| Adding 1 to an ASCII decimal strings is a great icebreaker and
| I always use it. It is not leetcode. It is a filter for people
| who have actually encountered computers before. Even though our
| industry is maturing there are still a huge number of
| candidates who present themselves without ever once having
| written a program. I find the question has a massive signal.
| Either the candidate aces it in 15 seconds, or they immediately
| ask a bunch of on-point clarifying questions, or they are
| stumped.
| marliechiller wrote:
| I have written countless programs but would not be able to
| answer that without first turning to google. You might have
| screened out plenty of valid applicants with this
| pphysch wrote:
| You don't know how to transform the string "12345" to
| "12346" in a mainstream PL?
|
| I don't think "valid applicant" and "doesn't really grok
| strings/types" are compatible, outside of intern/maybe
| junior positions. The filter works.
| marliechiller wrote:
| The filter works perhaps for whatever niche you might be
| working in. I cant imagine asking this to one of my
| candidates and then assessing their entire professional
| experience off of something like this though.
| pphysch wrote:
| What domain do you program in where handling
| strings/bytes is not a weekly if not daily task?
| marliechiller wrote:
| The point is not whether an applicant can or cannot do
| it, the point is that the question is deliberately
| rephrasing to obscure a candidates understanding. If you
| ask your average candidate to do that in laymans terms or
| they were given 5 seconds to google this would be a
| trivial task and you would have a different outcome. All
| this selects for is the candidate to have a working
| definition of an ascii decimal string in their head, it
| represents no ability to problem solve whatsoever.
| pphysch wrote:
| > All this selects for is the candidate to have a working
| definition of an ascii decimal string in their head, it
| represents no ability to problem solve whatsoever.
|
| Problem solving isn't orthogonal to having genuine
| expertise. Loads of awful, brittle, hard-to-read, but
| working, code gets written every day by people who are
| good at finding a solution but haven't RTFM, so to speak.
| suresk wrote:
| I think a lot depends on the context, the job, and the
| languages involved.
|
| Of course there is a trivial solution in pretty much any
| language, for example something like str(Decimal(x) + 1)
| in python. That's dead-simple and anyone should be able
| to do at least that.
|
| The later addendum that they want someone to know how
| data is store by the computer seems to imply that they
| want an answer that doesn't use these conversions, which
| gets a lot trickier depending on the context. I think
| you'd still expect someone who does C/C++ work to get
| there pretty quickly, but it is more than 15 seconds -
| you have to think about some corner cases and how you
| handle the string having to be resized in some
| situations.
|
| But in some languages, it isn't obvious to me how you'd
| do it (especially since strings are immutable in many
| languages) and I think it is maybe a bit unfair to ask
| someone who does Java or Python or whatever to do it off
| the top of their head.
| ninkendo wrote:
| Eh...
|
| You're given `99999`. Increment it. A naive approach
| would turn this into `9999:`. Making this work is a bit
| complicated and involves memory reallocation if you're in
| a C-like language and you need to increase the length of
| the string in order to increment it. You'll probably want
| a system where the caller passes a buffer of sufficient
| size to use for rewriting the string, in case you
| overflow. Make sure to have a way for the caller to pass
| the buffer length. You don't want to allocate because
| that's not the way it should be done in C, callers should
| generally allocate. You could use atoi, increment, and
| itoa to go back again, but that's probably "cheating"
| from the perspective of a leetcode advocate, they likely
| want you to do this without the stdlib conversion
| functions.
|
| There's a bazillion reasons why this sucks as an
| interview question. There's no way a correct answer is
| just something you'll "get in 15 seconds".
| jeffbee wrote:
| Whether this should be done in-place or not is a
| completely valid direction in which to take the
| discussion and would be a "pass" from me. Also a "pass"
| would be `return itoa(atoi(input)+1))` with relevant
| caveats.
|
| An O(1) in-place solution with a sane API exists in C++
| and the form of it is also a handy indicator of whether
| candidate who proposes solving this in C++ is familiar
| with more recent standards or not.
| ninkendo wrote:
| I don't see how you can increment `9999` in O(1) if the
| string length is considered the size of the input. You
| have to rewrite the string with zeroes, which is O(n) of
| the size of the string.
| jeffbee wrote:
| For that case, which is the worst case, yes. And the
| amortized average complexity is O(1) because that case is
| unlikely.
|
| Are you starting to see why this is a good icebreaker? It
| has all kinds of discussion potential.
| Aurornis wrote:
| Ironically, you just answered the "difficult" interview
| question in a few lines of casual commenting.
|
| If you're not allowed to use atoi and itoa, it's still
| not all that difficult to do in C. Incrementing ASCII
| characters and handling carries is really trivial.
|
| I'd be kind of worried if I was hiring a C developer who
| didn't know the basic things you described above. I'm not
| sure why you think those are esoteric concepts that we
| shouldn't expect developers to know.
| suresk wrote:
| Your last 2 sentences highlight the crux of it, I think -
| in the first sentence, you say "C developer" and in the
| second just "developers".
|
| This actually does seem like a great icebreaker-type
| question for a C developer. I'm less convinced every
| developer should be able to go into that level of detail
| if they are doing Javascript or Python or whatever.
| Ideally they'd be able to at least reason through some of
| this and demonstrate some understanding of some of this,
| but I'm not sure it is a great icebreaker question for
| all developer roles.
| crooked-v wrote:
| Javascript doesn't even have ASCII - every string is
| UTF-16.
| kaashif wrote:
| If someone really can't do that, then either they don't
| know how to count (very unlikely), they didn't understand
| the question, or they are really bad at translating what
| they would do on paper into a program. All disqualifying.
|
| Another possibility is nerves. Early in my career I was
| very nervous in interviews and I have sympathy. I have
| fucked up the most basic search algorithms completely and
| spewed gibberish when asked to explain the complexity of
| my solution.
|
| I have sympathy for that, but the only way to get through
| interview nerves is exposure therapy. At least in my
| experience.
| jeffbee wrote:
| A person who isn't well-versed in how the computer
| represents data internally is not a "valid applicant" for
| the positions I interview to fill.
| hcks wrote:
| What programs have you written?
| onion2k wrote:
| _All of this "clever shit" is exceptionally bad programming._
|
| In a company like Google (or Google 15 years ago really) there
| are problems with many possible solutions, but some solutions
| are better than others. The _aim_ of leetcode recruitment is
| that it filters for people who can not only solve hard computer
| science problems, but also recognize what problem they 're
| solving and find _good_ solutions rather than just solutions.
|
| "I can implement this with a library" is only a good solution
| if the library is solving the problem in the right way. If the
| library is solving the problem but solving it in an
| inefficient-but-working way that is not good programming. At
| the end of the spectrum where Google exists you need developers
| who know the difference.
|
| The problem with leetcode is that it doesn't actually filter
| for people who can understand problems in a general sense. It
| filters for people who know leetcode problems.
| josephg wrote:
| > If the library is solving the problem but solving it in an
| inefficient-but-working way that is not good programming.
|
| Yep. And even then, you need to know what you're looking for.
| Years ago I wanted a library which implemented occlusion on
| vector shapes for plotter art. I had no idea what terms to
| search for because I don't have a strong enough background in
| graphics. Turns out there are algorithms which help - but it
| was years before I found a good enough library.
|
| And if you know what to search for, there are so many
| terrible implementations out there. Look for priority queues
| on npm. Half the libraries implement custom binary trees or
| something, despite the fact that using a heap (an array) is
| way faster and simpler. If you don't know why a heap is
| better, how could you possibly evaluate whether any given
| library is any good?
| faizshah wrote:
| The reason they do this is because there is a lot of debate
| over having some objective way to collect information about a
| candidate. So they have multiple rounds of standardized
| technical interview questions from which they can compare
| interview feedback. The rounds will be from different
| interviewers so they can control for bias of one interviewer.
| Then they are able to compare this standardized data across
| multiple candidates.
|
| Imo this process is flawed though because just one or two
| rounds of technical interviewing gives you enough information
| about whether the candidate can code. After that you need to
| understand how the candidate thinks since most of the job is
| spent doing things that aren't coding. These are better probed
| by design questions, asking the candidate to critique some
| code, asking the candidate to explain a project from their
| resume and then propose alternatives and trade offs.
|
| Too often you get people who pass this interview process that
| can code at a basic level but hinder your team by giving poor
| feedback, having a fixed mindset, being a bad communicator, not
| being able to unblock themselves etc.
|
| It's fine if you are just looking to grow a new grad though,
| although former interns are better.
| PaulRobinson wrote:
| The problem is though how do you evaluate for real work without
| a portfolio of experience? Real work projects take weeks -
| perhaps months - to design, build, review and release. How do
| you test for that, really?
|
| I agree leetcode style interviews are artificial, but I think
| they persist because few people have identified and popularised
| effective alternatives. At least with leetcode you've shown
| people in front of you have been prepared to go learn arcane
| stuff and apply it. It's not good, but it's better than
| nothing.
|
| I was once asked to do the Gilded Rose kata[1] for one ~200
| headcount Series D "startup", and it not only resembled real
| work - it's a refactoring problem - but it also showed their
| engineering culture. When I joined, I found smart people who
| weren't leetcode robots, but thoughtful engineers trying to
| solve tricky engineering problems. I "stole" Gilded Rose to use
| in other companies when interviewing until I joined my current
| employer (a FAANG, heavily prescribed process), with great
| success. I would like to see more katas that are as good at
| testing real world skills.
|
| Also, something I've only ever been interviewed for twice in
| 25+ years, which I think is underplayed: pair programming and
| handling code review feedback. Do this more, please. If you
| hire people not knowing how they're going to respond to a
| principal engineer telling them "we need you to think about 4
| other things that weren't in the original scope given to you by
| the PM, can you please go deal with them", why are you
| surprised when toys are subsequently thrown out of metaphorical
| prams?
|
| [1] https://github.com/emilybache/GildedRose-Refactoring-Kata
| dkdbejwi383 wrote:
| Thanks for sharing, I've not come across this kata before.
| Seems like it'll be a fun one.
| MichaelZuo wrote:
| It seems fairly straightforward to just ask verbal questions?
|
| For example, if the position is mostly coding C then just get
| them to explain how some X interacts with some Y and how that
| interacts with some Z. Maybe with a copy of of K&R and get
| them to point to page so and so.
|
| Do that a few times, maybe use a whiteboard, and I think any
| experienced C developer will be able to tell who's faking it
| and who really understands within 2 or 3 iterations.
|
| Even if there are no experienced folks in the company, then
| it will take longer but, after an hour or two it'd be pretty
| difficult for anyone to fake a solid understanding of
| hundreds of pages of K&R.
| PaulRobinson wrote:
| Not the point you're making but in a C shop, if I interview
| and somebody pulls out K&R in 2023, they're not getting
| hired.
|
| I get the wider point you're making, and yes, a chat can
| help. Elsewhere in a reply to this I talk about how I
| personally like to do that, but the problem is, a
| significant number of people can talk about coding but
| can't actually code.
|
| I once interviewed somebody who had passed 3 previous
| calls. Asked them to implement fizzbuzz. Couldn't.
|
| That is a real problem. It's not myth.
|
| As such, I'm not hiring somebody without seen them writing
| code the same way I wouldn't hire a designer without seeing
| their actual personal portfolio.
| Apocryphon wrote:
| A Zed Shaw's _Learn C the Hard Way_ fan, I see.
| nomel wrote:
| > a significant number of people can talk about coding
| but can't actually code.
|
| We removed pseudocode from our pre-screening due to this.
| Some people are absolutely great with English and
| pseudocode, but can't write a for loop, in their
| "preferred" language of their choosing. I'm sure they
| could be _great_ at programming...eventually.
| david2ndaccount wrote:
| I write a lot of C and gave up on reading K&R as it is just
| too outdated.
| noodle wrote:
| > It seems fairly straightforward to just ask verbal
| questions?
|
| This is basically my interviewing POV. If you've done the
| work, you can talk about the work intelligently if I ask
| some questions about it. If I ask you how you would think
| about solving problem XYZ, you can probably verbally think
| through how you would solve the problem, what a solution
| might take.
| jebarker wrote:
| This seems like a better way to evaluate real-world coding
| skills. Did you use it in a standard 45-60 min interview or
| as a take home problem? It seems like it'd take a decent
| amount of time to read the requirements and just introduce
| the task.
| PaulRobinson wrote:
| Take home and "please time box it to maybe an hour maximum,
| you're probably doing a load of interviews and tech tests
| at the moment, so you don't need to finish: I just want to
| see your approach".
|
| In-person time I used to like to ask a question I got from
| here: "Tell me about your favourite coding work or side
| project". We'd then dig into choices, trade offs, obstacles
| and how they got around them.
|
| My favourite answer to this was "an OpenGL implementation
| for the X Window protocol which I wrote in Common Lisp".
| Just getting through the first layer of "Why [x]?", took 15
| minutes and we spent an hour talking about all the facets.
| Hired him, was a superb colleague.
| kaashif wrote:
| "Please timebox to an hour" is a bit dodgy though. If one
| candidate really does that, but the rest give it an extra
| 2 or 3 hours, that 1 hour candidate will probably be at a
| disadvantage.
| neon_electro wrote:
| Thank you for mentioning this. I always find myself going
| further back and forth with employers who allow a take-
| home exercise but ask that it be time-boxed nonetheless;
| it's difficult to try to unpack how they're trying to
| communicate what kind of time pressure a role
| experiences, and that if I took longer than their
| expected time box, does that look bad just because I
| needed some more time to understand the problem?
| remich wrote:
| I don't think most employers are out there looking at the
| timestamps on your commits to see if you really completed
| it within the timebox or not -- I certainly wouldn't.
|
| I don't think that candidates who spend less time or turn
| in incomplete take homes are necessarily at a
| disadvantage. Sooo much can be discerned from a take home
| even if it's not finished. I can evaluate a candidate's
| familiarity with modern syntax, how they organize
| functions, how readable their code is, whether or not
| they used ChatGPT/CoPilot or copy/pasted from an online
| tutorial (surprisingly easy to discern when you're
| evaluating many submissions), and so on.
|
| All of that tells me a lot about how well someone
| functions as an engineer, as well as what level they're
| operating at, and it doesn't require the completion of
| the take home problem.
| remich wrote:
| In a current hiring loop my company is doing for a senior,
| we have a take home divided into a series of steps, with
| explicit instructions that say that completion of the
| entire exercise is not necessary to advance (and we mean
| it).
|
| The take home serves two purposes: (1) should the candidate
| progress to the in person interviews? (2) if the candidate
| stumbles in the in person coding, can I deduce from the
| take home that they do actually know what they're doing,
| and the stumbling was a side effect of interview anxiety?
|
| I can tell a lot even from an incomplete take home, about
| whether someone is likely to do well on the in person
| interviews, but I mostly find it extremely valuable for
| (2), as a tiebreaker.
|
| It hasn't happened yet in this cycle, but I can imagine a
| situation where someone turned in a fantastic take home and
| then brain farted during the in person coding, and, thanks
| to the take home, got hired.
| VoodooJuJu wrote:
| >I think they persist because few people have identified and
| popularised effective alternatives
|
| Astrology persists, but that's not a testament to its
| efficacy.
| nine_zeros wrote:
| Refactoring is the best kind of test! It has a slight bias
| for programming languages but the bias can be mitigated by
| having refactorable libraries in many languages.
| nomel wrote:
| I'm fairly certain I would not perform well with this,
| unless the library was trivial.
|
| Refactoring is a task that's mostly about reading,
| understanding context, and a bit of rumination.
|
| I think having them design the library, or a fraction of
| it, from scratch, would give a more momentum.
| nine_zeros wrote:
| > I think having them design the library, or a fraction
| of it, from scratch, would give a more momentum.
|
| I have done this as a take home test and I am ok with
| this as long as it doesn't take more than 5 hours.
| catiopatio wrote:
| > "make a linked list" no, just use a library like everyone
| else.
|
| If you cannot sketch out a simple linked list on a whiteboard,
| you're not an engineer and have no business being hired as one
| at a place like Apple, full stop.
|
| I was asked to sketch out a hash table on the whiteboard. It
| was trivial, because a trivial hash table is trivial.
| KaiserPro wrote:
| > you're not an engineer and have no business being hired as
| one at a place like Apple
|
| well, unless you have a engineering degree, you're not
| actually an engineer, but we'll gloss over that. (big hint CS
| isn't an engineering discipline, otherwise testing,
| requirements gathering and cost analysis would be a big part
| of the course. )
|
| I was once asked to implement a distributed fault tolerant
| hashtable on a whiteboard. I'd still never make one from
| scratch unless I really really needed to. (and I've worked on
| distributed datastores....)
|
| but that wasn't part of the coding test, that was part of the
| design test.
|
| Which is my point, re-implementing things for the hell of it,
| is an antipattern. rote learning of toy implementations of
| some everyday function doesn't give you a good signal on if
| the candidate understands why you should use x over y.
|
| and again, my point is this: If I catch someone re-
| implementing something in a code review, they need to have a
| really good fucking reason to do it, otherwise it'll be
| rejected.
| whateverman23 wrote:
| > well, unless you have a engineering degree, you're not
| actually an engineer
|
| That's not a requirement in the US.
| edgyquant wrote:
| Nor is it a requirement for a majority of engineering
| types regardless of country. Civil engineers think they
| have a monopoly on the word; this should always be pushed
| back upon.
| OkayPhysicist wrote:
| They're not asking you to re-implement it on a whiteboard
| so they can open a PR and shove it in their new app.
| They're asking you to re-implement it to demonstrate that
| you understand it, and that given an understanding of
| something, that you have the skills to implement it.
|
| If you can't hammer out a technical interview using off-
| the-top of your knowledge, you're in the group they're
| trying to weed out.
| edgyquant wrote:
| >unless you have an engineering degree
|
| This is not true. There are dozens of types of engineers
| and that word doesn't mean civil engineer. There are audio
| engineers who work on music and film ffs, get over
| yourself.
| foldr wrote:
| I think a fair number of Leetcode 'medium' problems are
| reasonable as augmented versions of FizzBuzz. In most cases,
| someone who can code should at least be able to write a brute
| force solution to one of these problems and explain _why_ their
| brute force solution is slow. Where I think Leetcode-style
| questions become problematic is when they 're used as test of
| whether someone can invent and implement a clever algorithm
| under time pressure. Unless you're hiring someone to do
| specifically _that_ , then I think this style of Leetcode
| interviewing is of limited value.
|
| Also, some Leetcode problems just have unnecessarily unfriendly
| descriptions. For example this one, which is quite simple to
| implement, but which has an unnecessarily obscure problem
| description: https://leetcode.com/problems/count-and-say/
| slt2021 wrote:
| some companies/teams use leetcode hard level problems to
| specifically select for ACM ICPC level talent to solve their
| particular problems, writing very tight compute kernels in
| constrained environment and unbounded input
| varjag wrote:
| Not a fan of LeetCode but arguments like this almost sell me on
| it.
| sdfghswe wrote:
| Just use a library, but those who can implement the library are
| better than the ones who can't. And that's what leetcode aims
| to distinguish.
|
| You thought the point of leetcode was to simulate live work
| conditions? lol
| thereisnojesus wrote:
| What is it for. I don't think anyone here understands its
| purpose anymore.
| zyang wrote:
| 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.
| [deleted]
| slt2021 wrote:
| gogle's product failure is failure of executives and product
| managers, not engineers.
| compiler-guy wrote:
| Teams at Google are very fluid, there are many of them, and
| they change regularly. So it makes a lot of sense to be sure
| a candidate could be successful in a wide variety of teams.
| gumby wrote:
| I'm not going to defend "leetcode grinding" and its pathologies
| but TBF this is problematic:
|
| > "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.
|
| Sure, those statements (just use an existing library) are what
| you'll do in practice especially as a beginner. But there is
| value in asking these kinds of questions.
|
| One is "do you know what's going on under the hood?" On another
| post I just saw a comment in which someone advocated counting
| the number of occurrences of something in a list by filtering
| it and then getting the length of the result. This is almost
| certainly a terrible solution as it allocates memory (which has
| to be freed) in what can be done in a single quick pass. By
| asking you such a question the interviewer can learn if you
| have some idea of the tradeoffs and why something might be a
| good or bad idea.
|
| These are the kinds of decisions that can have order of
| magnitude impacts on runtime, which can have huge impact on the
| company's costs.
|
| Likewise doing arithmetic with strings as inputs would expose
| interesting but not super complicated questions about how
| arithmetic works, how you parse a numeric value out of its
| written representation (detest the word "conversion" for this),
| what are interesting bounds. If the job is really so high level
| that you don't have to think that there's an actual machine
| involved, then yes the questions aren't useful. But how many
| jobs are really so abstract?
|
| > We don't live in the 80s anymore. we don't need to make our
| own sort algorithms.
|
| No, but sometimes you have to make a choice based on the data
| to be operated on.
| alex_lav wrote:
| > Sure, those statements (just use an existing library) are
| what you'll do in practice especially as a beginner.
|
| I think it's really not about "beginner" vs. "expert", but
| moreso about the specificity of your role. If you're tasked
| with making general cloud services, it's probably fine. As
| your role gets closer to core systems/algorithms engineering,
| obviously that changes.
|
| > But there is value in asking these kinds of questions.
|
| There is value knowing, but the dynamic of an interview make
| things like this harder to ask/harder to answer.
|
| > One is "do you know what's going on under the hood?" On
| another post I just saw a comment in which someone advocated
| counting the number of occurrences of something in a list by
| filtering it and then getting the length of the result. This
| is almost certainly a terrible solution as it allocates
| memory (which has to be freed) in what can be done in a
| single quick pass.
|
| In the real world the validity of this solution depends on
| its input and use. Also in the real world, especially if
| you're not on one of the above-mentioned specialist teams,
| it's usually more important to be readable and maintainable
| instead of just purely performance oriented. So a single pass
| solution that's harder to grasp at a glance becomes less
| desirable than multiple passes as long as your performance
| requirements can afford it.
|
| > By asking you such a question the interviewer can learn if
| you have some idea of the tradeoffs and why something might
| be a good or bad idea.
|
| Totally, but the issue becomes "Can you figure out an
| algorithm on a whiteboard", instead of the (as you've already
| agreed) correct path of "Can you work through tradeoffs of
| one implementation vs. another". I think this question could
| pretty easily be presented in a way that isn't a quiz and
| also allows the programmer to demonstrate their
| problemsolving ability without seeming adversarial.
| SirMaster wrote:
| > One is "do you know what's going on under the hood?" On
| another post I just saw a comment in which someone advocated
| counting the number of occurrences of something in a list by
| filtering it and then getting the length of the result. This
| is almost certainly a terrible solution as it allocates
| memory (which has to be freed) in what can be done in a
| single quick pass. By asking you such a question the
| interviewer can learn if you have some idea of the tradeoffs
| and why something might be a good or bad idea.
|
| > These are the kinds of decisions that can have order of
| magnitude impacts on runtime, which can have huge impact on
| the company's costs.
|
| Then the questions should be more like: What data structure,
| library, method, steps, would you use to solve this problem
| and why. What are the tradeoffs of your choices, etc?
|
| All of this can be answered in fairly high level pseudocode
| too and still show that they understand the concepts etc.
| KaiserPro wrote:
| > Sure, those statements (just use an existing library) are
| what you'll do in practice especially as a beginner
|
| The more code you write, the more you have to maintain. Sure,
| of course there are times where you need to re-implement
| something from scratch. But those times are rare (or should
| be). Making something from scratch without strong
| justification is a strong signal, just not a positive one.
|
| Now, as you point out, "when would you write x from scratch"
| is a great question to ask someone. I am vary wary of people
| that are willing to overspend innovation tokens. But thats a
| design/systems/culture question, not a coding question.
|
| the signal I want from a coding test is the following:
|
| o Can they demonstrate and understanding of the programming
| language?
|
| o Do they create readable code?
|
| o Do they ask questions?
|
| o Do they follow the style of the programme they are
| modifying?
|
| o Do they say "I don't know"?
|
| o Do they push back on weird or silly requirements?
|
| all of those things make working with someone much easier.
| None of those questions require "implement algorithm that
| only exist in Computer Science courses". They can all be
| answered by something like:
|
| "here is a program that fetches a json document, but it
| breaks often, please make it more reliable"
|
| That is far more realistic, and more likely to what they'll
| be doing.
|
| The dirty little secret about most coding jobs is that
| actually, the important thing is getting something functional
| and stable for the business, so it can make money. Then after
| that its responding to feature/bug requests. As a programmer,
| your job is to convert business logic into computer logic.
| 99% of the time, this doesn't mean making artisan libraries
| that improve some tiny metric by 20x.
| gumby wrote:
| > o Do they ask questions?
|
| I find I get 90% of the insight from simple questions like
| "write a function to shuffle a deck of cards. Don't worry
| about simple typos like forgetting a semicolon."
|
| You learn a lot from how they set things up (make a suit
| class, and a vector of card classes? Or just use the
| integers 1-52?) and talking about that. Do they think about
| the problem (and, as you say, ask a couple of "requirement"
| questions) before diving in?
|
| One of the best hires I remember was someone who got this
| problem wrong (went to a lot of work to leave the deck
| unshuffled). We gently asked if it did what was required.
| Hi smacked himself on the forehead and said, "I'm a fucking
| idiot" (in front of us in his interview!) and quickly
| corrected the bug. Great guy.
| devoutsalsa wrote:
| If you ask me a question that boils down to "write a card
| shuffling algorithm", I'm going to do less well because
| I'm being taxed by the thought of "Why is this person
| asking me to shuffle a deck of virtual cards?" During the
| interview, I'd probably just google "best algorithm for
| shuffling deck of cards in <language>", and I'd tell you
| I was looking it up. If you tasked me with shuffling
| cards on the job, that's what I'd do.
| gumby wrote:
| You could just ask, and we'd answer "it's just a simple
| problem so both of us can see what it's like to work
| together." You'd be surprised how many people show up who
| don't actually know how to write a for loop.
|
| And if you didn't like the experience you wouldn't want
| to work for us so the interview would be a success too.
| deckard1 wrote:
| you don't actually believe that "work together" crap do
| you? You realize you're dangling a job over their head,
| right? There is a power imbalance. You'll never see "work
| together" in an interview because you're not colleagues
| on equal footing.
| gumby wrote:
| Often candidates already have a job and are looking to
| see if they want a change. There's parity in such
| situations.
| HeyLaughingBoy wrote:
| > don't actually know how to write a for loop
|
| My god, yes. We had a two-part problem that we used for
| the "work skills" part of the interview. Part 1 boiled
| down to writing a two-level nested for loop that was
| simpler than fizzbuzz. Part 2 was using that loop to
| solve the rest of the problem, which was far more
| complex. I lost track of how many candidates spent 40 of
| the 50 minutes _just writing that loop_.
| neon_electro wrote:
| Come up with better problems, _please_.
| gumby wrote:
| What would you recommend?
| catiopatio wrote:
| I'm not sure that's a great interview question; the right
| answer to google the appropriate algorithm (e.g. Fisher-
| Yates), make sure you understand implementation errors
| that will lead to bias, and implement it over any
| arbitrary sequence.
| gumby wrote:
| > The more code you write, the more you have to maintain.
| Sure, of course there are times where you need to re-
| implement something from scratch. But those times are rare
| (or should be). Making something from scratch without
| strong justification is a strong signal, just not a
| positive one.
|
| It really depends on what you're working on. A package to
| manage a dentist's office should be as off the shelf as
| possible. I don't care about I/O and try to do as little as
| possible, using whatever's off the shelf, but my HFT
| buddies are bumming the hell out of it, customizing the
| kernel, and whatnot. You may use elastic search to save you
| time and money, but the folks working on it have probably
| run over it so much there's nothing but custom code left.
|
| It's all context.
| josephg wrote:
| Yep I absolutely agree with this.
|
| I've spent about the last year optimising text CRDTs so
| they're actually usable in practice. A few years ago,
| 800mb of ram usage and 5 minutes processing was common to
| open a document. Now we're talking 2mb of ram and 20ms.
| That is the difference between something not being viable
| and something being usable everywhere. And yes: my code
| involved a lot of custom data structures and algorithms.
| There were no libraries in cargo which did exactly what I
| needed.
|
| This thread is full of people bemoaning "leetcode
| problems" for being irrelevant in software jobs. But I
| use them all the time in my work. Software engineering is
| far more varied than any of our individual careers.
| neon_electro wrote:
| I'm happy for you that you've found a job where the
| things Leetcode emphasizes has merit and importance and
| value in your day to day work.
|
| Everyone who's on the other side of the Leetcode debate
| from you wants the exact same thing - an interview
| process that is representative of the actual day-to-day
| work.
|
| As a Web developer, inverting a binary tree is not a
| thing an employer has ever asked me to do.
| josephg wrote:
| Yes. You, me and the GP commenter seem to all be
| vigorously agreeing with one another. Job interviews
| should be based on what the role entails. If that
| includes data structures and algorithms, so be it. If
| not, leave them out!
|
| As the GP commenter said:
|
| > It really depends on what you're working on. ... It's
| all context.
|
| I brought it up because many (most) commenters in this
| thread seem to be claiming that this knowledge and skill
| is _never_ useful. That its ridiculous to ask about this
| stuff in any job interviews, except as a ritualistic
| hazing ritual. This is also absurd.
|
| > As a Web developer, inverting a binary tree is not a
| thing an employer has ever asked me to do.
|
| I've never had an employer name any data structures
| explicitly. Its our job as the software experts to know
| which tools and technologies are relevant. But with that
| said, I can't remember ever using custom data structures
| in frontend website code either. If I were hiring a web
| developer, there are so many things I'd rather spend time
| talking about in an interview. (HTML & CSS knowledge, web
| frameworks, design skills, raw programming skill, etc.)
| Apocryphon wrote:
| > many (most) commenters in this thread seem to be
| claiming that this knowledge and skill is never useful.
|
| Those commenters are making generalizations because many
| (most) jobs in the industry do not find that knowledge
| and skill useful. Certainly specialized edge positions
| exist.
| nonameiguess wrote:
| I believe Google at least at that time was trying to hire
| engineers who could theoretically be put to work on any
| team, potentially being asked to create TensorFlow or
| MapReduce or contributing to the Linux kernel in service
| of Android, not people who have pigeonholed themselves
| into only being considered web developers.
|
| If pure CRUD companies only looking for JavaScript
| specialists are also using leetcode screening, they're
| missing the point.
| noleetcode wrote:
| Here's the difference: I bet you had time to think
| through the novel problems and didn't have someone
| hovering over your shoulder, demanding you come up with
| solutions within 20 - 30 minutes -or else-.
| EMM_386 wrote:
| > One is "do you know what's going on under the hood?"
|
| Why should I need to? Let's take Microsoft's .Net sort
| implemtation.
|
| It will intelligently determine which is the optimized sort
| given the conditions it's facing.
|
| Heapsort? Mergesort? Quicksort? Radix Sort.
|
| And the most-possibility optimized versions of each.
|
| This is what data scientists do. We don't need programmers
| standing at whiteboards writting BubbleShort and being told
| it's wrong. In the real world, you call .Sort() and get on
| with real work.
|
| Sure, you can hand-roll your own sort for hot-path cases but
| that's likely been taken into account anyway!
| nottorp wrote:
| Uh oh. You realize you just stated you actually know
| sorting algorithms and even know enough to be able to
| decide to roll your own if needed?
| dkdbejwi383 wrote:
| 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.
| yieldcrv wrote:
| > It tends to be a rote regurgitation exercise.
|
| where there are _much_ greater selective pressures in India
| and China to excel at this than there are in the US, raising
| this irrelevant bar to absurd territory if you value your
| time
| robryan wrote:
| A lot of places will also do a desgin interview to cover this
| aspect of the job.
| pavlov wrote:
| Which raises the question of why do the other kind of
| interview at all. I mean the leetcode nonsense whose end
| state is often a theatrical performance: "I'm pretending to
| invent this clever algorithm on the fly although I've
| practiced it for weeks".
|
| Is there any evidence that candidates who do well on design
| interviews but fumble on leetcode would be any worse at the
| actual job?
| porridgeandrice wrote:
| IME it's a test in which it is easy to grade many people
| in a way that it is really unlikely that two people end
| up with the same grade. That is what leetcode achieves
| and that is really the majority of the reason it is used.
| So it is just very convenient for hiring. In India, we
| have companies coming to hire students from colleges, and
| as the first filter, they give you three leetcode
| questions, and average the number of test cases you
| passed in each of them and rank you based on that. I
| spoke to one of the companies, they said that they had
| _very_ few people that had the same score, and it was
| easy to choose within those small sets by reading their
| resume/whatever.
| slt2021 wrote:
| Leetcode is simply testing whether you studied Computer
| Science, took Data Structures & Algorithms course, and
| read the CLR book on algos and practices it. Nothing
| else. This is really freshman level cs work. very simple.
|
| people who cannot leetcode - a simple data structures &
| algorithms inteview - cannot understand runtime nuances
| of what they write.
|
| This is how you end up with N+1 algorithms and
| exponential runtime.
|
| For example look at all modern front-end in javascript -
| usually leetcode is more relaxed for front end, and you
| end up with ungodly gobbles of unnecessary loops inside
| loops wrapped in loops that traverse DOM for no good
| reason and freeze the browser.
|
| it is the javascript people who import node libraries
| that contain 3 lines of code, instead of writing it
| properly
| remich wrote:
| You don't need to be good at leetcode to make a
| performant and well written frontend. You don't even need
| to know data structures, algorithms, or Big O notation.
| Clamchop wrote:
| Maybe. My experience is that a lot of the unprimed recall
| gets weak very quickly without practice. There's irony in
| testing for skills that a fresh graduate may do better at
| than someone with substantially more experience.
|
| Primed recall can remain strong for many years, but
| leetcode often penalizes googling around to refresh your
| memory, even though that is what almost everyone should
| do before taking any further steps toward an
| implementation. Depending, it's often also the correct
| thing to do before choosing a library, the parameters to
| a function, code base organization, and lots of other
| details.
|
| Of course, domain experts may be very strong in their
| specialty, but that's a special case with narrower scope.
|
| I can hypothesize that testing for a "fast study" may
| have more predictive power. I have seen some interviews
| that are designed for this, leetcode adjacent but less
| antagonistic.
|
| But anyway, I am spitballing, to be real with you.
| photon_lines wrote:
| 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. I suppose its better to screen for IQ and
| desparation than you know...people who love developing great
| software. Let them keep doing what they're doing while
| treating their own people like disposable garbage during hard
| times (like Google & Meta just did) and we'll see what
| they'll churn out over the next decade or so (I'm not
| expecting anything from either of these companies).
| josephg wrote:
| > LeetCode has no correlation with great software
| development. Great development is more about paying
| attention to the end users
|
| 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.
| nonameiguess wrote:
| This isn't really fair. All of Android, the Go programming
| language, TensorFlow, MapReduce, Big Table, Kubernetes, V8,
| Chrome are all very good engineering, software that stands
| the test of time and is likely to remain in use for
| decades. It's not garbage. They're great at libraries,
| plumbing, infrastructure layer tooling that enables
| Internet scale.
|
| What they aren't good at is consumer-facing web services
| with graphical frontends, at least since Gmail or so. Even
| there, businesses seem to like the G Suite.
| slt2021 wrote:
| > gathering requirements, clarifying ambiguity, weighing up
| trade-offs, making sure code is clear
|
| if you dont do that in leetcode interview - you will not make
| it, or you will be graded as junior/entry level engineer.
|
| No senior engineer will be passed without doing what you
| described during the leetcode interview
| circuit wrote:
| You do know we hire people who have to _write_ these libraries,
| and they can't just defer to something else with no
| consideration to time or space constraints. None of the
| questions are designed to be brainteasers or 'gotchas' but to
| get you to start discussing the problem and show your depth of
| knowledge/expertise.
|
| If I ask you a question along the lines of "write me a function
| to tell if two number ranges intersect" and your solution is to
| grab a library instead of writing a simple predicate...then
| perhaps the role is not a good fit.
|
| "Use a library for everything" is how we ended up with left-pad
| on npm.
| sacnoradhq wrote:
| Clickbait. This isn't a FTE with TC, it's an internship. Unlike
| Apple, most MANGs cut internships to functionally zero. You're
| never going to get a corporate coding job without multiple rounds
| of technical interview because common sense.
| lazyasciiart wrote:
| > Unlike Apple, most MANGs cut internships to functionally
| zero.
|
| Uh, when are they supposed to have done that?
| stevebmark wrote:
| A nice story, and a unique situation from someone who obviously
| shouldn't be giving anyone advice.
| hesdeadjim wrote:
| I guess it serves as a reminder that anything is possible,
| however (extremely) unlikely.
| minimaxir wrote:
| I too got my first job in tech at Apple in 2012 without a CS
| degree or taking any LeetCodes.
|
| I got discovered due to my frequent shitposting in the comments
| section of TechCrunch.
|
| I don't offer any career advice.
| GeekyBear wrote:
| I found this quote interesting and worth sharing:
|
| > I remember that my manager specifically pointed out that he
| didn't care about where I went to school or my GPA -- he said
| something like "it only matters what you can do."
| wongarsu wrote:
| Both which school you go to and your GPA try to be proxies
| for what you can do. They are probably even reasonably good
| proxies (for some jobs). But on the other hand too many
| people rely on them, so as a manager you can get great hires
| by finding brilliant people who are undervalued on those
| metrics, and thus not as strongly fought over on the market.
|
| And of course at some point in your career nobody should be
| asking for your GPA or school anymore because by then there
| should be much better ways to communicate your ability.
| john-radio wrote:
| Well, the title is not "How to get a job at Apple without..."
| is it?
| zyang wrote:
| Luck is a part of life. I guess the key takeaway here to focus
| on your craft and showcase your work.
| [deleted]
| dazh wrote:
| Yeah, I'd bet that there was probably only a handful of people
| like this in the entire intern class. I wouldn't put all my
| effort or hold out for a case like this. Your time would be
| better spent doing LeetCode.
| birdyrooster wrote:
| I dunno it's actually not too atypical. My team is half
| graduates and half drop outs.
| _jal wrote:
| Yep.
|
| I also personally managed to drop out of both high school and
| college.
| tjpnz wrote:
| I realise this is a different scenario to op, but be wary of
| Apple recruiters claiming a LeetCode-lite or homework assignment
| driven process. My own experience interviewing for a hardware
| division role in Tokyo was that it's a complete lie.
___________________________________________________________________
(page generated 2023-08-17 23:02 UTC)