4 ms·

It is definitely about the coding skills. It is too easy to bullshit and there is a financial incentive to do so. Also many people with genunine 10 years of exp

It is definitely about the coding skills. It is too easy to bullshit and there is a financial incentive to do so. Also many people with genunine 10 years of experience are not too good at coding.

pkolaczk 4y ago
It's is also easy to bullshit a coding interview. The problems solved at interviews are just too small to verify code organization skills.
- koonsolo 4y ago
  I suppose you never did any interviews yourself. You can't imagine how many people can't even do or know the basics.
  - ipaddr 4y ago
    Yet they are able to do the job. Something doesn't lineup with your testing methods vs outcome. If these people are finding work elsewhere and doing productive work for years what does it say about your process?
    - koonsolo 4y ago
      Do you think they are looking for a job because they were fired somewhere else? Or do you think companies never fire people? We already fired plenty of people that we hired. So yes, our hiring process is not perfect. But if you're a JavaScript developer and can't explain the difference between var, let and const, I'm not going to hire you. If you claim these people are great developers, you are free to hire them. Let me know the details of your company. Whenever we find a candidate that doesn't satisfy our requirements (which is around 90% of them), I'll send them to you so you can hire them.
      - pkolaczk 4y ago
        I've never said you should hire people who can't tell var from const. I've said that even if you hire people who do know the basics of the language, and some algorithms, and even could solve a toy problem on paper, you might still hire someone who can't code at scale. Coding interviews typically don't test design skills, documentation skills, ability to not get lost on a larger code base, debugging skills, tendency to avoid hacks and increase tech debt etc.
      - ipaddr 4y ago
        Those are different skill sets. Someone may know and know how to properly use var, let and const according to standards and current trends. They may understand it deeply. But that doesn't mean that they can explain it to you. The question changes to: is what you are testing the actual skill you need? Are you hiring a teacher who is going to explain var,let,const as part of their job or are you hiring someone who needs to know how properly to use var,let,const? Send me over any developer who fails your teaching requirements for var,let,const but has code samples with proper usage. I've never seen a senior developer fired for poor coding. I've seen them get fired for being part of a department cut or because they got into a fight with the owner/boss. I've seen them fired because they make too much compared to outsourced resources.
        koonsolo 4y ago
        > that doesn't mean that they can explain it to you. I'm sorry what? I don't expect them to teach me, I just want them to tell the difference. By the way, the ones that can't say: "they told me to always use let". I'll send them to you :D. Best of luck. > I've never seen a senior developer fired for poor coding. I've seen plenty. If a junior dev needs to help you out of trouble every time, you know there is something wrong. Some people just reach their limit very soon, and can hide away in some comppanies. Probaly companies where you seem to work. Other companies probably just have a higher bar, no disrespect meant.
        Cd00d 4y ago
        Look. I've seen a lot of your comments in this thread, and I don't think you're listening. You don't seem open to hearing. What I read is a knee jerk justification for your hiring methodology without being open to any feedback. You should take a breath. Clearly people disagree with you. Try to empathize with where they're coming from and understand the point they're trying to make.
  - lapcat 4y ago
    > You can't imagine how many people can't even do or know the basics. I can imagine it, because I've been that person. It's simple interview anxiety, which causes temporary but severe performance degradation. Then when the interview is over, the anxiety suddenly disappears, and you can even go back and do the same problems much more easily. But I suppose interviewers will just assume that my resume is a lie or that I managed to incompetently hold onto previous jobs.
amitport 4y ago
Many people with genuine 10 years of experience do not care for stupid leetcode question they could obviously solve given some quiet and time. The idea that everything boils down to answering some intro to programming questions quickly is absurd.
- kortilla 4y ago
  Years of experience are not created equal. There are far fewer who can actually solve them but don’t want to than those who just can’t. If you spent the last 10 years just ossifying then you might be great in your current role but realistically you’re terrible at building new things.
