5 ms·

> because credentials and experience often mean nothing, resume fraud is rampant Problem is, it's even easier to game the system by just memorizing LC question

> because credentials and experience often mean nothing, resume fraud is rampant Problem is, it's even easier to game the system by just memorizing LC questions. A metric that is known to be relevant beforehand and can be tackled by "learning for the test" is an almost surefire way of ensuring that a lot of people will do exactly that. There is an entire industry to prepare people for these tests, same as there is for standardized MC tests in eductional systems that rely on them. It's not easy to detect resume fraud. But it's even harder to determine whether someone actually knows his stuff, or just spend time (and sometimes money) on just memorizing a lot of questions. > If there was a better way There is: Talking to people. Actually doing interviews. https://www.linkedin.com/pulse/why-interview-coding-tests-moronic-brain-dead-stupid-asinine-briggs https://www.linkedin.com/pulse/why-interview-coding-tests-mo...

twblalock 5y ago
It's not like we don't talk to people. We do that too. Most interviews I've been a part of, on either side of the table, have involved coding questions, design questions, and conversation. However, to get to that point you need to get past the phone screen and that's usually a coding exercise. I'm not mad about that because I have seen firsthand that companies need to filter out all the ridiculously unqualified people who come their way, to ensure that time spent on interviewing (including conversation) is not wasted. If you list a decent software job right now you will get hundreds, maybe even thousands, of applicants. Many will be outright liars, many will be junior people pretending to be senior, and many will be very good. You can't spend time on all of them. You need to have a way to decide who is worth your time, or you'll never have time to do anything else.
- usrbinbash 5y ago
  > You need to have a way to decide who is worth your time The "first filter" is what we have HR departments for. As you say, decent jobs get thousands of applicants. Whos going to do the phone interview on a thousand people? The first filter is skimming the applications and checking basic credentials. Filter out resumes that don't check out, and looking for red flags. This already brings down the candidate pool to a manageable size.
  - dnissley 5y ago
    There are lots of talented people in our industry who don't have formal credentials. We're kind of known for that. So if you insist on credentialism you risk eliminating a significant number of perfectly fine candidates.
    - usrbinbash 5y ago
      I am absolutely aware of that. I used "credentials" in the above post in a very broad sense of the word, because "something that shows on paper that you know how to program" is a bit of a handful to type. Work Experience, Involvement in projects, a degree, a github link, code-camp certificate, reference to prior training, all of these can be credentials. The better the position, the better whatever someone puts in needs to be in Order to consider the candidate. If it's a beginners position even a short paragraph about when, how and why someone started self-teaching would be acceptable, if I am looking for a senior database engineer I want to see more. Writing something tangible in a resume about ones skills is a prerequisite. If a candidate doesn't do that, his application is eliminated before it even gets past the desk of the first HR person. This is not "credentialism", it's normal procedure for basically every single job-that-requires-some-form-of-expertise on the planet. "credentialism" would be to only consider candidates with, say, a CS degree. That would be bad in our industry, for the exact reason you outlined.
      - dnissley 5y ago
        The problem is "something that shows on paper that you know how to program" is so easy to fake that this amounts to basically no filter at all. Literally anyone could go on linked in and copy+paste blurbs from other people's job histories and nobody would know the difference between them and a viable candidate.
        usrbinbash 5y ago
        The thing is, in smaller companies, where there are few applicants, this can be solved by interviewing people (as in "talking to them", not with LC puzzles which can just be memorized). In larger companies, and for well paid positions, where there can be hundreds of applicants for each job, that just isn't feasible, so HR has no choice but to apply some sort of filtering.
visarga 5y ago
> just memorizing a lot of questions If you can implement one of the memorised solutions on the spot, with tweaks, then you're probably good.
- usrbinbash 5y ago
  Good at what? If I memorized how certain classes of problems are solved, and can derive an implementation from that, then yes, I am probably a good coder. I am then also someone who used LC et al. to learn about data structures and algorithms, aka. what these puzzles were originally intended to help people with. If I memorized the question and its solution however, without understanding why and how this solution works then I am merely good at memorizing text and replaying it. This doesn't demonstrate my ability to solve problems or to code.
  - visarga 5y ago
    You won't be able to implement it from memory if you didn't grock it.
    - usrbinbash 5y ago
      I am not implementing them "from memory". If I know the principle of, say, a B-Tree, and I know how to program in language Blub, then all I have to do is translate the principle into code. It's the same with translating a concept into natural language. I have not memorized the word-by-word explanation of how the JW-Telescope deploys. I have an image of the process in my mind, so if someone wants an explanation, I translate that principle into english dynamically.

