15 ms·

The dirty secret is that it’s never about the coding skills. It’s about the person’s behavior, the way he/she interacts with you. It’s about the person’s cultu

• mountainriver 4y ago
  Yup this is true for the most part, although someone bad will be harder to justify. It’s hilarious listening to people review candidates on third coding interviews. Usually it’s “this person didn’t know this one thing I think makes me really smart”. This is why I lean so heavy in OSS to review candidates. I can see how they interact with people, and whether they are actually able to build software that _people want_ I find with this approach it’s a lot harder to justify nonsense. I hear people say maybe they don’t have time for OSS and then hand them a Leetcode interview, which as we all know is just about memorizing problems. OSS is such a better metric and has the added benefit of improving the world.
  • lelanthran 4y ago
    > It’s hilarious listening to people review candidates on third coding interviews. Usually it’s “this person didn’t know this one thing I think makes me really smart”. Yup. I just went through a round of interviews at multiple companies. In the past I successfully interviewed at a FAANG. I agree completely.
  • rvz 4y ago
    > This is why I lean so heavy in OSS to review candidates. I can see how they interact with people, and whether they are actually able to build software that _people want_ This. There is absolutely no need to ask such ridiculous algorithms and advanced equations questions that you will never use or implement from scratch yourself, or asking the candidate to create a formal proof by rote for a entry-level software engineering position or even a senior level position. Such interviewers who ask these questions have both googled the answers to these questions before the interview and also have never used them practically, but only do this to appear smarter than they actually are. Worse part is not even FAANG asks any of these formal proof questions, but only some certain startups that the last time I have checked, they have failed to make money and have shutdown. Why? Because they seriously thought they were a FAANG company. Open-source cuts through the algorithms nonsense, saves time and gets a realistic idea of what the candidate has actually worked on in the open. I can ignore the typical hello world, or demo projects but can ask for if they have created open-source libraries or contributions to any serious projects like compilers, OS projects, or any related project to the job description etc. A take home project is also a fine metric, but asking questions about algorithms and finding out that the interviewer (or the company) doesn't even use them tells you that the interviewer doesn't know what they are looking for.
  • itronitron 4y ago
    https://people.wku.edu/sally.kuhlenschmidt/whimsy/oss/ossstrs.htm https://people.wku.edu/sally.kuhlenschmidt/whimsy/oss/ossstr...
• t-writescode 4y ago
  Statements like this make me distinctly angry because I do everything I can to remove myself from the interview, of sorts. If they come up with, or start walking with an interesting solution, I listen to them. Tabs and spaces don't matter. I actively work against the biases of "whether I like the person or not" because I'm aware of that as a factor. We can absolutely minimize all of those peripherals when we explicitly train against it and a good programming interview doesn't have to be about that.
  • d--b 4y ago
    Well I didn’t mean to offend anyone. I guess that just makes you a better technical interviewer than most. But to be perfectly unbiased, the process would have to double blind. And I don’t know anyone who likes to hire people (or anyone who wants to be hired) following a double blind process. So at least there is _some_ non-technical bias that gets in the process.
• quickthrower2 4y ago
  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.