- kingdomcome50 4y ago
  While providing a syntactically correct, optimal solution to a given problem is important (this was reiterated many times during my recent interview process at a FAANG), it is also important to be able to demonstrate the ability to synthesize an approach to solving a problem to which you don't already know the answer. That is, how to solve a problem. These questions, while certainly aimed at identifying core competency areas, are also an opportunity for the candidate to demonstrate an aptitude for problem solving. Nobody really cares "how many piano tuners operate in Seattle". What they care about is, given that kind of question, how a candidate responds. You might be surprised by the number of people totally unable to even generate a reasonable estimate: - How many people live in Seattle? - What percentage have pianos? - How often does a piano need tuning? - How long does it take to tune a piano? - How many pianos can be tuned per work day (given commuting time)? - etc.. driving towards a number. Did the candidate attack the problem and even attempt to solve it? Did they use metrics? The list goes on... Most LC-style questions (save the "aha! moment" ones) have a similar impetus, but are also much more practical and efficient because they test for many things at once. And if I'm being honest... most FAANGs aren't looking for engineers that require quiet and time to solve problems. They are looking for elite engineers who can write a solution nearly as fast as the problem is presented (I'm obviously exaggerating a little bit here). The difficulty of the questions presented to me (6 technical interviews) were what I consider semi-trivial. I was able to describe the solution-space within seconds of reading the prompt and code an optimal solution nearly as fast as I could type in all cases. It honestly made me wonder about how poorly the average programmer must perform such that these were the questions they needed to evaluate my potential. Another commenter posted this article [0] about the interviewing philosophy back in the early '00s. I found it very enlightening, and reassuringly, while reading through it I knew the answer to nearly every question (and could expand upon the topics) just off the top of my head. I'm not trying to sound arrogant here but the idea that a FAANG, who pays top-dollar for engineers, would settle for "10 years experience" as a suitable replacement for "demonstrates ability" is what's absurd. A false positive is way more costly than a false negative. [0] https://sites.google.com/site/steveyegge2/five-essential-phone-screen-questions https://sites.google.com/site/steveyegge2/five-essential-pho...

It is definitely about the coding skills. It is too easy to bullshit and there is a financial incentive to do so. Also many people with genunine 10 years of experience are not too good at coding.

pkolaczk 4y ago

It's is also easy to bullshit a coding interview. The problems solved at interviews are just too small to verify code organization skills.

koonsolo 4y ago
I suppose you never did any interviews yourself. You can't imagine how many people can't even do or know the basics.
- ipaddr 4y ago
  Yet they are able to do the job. Something doesn't lineup with your testing methods vs outcome. If these people are finding work elsewhere and doing productive work for years what does it say about your process?
  - koonsolo 4y ago
    Do you think they are looking for a job because they were fired somewhere else? Or do you think companies never fire people? We already fired plenty of people that we hired. So yes, our hiring process is not perfect. But if you're a JavaScript developer and can't explain the difference between var, let and const, I'm not going to hire you. If you claim these people are great developers, you are free to hire them. Let me know the details of your company. Whenever we find a candidate that doesn't satisfy our requirements (which is around 90% of them), I'll send them to you so you can hire them.
    - pkolaczk 4y ago
      I've never said you should hire people who can't tell var from const. I've said that even if you hire people who do know the basics of the language, and some algorithms, and even could solve a toy problem on paper, you might still hire someone who can't code at scale. Coding interviews typically don't test design skills, documentation skills, ability to not get lost on a larger code base, debugging skills, tendency to avoid hacks and increase tech debt etc.
    - ipaddr 4y ago
      Those are different skill sets. Someone may know and know how to properly use var, let and const according to standards and current trends. They may understand it deeply. But that doesn't mean that they can explain it to you. The question changes to: is what you are testing the actual skill you need? Are you hiring a teacher who is going to explain var,let,const as part of their job or are you hiring someone who needs to know how properly to use var,let,const? Send me over any developer who fails your teaching requirements for var,let,const but has code samples with proper usage. I've never seen a senior developer fired for poor coding. I've seen them get fired for being part of a department cut or because they got into a fight with the owner/boss. I've seen them fired because they make too much compared to outsourced resources.
      - koonsolo 4y ago
        > that doesn't mean that they can explain it to you. I'm sorry what? I don't expect them to teach me, I just want them to tell the difference. By the way, the ones that can't say: "they told me to always use let". I'll send them to you :D. Best of luck. > I've never seen a senior developer fired for poor coding. I've seen plenty. If a junior dev needs to help you out of trouble every time, you know there is something wrong. Some people just reach their limit very soon, and can hide away in some comppanies. Probaly companies where you seem to work. Other companies probably just have a higher bar, no disrespect meant.
        Cd00d 4y ago
        Look. I've seen a lot of your comments in this thread, and I don't think you're listening. You don't seem open to hearing. What I read is a knee jerk justification for your hiring methodology without being open to any feedback. You should take a breath. Clearly people disagree with you. Try to empathize with where they're coming from and understand the point they're trying to make.
