11 ms·

Big tech interviews tend to be daunting. Many long term employees lose the skill, and fear the impact of work interruption on their resume as well as their abil

• WalterBright 2y ago
  > I'm unclear what employers are deriving from this exercise at this point It filters out the complete frauds. Yes, there are people who know all the right things to say in a job interview, but cannot code at all. If you hire one of them, it takes a bit to find out they cannot code, and a bit longer to fire them, so you're out $$$$ paying their salaries for nothing. For example, a recruiter I know will ask a tech candidate "what is 20% of 20,000?" A significant percentage cannot answer the question. Some even cry. It's shocking. A friend of mine was looking at getting a FAANG job. He was worried about the leetcode tests. I suggested he spend a month going through the leetcode books studying them - that the return on his time investment doing that will be one of the best ROIs he's ever done. He did, and got the job. (Although the LC was just a first gate one had to go through to get to the real job interview.) Personally, I have no idea how I'd do on an LC test without prep. But I don't have a problem with studying it to get a top job.
  • indigodaddy 2y ago
    I get that perhaps you were using the proverbial "I" in your last sentence as an example of something everyone should be willing to do in/for their career, but does someone of your stature even need a real interview, much less a LC test, to obtain a top job? It's kind of funny imagining a young tech bro interviewing you, tbh.
    • WalterBright 2y ago
      It's an interesting question. I'll try to answer. I generally do not use clever algorithms in my code. I just use straightforward ones. Rarely, I might need a better one and go looking for it (like a better hash algorithm). I rarely use a data structure more complicated than an array, list, binary tree, hash, or single inheritance. What I have, though, is decades of experience with what works and what doesn't work. (My favorite whipping boy is macros. Macros look like they are great productivity boosters. It takes about 10 years to realize that macros are a never-ending source of confusion, they just confuse and obfuscate every code base that uses them. I could go on about this! ...) I have become pretty good at writing modules that minimize dependencies, and pretty good at the user interface design of a language. But still, if the job wanted a leetcode test, I'd take it, no problem. I'd study up first, though. If a young tech bro was interviewing me, I'd suggest he show me his best code, and I'd do a review of it :-) The point of that would not be to humilate him, but to demonstrate the value I can bring to improving code quality. If I was being interviewed for a job writing a faster divide routine (the ones I wrote were shift-subtract, slower but bulletproof), a better random number generator, a cryptographically secure hash function, a tighter compression algorithm, a faster sort, I'm not the right guy for that.
      • indigodaddy 2y ago
        Thanks for that very interesting and insightful feedback!
      • WalterBright 2y ago
        P.S. I was once asked to review the code of a famous programmer I won't name. I was shocked to discover that the large codebase had 3 different implementations of bubblesort in it. I replaced them all with a call to qsort(). He asked me how I managed to speed it up :-/ We all have our blind spots. I do, too.
        • acdha 2y ago
          My favorite blind spot is how our definitions of quality change over time. I knew someone who had a mature codebase which a new developer made substantially faster by removing his old optimizations. He’d measured very real improvements back when he made that hand-rolled assembly code on early Pentium generations but by the time we revisited it less than a decade later the combination of compiler and processor improvements meant that the C reference implementation was always faster. (I was assisting with the port to PowerPC and at first we thought that it was just XLC being especially good there, but then we tested it on x86 with GCC and found the same result) Beyond the obvious lesson about experience and sunk costs it was also a great lesson about how much time you assume you have for maintenance: when he’d first written that code as a grad student he’d been obsessed with performance since that was a bottleneck for getting his papers out but as his career progressed he spent time on other things, and since it wasn’t broken he hadn’t really revisited it because he “knew” where it was slow. Over time the computer costs eventually outweighed that original savings.
  • ltbarcly3 2y ago
    I have done probably 500 to 1000 tech screens for big tech companies (as the interviewer) and this is completely true. I have interviewed many people employed in tech as programmers for their entire career and they can't code. I don't meen leetcode, I mean they get confused trying to write brute force substring search. The nested for loop seems to be too complex for them to keep in their head all at once. I have had numerous people cry. Again this was a screen, not leetcode. I'm asking them to check if text has mismatched parens, or find a substring. Things you do for homework in your 2nd programming class freshman year. Things every competent programmer can do while chitchatting about the job. I would estimate that more than 10% of screens are like this, again these are employed people in the industry for years, sometimes tens of years. Edit: I understand that people can get flustered, I understand that some people have trouble under pressure or while being observed. That's why I pointed out multiple times that the problems I gave are extremely, EXTREMELY easy. I'm basically asking them to write down their name and they sit and look at the pen like they've never seen one before. If you can't write a 5 line function to find whether a substring occurs in a larger string when given 45 minutes, your choice of programming language, and as many attempts as you need to debug and try again you simply will not be able to do any useful work as a programmer. If you don't know that to match parens you need to use a stack (or at least that it's one way to do it) you either have a very poor memory or no training in computer science at all - either of which is frankly disqualifying. Anyone borderline competent would invent a stack when presented with this problem if they hadn't already been told this fact a dozen times during their education or even light reading about algorithms.
    • momocowcow 2y ago
      You are still not testing if they can code. But whether under the scrutiny of another person, they can code. Maybe this is important to you, maybe peer programming is important to you for example. I remember a young dev who couldn’t pass such tests, as he would get too nervous, yet he had written the core tech for many shipped products. The type of guy you would just stick in dark room. With age this type of stuff settles down.
      • giantg2 2y ago
  • visarga 2y ago
    > it takes a bit to find out they cannot code, and a bit longer to fire them, so you're out $$$$ paying their salaries for nothing Not just that. They block the hiring process. Maybe there was just that one open position on your team, and that bad 3 month hire postponed a good hire by 6 months. It's also very incomfortable to fire and start again. My interviews contain questions that are basic, and any new team mate should know. I keep asking them because 90% of the candidates actually can't answer them well. You should know what a "dot product" is if you want to work as a ML engineer, that kind of stuff. Or be able to open a text file and count word frequencies.
  • ezekiel68 2y ago
    True words. It's not 'imposter syndrome' if one comes across as an imposter (though it might have been just be a bad day). I can appreciate the gating process because it's a real drag to get hired and then spend more time than necessary not doing my work but trying to help coworkers catch up on very basic and fundamental skills in order to be able to collaborate with them.
  • eastbound 2y ago
    > For example, a recruiter I know will ask a tech candidate "what is 20% of 20,000?" A significant percentage cannot answer the question. Some even cry. It's shocking. During our interview, we ask candidates to design a history system. The key is to realize that our database is only 8Gb, and storing a year of updates is only 160Gb, so $2pm in AWS. Once there, a simple DB table suits, no need to set up Amazon S3. So we ask them for the multiplication. First we give them the data, and if they don’t do the calculation, we nudge them, then we ask them, then we write the multipliers for them, then we take the calculator out and write the result for them. Those are Masters degrees. They can’t even do calculations, let alone getting it right, because 500MB x 200 days a year = a few petabytes apparently. And after that, they’re exhausted, it’s impossible to ask them the rest of the questions like “So is it worth worrying about a Rube Goldberg machine when you’re in for $2 of AWS costs?”.
    • DarkContinent 2y ago
      Does your interview process require knowing cloud costs off the top of your head? Because that's hard to track tbh
      • eastbound 2y ago
        What the… no.
      • akdor1154 2y ago
        Sounds like it requires knowing them to an order of magnitude or so... Which honestly sounds like a pretty good bar to have your team above?
        • yallpendantools 2y ago
          Honestly, after ~13y in this, I only know a handful of items from the famous latency table, notably those I've used a lot (mutexes cost 25ns, is only 1/4th of main memory reference tho, then disk seek is x100K of that). I'm "DevOps" (and titular variants thereof) in most of my resume. That said, I'm not above your bar as each cloud provider have their own pricing model. I'm not even above your bar for AWS---which I've used the past six years---just for the sheer diversity of their offerings, not to mention regional variations. I know how EC2 servers are priced relative to each other but when we include ECS, DynamoDB, Lambda, etc., I'm gonna need a cheat sheet.
  • lumost 2y ago
    Aye - I don’t tend to have a problem honestly with “classic” lc tests. I tend to take issue with uncommon/nuanced Dynamic Programming questions and clever uses of binary search. Both of these categories tend to rely on the engineer knowing the “trick” of the particular question. Perhaps I'm naive, but I suspect that hiring based on a candidates ability to produce optimal solutions to LC Hards will bias strongly towards candidates who can't code, but are very good at interviewing.
  • johnnyanmac 2y ago
    I'm still surprised how were 3 years into this horrible market and we still have people that just go "yeah bad employees just grind leetcode". It's not about skills at this point, companies just want to pretend to hire while not admitting we're now heading towards a recession.
• Der_Einzige 2y ago
  Just do what everyone is doing today and use those AI tools for cheating. There’s a whole industry of invisible and hard to detect leetcode AI cheating tools. Glad they exist and I fully support all candidates using them aggressively.
• mym1990 2y ago
  I definitely feel that first part. I landed in a nice company in SF about 8 years ago and am still here. The culture has changed a lot but I often find myself doubting whether I could repeat the whole thing or if I got lucky. (The work is fine, and the company is one of the good ones I feel, so no real qualms there).
• lr4444lr 2y ago
  I agree, but I look at it like trying out for an athletic team. Once you're on the team, you are mostly practicing plays, doing clinics, and simulating competition, but to get on the team in the first place you have to prove your general fitness by running, say, a 6 minute mile. You may not be able to do that again easily right away once you've been on the team for a while because you don't practice running for pure time at that distance, but it's a level of fitness you should be easily able to obtain again if you had to, and it's a very useful benchmark to a scout. When you're laid off, it's time to start doing that "roadwork" again. It will be a bit hard at first in practice, but if you've been a solid contributor, you should be able to get fit enough again to prove that.
  • Aeolun 2y ago
    Unlike, you know, proving that by the fact my previous employer was happy to retain me for 10 plus years?
    • lr4444lr 2y ago
      You've never worked at a place where someone was an incompetent hanger-on who was an expert at self promotion and stealing credit? Or hired someone like that accidentally? Notwithstanding, I have long argued that a non-profit credentialing body for SWEs offering cerification exams (which also required regular updates) akin to passing the bar or USMLE could go a long way to solving this problem. It would come with other drawbacks, perhaps not worth it, but we have to accept that constant tech interviews is the price we pay for refusal to standardize and professionalize.
      • Aeolun 2y ago
        > You've never worked at a place where someone was an incompetent hanger-on who was an expert at self promotion and stealing credit? Or hired someone like that accidentally? Thinking back on it. Not really. I’ve had a few people be outright incompetent, but I’ve never been at risk of them stealing the credit for stuff. The closest I’ve come is people that should probably be fired, but manage to barely hold on by being experts at self promotion.
• bbqfog 2y ago
  This is a persistent myth in our industry. If you're a good manager, you can tell within minutes if someone is "for real", if you can't, you aren't qualified to be hiring people. Have you even looked at their GitHub?
  • guappa 2y ago
    > Have you even looked at their GitHub? Lol, considering most big projects are not on github, you're just showing your own lack of clue.
    • bbqfog 2y ago
      Great, I'll continue my "lack of a clue" and keep hiring the best engineers in the world.
      • guappa 2y ago
        If your definition for "best engineer in the world" is "hired by you"… sure. I'm just not sure anyone else in the world would agree with this definition :)
        • bbqfog 2y ago
          My definition of "best engineers in the world" are people that have wildly successful GitHub accounts. I'm very glad I'm in an industry with losers that don't know how to compete. It's like playing on easy mode!
          • guappa 2y ago
            Lol. Don't worry "losers that don't know how to compete" have better things to do than to work with jackasses like you. :)