• weatherlite 4y ago
  > It’s about the person’s behavior, the way he/she interacts with you. It’s about the person’s culture, tabs vs space, and that kind of things. And it’s mostly about whether you like the person or not Not in FAANG or famous startups it's not. You're either gonna solve 3-6 medium hard Leetcode questions perfectly or you're out. Sure, liking you will help you better not come off as a douche - but you're not gonna get an offer without being able to solve (unless it's some kind of a diversity hire).
  • sitkack 4y ago
    Interview technical folks at a FAANG and I don't asking leetcode questions. It isn't a SWE role but people should be SWE material. I do ask them to * read code * extend some working code with a new feature * parse some semi-structured text into a data structure Programming interviews suck for everyone, even the interviewer. I feel absolutely horrible when someone locks up, or fails really hard. The questions I ask aren't hard but half don't pass. What folks should do is practice coding in front of someone. Writing little exploratory snippets and understand the base library of the language they claim to know. I don't even ask people to vocalize while they are working on the problem. And I solve it at the same time they are and if they get stuck, I show them some of my code. I had one person start crying they put so much pressure on themselves, I had to take a two week break from interviewing after that.
    • weatherlite 4y ago
      I was referring to SWE roles, as is this article I believe.
      • sitkack 4y ago
        They aren't technically SWEs but they would be at any other company. I have been a SWE at three other FAANGs
        • weatherlite 4y ago
          > I have been a SWE at three other FAANGs Good for you. Now seriously I'm not sure what you're arguing for - you're saying FAANGS don't do Leetcode style questions? I get it that YOU don't do it to candidates in those roles, but the reality is for SWE roles this is how it is. People who aren't very good in Leetcode will not succeed. There's hundreds, maybe thousands of candidates for these roles and some of them can do the Leetcode thing - they are the ones who get hired. I'm not advocating for this method because I'm not particularly good at it or like solving these things on my spare time, nor do I think this method is particularly useful - but that's reality.
• 1270018080 4y ago
  > The dirty secret is that it’s never about the coding skills. If you don't answer the 2 leetcode mediums in optimal complexity within 45 minutes then you don't pass. It's about coding skills.
  • ipaddr 4y ago
    It's about speed of solving medium leetcode not coding skills.
  • aulin 4y ago
    leetcode is not coding
• koonsolo 4y ago
  > You mainly need to be sure that the person knows what a for loop is, other than that, most people are ok at programming. When I'm interviewing a senior developer that will guide other juniors, they will need to prove they know more than a for loop. They will need to show they understand the underlying concepts and technologies. Else it's a no hire, tough luck. We also fired plenty of people that weren't up to the quality we expect. Were are you working? At some government?
• em-bee 4y ago
  i do sort of pair programming with candidates specifically to evaluate the interaction. i let them drive and navigate, acting more like a passenger with the occasional input. that way i can see coding skills and ability to communicate. of course i interview for my specific situation. the candidate will be working with me directly, so they should at least be able to interact with me. if i don't like them then that's almost a showstopper, but if the candidate otherwise qualifies i should try to figure out what my problem is, and see if i can get over it.
• jordanpg 4y ago
  SWE to lawyer here. The analogs of the traditional coding interview in the law school world are the LSAT and classroom timed memory tests. Both have absolutely nothing whatsoever to do with being a lawyer or the kinds of activities that lawyers actually do. What they are are intelligence tests. They are easy ways for judges and top tier law firms to tell if you are "one of them." You can get your foot in the door if you can perform, at a minimum, at a certain level. There are plenty of things you can do without 97+ percentile LSAT and A's in law school, but you are screened from the top echelon of work. People object that this isn't fair and screens good people out -- false negatives. But experience has shown that it is effective and easy. Perhaps there is a better way, but this way seems to work well enough. There is little incentive, beyond some people complaining about it, to change a system that is working well. I see the traditional leetcode interview in the same light. The point is to see if you can perform at a certain minimal level. Yes, it's arbitrary, and often unconnected to real life. But it is an effective way to gauge a minimum level of intelligence and competence. Not perfect, but easy and effective. Finally, there is ego element to this. People who can perform at this level see these skills as a minimum qualification. They are uncomfortable seeing themselves in relation to others who cannot perform at this level. Knowing that their peers have similar minimum qualifications makes them feel safe and secure about their status. This is not a criticism, just an observation about human nature. People in a club need a shared identity.
  • lapcat 4y ago
    > The analogs of the traditional coding interview in the law school world are the LSAT and classroom timed memory tests. How are these analogous? LSAT is the Law School Admission Test. It gets you into law school. It doesn't get you a job as a lawyer. (The bar exam doesn't get you a job as a lawyer either.) And you only have to take it once, not for every job interview.
    • jordanpg 4y ago
      Fair enough; it's not a perfect analogy. The main point is the nature of the metrics. Getting into law school is the first part of the "interview." If you don't have the LSAT score, you won't get into a prestigious law school, full stop. If you aren't in a prestigious school, then a huge swath of elite positions are permanently closed to you. (In general -- yes there are a sprinkling of exceptions.) The bar exam has nothing to do with it -- everyone has to pass that, no matter what you do. The second part of the interview is law school grades and certain extra curricular signals. You're right, there is only one "interview." But the analogy still holds up, with respect to the nature of the intelligence and memory tests.