10 ms·

I still don't get why such questions are even asked as most jobs I've ever had not even remotely touched those and I've touched quite a few industries, technolo

I still don't get why such questions are even asked as most jobs I've ever had not even remotely touched those and I've touched quite a few industries, technologies and types of companies. To me, the value of a software engineer is to ask questions, make hypotheses and be able to iterate quickly. Balancing trees, leetcode and other algorithmic stuff on the spot sounds like bringing the dreadful education system structure to the real world. Also if a senior person can't in 30/45 min of talking with someone figure out the general experience level then the problem is them, really.

hintymad 2y ago
Personally I think such questions have three values: - Future proof. Unless I work for an outsourcing company, sooner or later I will want to push the envelope, or so I hope I do. And to push the envelop, one needs good CS fundamentals (maybe there are some exceptions in some specialized field). Think about React. It's a JS framework, yet to invent it one needs to understand at least compiler and graph. - Geekiness/talent filter. The same reason that the nascent Google and Microsoft and any elite companies like Jane Street asked Putnam questions, Martin Gardner questions, ICPC questions, and clever probability puzzles. Whether it's a good idea is debatable, but at least those companies want to have such type of people and they were hugely successful. Note the word filter: people who pass the interview may not be good, but failing the interview means the candidate may not be smart or geeky enough. Again, I'm not endorsing the idea but just exploring the motivation of the interview policies. - Information density. Assuming a company does want to time box a coding interview in an hour, it will be hard to come up with realistic question without spending too much time on the context. On the other hand, it's relatively easy to come up with a data structure/algorithm question that packs enough number of abstractions and inspection points to examine one's programming skill.
- davidw 2y ago
  > Think about React. It's a JS framework, yet to invent it one needs to understand at least compiler and graph. Are you hiring people to create new JS frameworks, or to use an existing one?
  - paulddraper 2y ago
    To use an existing one. And tools are best used when they are understood.
    - davidw 2y ago
      Hiring, like many things - including engineering - is about tradeoffs. Is someone more knowledgeable "better"? Sure. But sometimes it's about getting a specific thing done, and if you're hiring someone to improve a web thing that uses React, maybe you don't need someone who understands compilers and the kernel and how the underlying hardware works and all that. Maybe you can spend a bit less and get someone who will do a perfectly adequate job.
    - bjablonski 2y ago
      How many react developers understands compilers & graphs? I'd wager that it's way below 10%.
      - mewpmewp2 2y ago
        Also why do you need knowledge on compilers and graphs to create React? Firstly, React is not compiled. Secondly the graph or tree or whichever aspect can come naturally when you come up with the idea of how it would be best to maintain JS apps. In fact most important experience should have been grinding put tons of unmaintainable JS apps to come up with something like that.
      - paulddraper 2y ago
        I wouldn't argue with that.
    - Paul-Craft 2y ago
      I don't know anything about quantum mechanics. Does that mean I don't understand how computers work?
      - paulddraper 2y ago
paulddraper 2y ago
> I still don't get why such questions are even asked The thesis is not that these exercises are representative of work but rather predictive of performance. Sales has a similar phenomenon with sports. While there is no athleticism involved in selling, many believe history in competitive sports to be a positive predictor of sales success. --- You can reasonably argue whether leetcode accomplishes this well or poorly, but... Always remember that purpose of an interview (for an employer) is to predict performance. So you are looking for the resume screening+interview process that most accurately assesses that.
- xandrius 2y ago
  So you're saying that someone wasting their time studying leetcode to pass a stupid game is a good indicator? I would almost believe the opposite: if you actually pass those tests with flying colours, it shows me that you believe you needed to do that to be hired, while someone who's actually experienced would never in a million years step down so low.
  - paulddraper 2y ago
    I didn't state my personal opinion above, but yes I have seen leetcode aptitude to positively correlate with day-to-day problem solving.
    - xandrius 2y ago
      If your company uses leetcode to filter out employees then you are a leetcode team with your internal levels and ranks, not at all representative of the whole population of skilled IT people.
      - deleted 2y ago
        [deleted]
      - josephg 2y ago
        How would you, or anyone, know if your career is representative of the field? I’m sure plenty of people spend their career never learning or using data structures and algorithms knowledge. But I suspect plenty of people spend their career using this stuff all the time. Eg people who work in databases, compilers, operating systems, video games, ai, crypto currencies, and so on.