twblalock 5y ago

It's not like we don't talk to people. We do that too. Most interviews I've been a part of, on either side of the table, have involved coding questions, design questions, and conversation. However, to get to that point you need to get past the phone screen and that's usually a coding exercise. I'm not mad about that because I have seen firsthand that companies need to filter out all the ridiculously unqualified people who come their way, to ensure that time spent on interviewing (including conversation) is not wasted. If you list a decent software job right now you will get hundreds, maybe even thousands, of applicants. Many will be outright liars, many will be junior people pretending to be senior, and many will be very good. You can't spend time on all of them. You need to have a way to decide who is worth your time, or you'll never have time to do anything else.

usrbinbash 5y ago
> You need to have a way to decide who is worth your time The "first filter" is what we have HR departments for. As you say, decent jobs get thousands of applicants. Whos going to do the phone interview on a thousand people? The first filter is skimming the applications and checking basic credentials. Filter out resumes that don't check out, and looking for red flags. This already brings down the candidate pool to a manageable size.
- dnissley 5y ago
  There are lots of talented people in our industry who don't have formal credentials. We're kind of known for that. So if you insist on credentialism you risk eliminating a significant number of perfectly fine candidates.
  - usrbinbash 5y ago
    I am absolutely aware of that. I used "credentials" in the above post in a very broad sense of the word, because "something that shows on paper that you know how to program" is a bit of a handful to type. Work Experience, Involvement in projects, a degree, a github link, code-camp certificate, reference to prior training, all of these can be credentials. The better the position, the better whatever someone puts in needs to be in Order to consider the candidate. If it's a beginners position even a short paragraph about when, how and why someone started self-teaching would be acceptable, if I am looking for a senior database engineer I want to see more. Writing something tangible in a resume about ones skills is a prerequisite. If a candidate doesn't do that, his application is eliminated before it even gets past the desk of the first HR person. This is not "credentialism", it's normal procedure for basically every single job-that-requires-some-form-of-expertise on the planet. "credentialism" would be to only consider candidates with, say, a CS degree. That would be bad in our industry, for the exact reason you outlined.
    - dnissley 5y ago
      The problem is "something that shows on paper that you know how to program" is so easy to fake that this amounts to basically no filter at all. Literally anyone could go on linked in and copy+paste blurbs from other people's job histories and nobody would know the difference between them and a viable candidate.
      - usrbinbash 5y ago
        The thing is, in smaller companies, where there are few applicants, this can be solved by interviewing people (as in "talking to them", not with LC puzzles which can just be memorized). In larger companies, and for well paid positions, where there can be hundreds of applicants for each job, that just isn't feasible, so HR has no choice but to apply some sort of filtering.

visarga 5y ago

> just memorizing a lot of questions If you can implement one of the memorised solutions on the spot, with tweaks, then you're probably good.

usrbinbash 5y ago
Good at what? If I memorized how certain classes of problems are solved, and can derive an implementation from that, then yes, I am probably a good coder. I am then also someone who used LC et al. to learn about data structures and algorithms, aka. what these puzzles were originally intended to help people with. If I memorized the question and its solution however, without understanding why and how this solution works then I am merely good at memorizing text and replaying it. This doesn't demonstrate my ability to solve problems or to code.
- visarga 5y ago
  You won't be able to implement it from memory if you didn't grock it.
  - usrbinbash 5y ago
    I am not implementing them "from memory". If I know the principle of, say, a B-Tree, and I know how to program in language Blub, then all I have to do is translate the principle into code. It's the same with translating a concept into natural language. I have not memorized the word-by-word explanation of how the JW-Telescope deploys. I have an image of the process in my mind, so if someone wants an explanation, I translate that principle into english dynamically.