- lapcat 4y ago
  > You can't imagine how many people can't even do or know the basics. I can imagine it, because I've been that person. It's simple interview anxiety, which causes temporary but severe performance degradation. Then when the interview is over, the anxiety suddenly disappears, and you can even go back and do the same problems much more easily. But I suppose interviewers will just assume that my resume is a lie or that I managed to incompetently hold onto previous jobs.

amitport 4y ago

Many people with genuine 10 years of experience do not care for stupid leetcode question they could obviously solve given some quiet and time. The idea that everything boils down to answering some intro to programming questions quickly is absurd.

kortilla 4y ago
Years of experience are not created equal. There are far fewer who can actually solve them but don’t want to than those who just can’t. If you spent the last 10 years just ossifying then you might be great in your current role but realistically you’re terrible at building new things.
kingdomcome50 4y ago
While providing a syntactically correct, optimal solution to a given problem is important (this was reiterated many times during my recent interview process at a FAANG), it is also important to be able to demonstrate the ability to synthesize an approach to solving a problem to which you don't already know the answer. That is, how to solve a problem. These questions, while certainly aimed at identifying core competency areas, are also an opportunity for the candidate to demonstrate an aptitude for problem solving. Nobody really cares "how many piano tuners operate in Seattle". What they care about is, given that kind of question, how a candidate responds. You might be surprised by the number of people totally unable to even generate a reasonable estimate: - How many people live in Seattle? - What percentage have pianos? - How often does a piano need tuning? - How long does it take to tune a piano? - How many pianos can be tuned per work day (given commuting time)? - etc.. driving towards a number. Did the candidate attack the problem and even attempt to solve it? Did they use metrics? The list goes on... Most LC-style questions (save the "aha! moment" ones) have a similar impetus, but are also much more practical and efficient because they test for many things at once. And if I'm being honest... most FAANGs aren't looking for engineers that require quiet and time to solve problems. They are looking for elite engineers who can write a solution nearly as fast as the problem is presented (I'm obviously exaggerating a little bit here). The difficulty of the questions presented to me (6 technical interviews) were what I consider semi-trivial. I was able to describe the solution-space within seconds of reading the prompt and code an optimal solution nearly as fast as I could type in all cases. It honestly made me wonder about how poorly the average programmer must perform such that these were the questions they needed to evaluate my potential. Another commenter posted this article [0] about the interviewing philosophy back in the early '00s. I found it very enlightening, and reassuringly, while reading through it I knew the answer to nearly every question (and could expand upon the topics) just off the top of my head. I'm not trying to sound arrogant here but the idea that a FAANG, who pays top-dollar for engineers, would settle for "10 years experience" as a suitable replacement for "demonstrates ability" is what's absurd. A false positive is way more costly than a false negative. [0] https://sites.google.com/site/steveyegge2/five-essential-phone-screen-questions https://sites.google.com/site/steveyegge2/five-essential-pho...