devbent 2y ago
>I still don't get why such questions are even asked as most jobs I've ever had not even remotely touched those and I've touched quite a few industries, technologies and types of companies. I've had to work on tree traversal stuff multiple times in my life, anything low level GUI related will work with trees a ton. I've also had to work with hash tables directly, and with memory caching layers. I really should learn to write a proper parser, as I've had to write parsers multiple times now and they are always an ugly hack job.
- josephg 2y ago
  Yep. In a project I’m working on at the moment (collab text editing), I’ve implemented 2 different b-trees, a skip list, 2 custom file formats and a dozen or so algorithms which do various graph traversals. I get that this is uncommon, but if you scratch beneath the surface, most software (browsers, databases, compilers, OSes) are full of this stuff. Even while I was consulting stuff like this would come up. At one company we were using a custom graphql wrapper around a CMS, and it was missing some functions we needed. The wrapper was implemented like a compiler from the cms’s data format to a set of query functions. Fixing it to do what we needed it to do was really hard and broke my brain a bit. But I did it. And I wouldn’t have been able to without understanding compilers and algorithms. You can spend your whole career walking the beaten path adding features to apps and websites, and never traversing a tree at all. There’s lots of work like that out there. But if you ever want to go deeper, you’ve gotta understand data structures and algorithms. I know not everyone is suited to it, and that’s fine. But there’s definitely a reason big tech asks about this stuff.
  - sanderjd 2y ago
    > But if you ever want to go deeper, you’ve gotta understand data structures and algorithms. I don't think this is quite right. I think it's more like: If you ever want to go deeper, you've gotta be able to recognize when the problem you're solving fits a pattern for which good data structures and/or algorithms exist, and you've gotta be able to find, understand, and apply good reference material. Solving this "knowing what you don't know" problem is the best and most important role of formal education, in my opinion. It's not as important to know a topic as it is to know that it exists, and some of the basic terminology necessary to get started researching it further.
whstl 2y ago
I disagree with some of this. At some of my past jobs and the current one, this kind of algorithmic knowledge was important to build features that were differentiators in the market. As much as people love to pretend, not every single possible solution is in a library. Sometimes you're the one building the library. It doesn't have to be leetcode, but candidates should at least be able to produce some code that doesn't come from the README of their favourite framework. Also, talking for 30/45 mins can be enough, but it produces false positives when you have people coaching candidates. I've had people completely acing interviews that it felt like the perfect candidate. Well, it was rehearsed. When I asked for a fizz-buzz type question they completely messed it up.
- emseetech 2y ago
  | this kind of algorithmic knowledge was important to build features that were differentiators in the market I agree with this, but with the caveat that it's extremely rare to come up with a truly novel algorithm in a production environment. Those almost always come out of academia or R&D departments. So is it important that people remember how to implement algorithms from scratch? Or is it important that they know when to identify when an existing algorithm would be useful? For instance, if I see that something is suspiciously like a Stable Marriage Problem, do I need to remember how to implement the Gale–Shapley algorithm? Or is just the ability to recognize the problem as something that has a particular solution 90% of the way there? I would argue yes. That said, I'm not sure how to test this is an interview setting.
  - whstl 2y ago
    You don't need something "truly novel" to have a market advantage. Far from it. You just need something that is not ready made. Remember that not every algorithm is neatly package-able, or has a cool name like "Stable Marriage Problem" or "Levenshtein Distance". Also: maybe your advantage is implementing some of those in a new language. Maybe your advantage is implementing one of those in SQL! Maybe you have a tree-like or graph-like structure, and you need to do something with it without having to export into some format expected by certain packages. Knowing what to implement is important too. Also, those interviews are often testing for something even simpler than those fancy algorithms. Nobody uses Fizz Buzz or Recursive Fibonacci daily, but you might need to implement something that is beyond creating views/models/controllers in your favourite MVC framework. This is what the test is checking for: coding beyond what's on the README of your framework.
