6 ms·

> 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 th

> 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.
      - WalterBright 2y ago
        My compilers support inline assembler, but these days there doesn't seem to be much of any point to them. The compilers have simply gotten too good.
        2y ago
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.

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.
    - WalterBright 2y ago
      My compilers support inline assembler, but these days there doesn't seem to be much of any point to them. The compilers have simply gotten too good.
      - 2y ago

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.