godelski 2y ago
> if a senior person can't in 30/45 min of talking with someone figure out the general experience level then the problem is them, really. This is why I've always been so confused. Why is the software engineering interview wildly different from the traditional engineering interview (seniors sit down with candidates and discuss how to solve a relevant proxy problem the team is currently undergoing (has the side benefit of making the interview process potentially fruitful if you don't go with that candidate. This can be (and sometimes is) abused though)). I mean... we all speak the same language, and that isn't standard English... right?
- deleted 2y ago
  [deleted]
- markwkw 2y ago
  Mechanical engineering interviews seem to do the same as software: "Engineers always ask about beam bending, stress strain curves, and conservation of work. Know the theory and any technical questions are easy." Basically an equivalent of simple algorithmic questions. Not "real" because it's impossible to share enough context of a real problem in an interview to make it practical. Short, testing principles, but most importantly basic thinking and problem solving facilities.
  - godelski 2y ago
    > Mechanical engineering interviews seem to do the same as software: I've been an engineer in the past (physics undergrad -> aerospace job -> grad school/ml). I have never seen or heard of an engineer being expected to solve math equations on a whiteboard during an interview. It is expected that you already know these things. Honestly, it is expected that you have a reference to these equations and you'll have memorized what you do most. As an example, I got a call when I was finishing my undergrad for a job from Raytheon. I was supposedly the only undergrad being interviewed but first interview was a phone interview. I got asked an optics question and I said to the interviewer "you mind if I grab my book? I have it right next to me and I bookmarked that equation thinking you might ask and I'm blanking on the coefficients (explain form of equation while opening book)". He was super cool with that and at the end of the interview said I was on his short list. I see no problem with this method. We live in the age of the internet. You shouldn't be memorizing a bunch of stuff purposefully, you should be memorizing by accident (aka through routine usage). You should know the abstractions and core concepts but the details are not worth knowing off the top of your head (obviously you should have known at some point) unless you are actively using them.
lmm 2y ago
> Also if a senior person can't in 30/45 min of talking with someone figure out the general experience level then the problem is them, really. OK take it as read that your posturing has succeeded and we all agree that you're a brilliant interpersonal genius and the rest of us are all useless chumps. What then? The rest of us still need to interview and make hiring recommendations. Or are you suggesting that employers should fire anyone who lacks your magical talent?
- xandrius 2y ago
  Why would you read that? I just mean that if you put 2 experienced people talking about a topic they both know, it should be pretty easy for both (or at least the interviewer) to get a rough understanding of the level of the interviewee.
  - lmm 2y ago
    > I just mean that if you put 2 experienced people talking about a topic they both know, it should be pretty easy for both (or at least the interviewer) to get a rough understanding of the level of the interviewee. Well, in my experience it's not, at least not in a "hostile" context. Most technical people are used to assuming good faith in technical conversations, and there are some very smooth bullshitters around; it's easy to construct a verbal facade that only falls apart once you ask someone to actually code.
    - MichaelZuo 2y ago
      Anyone who can't see through the 'verbal facade' is not that good. They may be very smart, but not at a bonafide genius level.
  - baobabKoodaa 2y ago
    It's not. You will find plenty of examples in this very thread.
dennis_jeeves2 2y ago
> Also if a senior person can't in 30/45 min of talking with someone figure out the general experience level then the problem is them, really. Actually most of them, including the really inexperienced juniors have 'figured' you out in less that 15 minutes, or at least they have decided whether to hire you or not in 15 minutes. But they have to put on a charade of being fair. Also a 'white' older male is the least preferred even if he is smarter compared to all females and the minorities that are being interviewed as long as they are not terrible. Biases galore.
- wanderlust123 2y ago
  Got any evidence for the following claim: “ Also a 'white' older male is the least preferred even if he is smarter compared to all females and the minorities that are being interviewed as long as they are not terrible. Biases galore.”
  - renewiltord 2y ago
    He's close. The real bias is against extremely good looking guys named Rene who are also way smarter and charismatic than everyone else. Terrible bias.
    - phlakaton 2y ago
      I dunno. "Rene" sounds a lot like "renege." Which probably means you'll sign on to a project and abandon it halfway through or something. Very sus. (I wish I could say my early interviewing rubrics were any better than this. We have come a long way as a people, we Silly Valley programmers.)
    - Aeolun 2y ago
      That kinda makes sense, unless you want Rene to be your replacement.
  - spacebanana7 2y ago
    Isn't that the definition of affirmative action? Which most companies claim to do (e.g Google [1]). Admittedly Google also claims not to discriminate on the basis of protected characteristics, which is somewhat contradictory to the definition of affirmative action as positive discrimination [2]. [1] https://www.google.com/about/careers/applications/eeo/ https://www.google.com/about/careers/applications/eeo/ [2] https://en.wikipedia.org/wiki/Affirmative_action https://en.wikipedia.org/wiki/Affirmative_action
OJFord 2y ago
> Also if a senior person can't in 30/45 min of talking with someone figure out the general experience level then the problem is them, really. Or it's not their call, theirs is just to work with them after.
wasteduniverse 2y ago
[dead]

hintymad 2y ago

Personally I think such questions have three values: - Future proof. Unless I work for an outsourcing company, sooner or later I will want to push the envelope, or so I hope I do. And to push the envelop, one needs good CS fundamentals (maybe there are some exceptions in some specialized field). Think about React. It's a JS framework, yet to invent it one needs to understand at least compiler and graph. - Geekiness/talent filter. The same reason that the nascent Google and Microsoft and any elite companies like Jane Street asked Putnam questions, Martin Gardner questions, ICPC questions, and clever probability puzzles. Whether it's a good idea is debatable, but at least those companies want to have such type of people and they were hugely successful. Note the word filter: people who pass the interview may not be good, but failing the interview means the candidate may not be smart or geeky enough. Again, I'm not endorsing the idea but just exploring the motivation of the interview policies. - Information density. Assuming a company does want to time box a coding interview in an hour, it will be hard to come up with realistic question without spending too much time on the context. On the other hand, it's relatively easy to come up with a data structure/algorithm question that packs enough number of abstractions and inspection points to examine one's programming skill.

davidw 2y ago
> Think about React. It's a JS framework, yet to invent it one needs to understand at least compiler and graph. Are you hiring people to create new JS frameworks, or to use an existing one?
- paulddraper 2y ago
  To use an existing one. And tools are best used when they are understood.
  - davidw 2y ago
    Hiring, like many things - including engineering - is about tradeoffs. Is someone more knowledgeable "better"? Sure. But sometimes it's about getting a specific thing done, and if you're hiring someone to improve a web thing that uses React, maybe you don't need someone who understands compilers and the kernel and how the underlying hardware works and all that. Maybe you can spend a bit less and get someone who will do a perfectly adequate job.
  - bjablonski 2y ago
    How many react developers understands compilers & graphs? I'd wager that it's way below 10%.
    - mewpmewp2 2y ago
      Also why do you need knowledge on compilers and graphs to create React? Firstly, React is not compiled. Secondly the graph or tree or whichever aspect can come naturally when you come up with the idea of how it would be best to maintain JS apps. In fact most important experience should have been grinding put tons of unmaintainable JS apps to come up with something like that.
    - paulddraper 2y ago
      I wouldn't argue with that.
  - Paul-Craft 2y ago
    I don't know anything about quantum mechanics. Does that mean I don't understand how computers work?
    - paulddraper 2y ago

paulddraper 2y ago

> I still don't get why such questions are even asked The thesis is not that these exercises are representative of work but rather predictive of performance. Sales has a similar phenomenon with sports. While there is no athleticism involved in selling, many believe history in competitive sports to be a positive predictor of sales success. --- You can reasonably argue whether leetcode accomplishes this well or poorly, but... Always remember that purpose of an interview (for an employer) is to predict performance. So you are looking for the resume screening+interview process that most accurately assesses that.

xandrius 2y ago
So you're saying that someone wasting their time studying leetcode to pass a stupid game is a good indicator? I would almost believe the opposite: if you actually pass those tests with flying colours, it shows me that you believe you needed to do that to be hired, while someone who's actually experienced would never in a million years step down so low.
- paulddraper 2y ago
  I didn't state my personal opinion above, but yes I have seen leetcode aptitude to positively correlate with day-to-day problem solving.
  - xandrius 2y ago
    If your company uses leetcode to filter out employees then you are a leetcode team with your internal levels and ranks, not at all representative of the whole population of skilled IT people.
    - deleted 2y ago
      [deleted]
    - josephg 2y ago
      How would you, or anyone, know if your career is representative of the field? I’m sure plenty of people spend their career never learning or using data structures and algorithms knowledge. But I suspect plenty of people spend their career using this stuff all the time. Eg people who work in databases, compilers, operating systems, video games, ai, crypto currencies, and so on.

devbent 2y ago

>I still don't get why such questions are even asked as most jobs I've ever had not even remotely touched those and I've touched quite a few industries, technologies and types of companies. I've had to work on tree traversal stuff multiple times in my life, anything low level GUI related will work with trees a ton. I've also had to work with hash tables directly, and with memory caching layers. I really should learn to write a proper parser, as I've had to write parsers multiple times now and they are always an ugly hack job.

josephg 2y ago
Yep. In a project I’m working on at the moment (collab text editing), I’ve implemented 2 different b-trees, a skip list, 2 custom file formats and a dozen or so algorithms which do various graph traversals. I get that this is uncommon, but if you scratch beneath the surface, most software (browsers, databases, compilers, OSes) are full of this stuff. Even while I was consulting stuff like this would come up. At one company we were using a custom graphql wrapper around a CMS, and it was missing some functions we needed. The wrapper was implemented like a compiler from the cms’s data format to a set of query functions. Fixing it to do what we needed it to do was really hard and broke my brain a bit. But I did it. And I wouldn’t have been able to without understanding compilers and algorithms. You can spend your whole career walking the beaten path adding features to apps and websites, and never traversing a tree at all. There’s lots of work like that out there. But if you ever want to go deeper, you’ve gotta understand data structures and algorithms. I know not everyone is suited to it, and that’s fine. But there’s definitely a reason big tech asks about this stuff.
- sanderjd 2y ago
  > But if you ever want to go deeper, you’ve gotta understand data structures and algorithms. I don't think this is quite right. I think it's more like: If you ever want to go deeper, you've gotta be able to recognize when the problem you're solving fits a pattern for which good data structures and/or algorithms exist, and you've gotta be able to find, understand, and apply good reference material. Solving this "knowing what you don't know" problem is the best and most important role of formal education, in my opinion. It's not as important to know a topic as it is to know that it exists, and some of the basic terminology necessary to get started researching it further.

whstl 2y ago

I disagree with some of this. At some of my past jobs and the current one, this kind of algorithmic knowledge was important to build features that were differentiators in the market. As much as people love to pretend, not every single possible solution is in a library. Sometimes you're the one building the library. It doesn't have to be leetcode, but candidates should at least be able to produce some code that doesn't come from the README of their favourite framework. Also, talking for 30/45 mins can be enough, but it produces false positives when you have people coaching candidates. I've had people completely acing interviews that it felt like the perfect candidate. Well, it was rehearsed. When I asked for a fizz-buzz type question they completely messed it up.

emseetech 2y ago
| this kind of algorithmic knowledge was important to build features that were differentiators in the market I agree with this, but with the caveat that it's extremely rare to come up with a truly novel algorithm in a production environment. Those almost always come out of academia or R&D departments. So is it important that people remember how to implement algorithms from scratch? Or is it important that they know when to identify when an existing algorithm would be useful? For instance, if I see that something is suspiciously like a Stable Marriage Problem, do I need to remember how to implement the Gale–Shapley algorithm? Or is just the ability to recognize the problem as something that has a particular solution 90% of the way there? I would argue yes. That said, I'm not sure how to test this is an interview setting.
- whstl 2y ago
  You don't need something "truly novel" to have a market advantage. Far from it. You just need something that is not ready made. Remember that not every algorithm is neatly package-able, or has a cool name like "Stable Marriage Problem" or "Levenshtein Distance". Also: maybe your advantage is implementing some of those in a new language. Maybe your advantage is implementing one of those in SQL! Maybe you have a tree-like or graph-like structure, and you need to do something with it without having to export into some format expected by certain packages. Knowing what to implement is important too. Also, those interviews are often testing for something even simpler than those fancy algorithms. Nobody uses Fizz Buzz or Recursive Fibonacci daily, but you might need to implement something that is beyond creating views/models/controllers in your favourite MVC framework. This is what the test is checking for: coding beyond what's on the README of your framework.

godelski 2y ago

> if a senior person can't in 30/45 min of talking with someone figure out the general experience level then the problem is them, really. This is why I've always been so confused. Why is the software engineering interview wildly different from the traditional engineering interview (seniors sit down with candidates and discuss how to solve a relevant proxy problem the team is currently undergoing (has the side benefit of making the interview process potentially fruitful if you don't go with that candidate. This can be (and sometimes is) abused though)). I mean... we all speak the same language, and that isn't standard English... right?

deleted 2y ago
[deleted]
markwkw 2y ago
Mechanical engineering interviews seem to do the same as software: "Engineers always ask about beam bending, stress strain curves, and conservation of work. Know the theory and any technical questions are easy." Basically an equivalent of simple algorithmic questions. Not "real" because it's impossible to share enough context of a real problem in an interview to make it practical. Short, testing principles, but most importantly basic thinking and problem solving facilities.
- godelski 2y ago
  > Mechanical engineering interviews seem to do the same as software: I've been an engineer in the past (physics undergrad -> aerospace job -> grad school/ml). I have never seen or heard of an engineer being expected to solve math equations on a whiteboard during an interview. It is expected that you already know these things. Honestly, it is expected that you have a reference to these equations and you'll have memorized what you do most. As an example, I got a call when I was finishing my undergrad for a job from Raytheon. I was supposedly the only undergrad being interviewed but first interview was a phone interview. I got asked an optics question and I said to the interviewer "you mind if I grab my book? I have it right next to me and I bookmarked that equation thinking you might ask and I'm blanking on the coefficients (explain form of equation while opening book)". He was super cool with that and at the end of the interview said I was on his short list. I see no problem with this method. We live in the age of the internet. You shouldn't be memorizing a bunch of stuff purposefully, you should be memorizing by accident (aka through routine usage). You should know the abstractions and core concepts but the details are not worth knowing off the top of your head (obviously you should have known at some point) unless you are actively using them.

lmm 2y ago

> Also if a senior person can't in 30/45 min of talking with someone figure out the general experience level then the problem is them, really. OK take it as read that your posturing has succeeded and we all agree that you're a brilliant interpersonal genius and the rest of us are all useless chumps. What then? The rest of us still need to interview and make hiring recommendations. Or are you suggesting that employers should fire anyone who lacks your magical talent?

xandrius 2y ago
Why would you read that? I just mean that if you put 2 experienced people talking about a topic they both know, it should be pretty easy for both (or at least the interviewer) to get a rough understanding of the level of the interviewee.
- lmm 2y ago
  > I just mean that if you put 2 experienced people talking about a topic they both know, it should be pretty easy for both (or at least the interviewer) to get a rough understanding of the level of the interviewee. Well, in my experience it's not, at least not in a "hostile" context. Most technical people are used to assuming good faith in technical conversations, and there are some very smooth bullshitters around; it's easy to construct a verbal facade that only falls apart once you ask someone to actually code.
  - MichaelZuo 2y ago
    Anyone who can't see through the 'verbal facade' is not that good. They may be very smart, but not at a bonafide genius level.
- baobabKoodaa 2y ago
  It's not. You will find plenty of examples in this very thread.

dennis_jeeves2 2y ago

> Also if a senior person can't in 30/45 min of talking with someone figure out the general experience level then the problem is them, really. Actually most of them, including the really inexperienced juniors have 'figured' you out in less that 15 minutes, or at least they have decided whether to hire you or not in 15 minutes. But they have to put on a charade of being fair. Also a 'white' older male is the least preferred even if he is smarter compared to all females and the minorities that are being interviewed as long as they are not terrible. Biases galore.

wanderlust123 2y ago
Got any evidence for the following claim: “ Also a 'white' older male is the least preferred even if he is smarter compared to all females and the minorities that are being interviewed as long as they are not terrible. Biases galore.”
- renewiltord 2y ago
  He's close. The real bias is against extremely good looking guys named Rene who are also way smarter and charismatic than everyone else. Terrible bias.
  - phlakaton 2y ago
    I dunno. "Rene" sounds a lot like "renege." Which probably means you'll sign on to a project and abandon it halfway through or something. Very sus. (I wish I could say my early interviewing rubrics were any better than this. We have come a long way as a people, we Silly Valley programmers.)
  - Aeolun 2y ago
    That kinda makes sense, unless you want Rene to be your replacement.
- spacebanana7 2y ago
  Isn't that the definition of affirmative action? Which most companies claim to do (e.g Google [1]). Admittedly Google also claims not to discriminate on the basis of protected characteristics, which is somewhat contradictory to the definition of affirmative action as positive discrimination [2]. [1] https://www.google.com/about/careers/applications/eeo/ https://www.google.com/about/careers/applications/eeo/ [2] https://en.wikipedia.org/wiki/Affirmative_action https://en.wikipedia.org/wiki/Affirmative_action

OJFord 2y ago

> Also if a senior person can't in 30/45 min of talking with someone figure out the general experience level then the problem is them, really. Or it's not their call, theirs is just to work with them after.

wasteduniverse 2y ago

[dead]