4 ms·

I’m reasonably certain that I interviewed someone using this or something like it in the last few days. Lots of eye scanning while looking above the window the

by colinb 2y ago

I’m reasonably certain that I interviewed someone using this or something like it in the last few days. Lots of eye scanning while looking above the window they’d been typing into. Pauses. Big pastes. One of my excellent colleagues noticed that the candidate made use of exciting C++ casts before ever defining the variable’s types. Complete inability to explain or debug the code just written. So. Frustrating in two dimensions. First a waste of time for everyone. Second, occasional signs of real ability make me think the candidate might’ve made it work honestly. The fool. This, and this alone, makes me pine for in-person interviews. But I suspect those won’t be back for some time. (For good reasons that are out of scope here.)

deleted 2y ago
[deleted]
xandrius 2y ago
It sounds like you want sympathy but it just shows that some people just don't understand the power dynamics of an interview. I believe live coding is a scourge and we should get rid of it altogether. Get a tiny open ended project, which requires more design/architecture skills than actually finishing the solution. You do it at your own time and shouldn't take more than 1-2h. You submit it and provide your mental process in writing. We then hop on a call and we can dicuss it further, talking about possible issues and what to do to get it released if a requirement changed last minute. If you can do that, come across amicable, knowledgeable and experienced enough given the seniority of the role, and feel like you are not reading from an hidden ai window then you pass. "Exciting casts" are absolutely worthless in real life, everyone has to balance shipping vs code artistry.
- 4dregress 2y ago
  100% Another one I like was having to code review a repo which had specific issues in it. Then add some new features. Then in the final stage of the interview you go through it.
- colinb 2y ago
  [flagged]
- gzer0 2y ago
  The core issue here is the sheer volume of applicants. Microsoft opened 30 new-grad software engineering positions. Care to guess how many applications they got within 24 hours? 1,000? 10,000? Nope. 100,000 applications. In under a single day. With that kind of applicant pool, I’m honestly not sure what the best approach is—even though, in a perfect world, your suggestion would be the more appropriate route. The reality, however, is that these numbers are just absurd.
  - xandrius 2y ago
    I think at that point it's a lottery anyway, pick 50 truly randomly and try those?
    - teddyh 2y ago
      “We don’t want to hire unlucky people.”
  - thaumasiotes 2y ago
    > With that kind of applicant pool, I’m honestly not sure what the best approach is You should see the number of people that apply to college.
    - turdprincess 2y ago
      At least in the USA one major piece of the college application is a standardized test - a concept very similar to a Leetcode interview.
      - sotix 2y ago
        A standardized test is considerably more standardized than a leetcode interview though. Not to mention you take it once and then provide the scores to everyone. My process with taking the cpa exam a single time was a much better experience than random leetcode problems every time.
  - lordnacho 2y ago
- disgruntledphd2 2y ago
  > Get a tiny open ended project, which requires more design/architecture skills than actually finishing the solution. You do it at your own time and shouldn't take more than 1-2h. You submit it and provide your mental process in writing. I used to really like the idea of take homes, then I had kids and discovered just how hard it is to find time to do these (particularly for multiple applications while working). Don't get me wrong, I think that they're generally a better test for the actual role, but they're not perfect, and they're game-able by spending way more time on them. Interviewing is hard. Like, ideally, we'd just centralise the administration of these tests and you'd do a few every year (so formal CPD rather than an expectation that people do it in their off time) but that is never gonna happen in the tech industry for various good and bad reasons.
- szastupov 2y ago
  > I believe live coding is a scourge and we should get rid of it altogether. I would take an hour of live coding any time over a take-home task that is one hour only on paper and takes you three in reality. Engineering is collaboration, and it's fair to expect candidates to talk, solve problems, and explain their solutions. Where we could do better as an industry is the type of problems we give to people. I'm not a fan of LeetCode-style questions, especially when multiple ones are asked. Something closer to Earth would be better. But even if you have to ask something algorithmical, I'd prefer the style of "Advent of Code" exercises where the same problem has variations and multiple levels of complexity.
  - thaumasiotes 2y ago
    > But even if you have to ask something algorithmical, I'd prefer the style of "Advent of Code" exercises where the same problem has variations and multiple levels of complexity. That's how Amazon does their interviews.
  - tdeck 2y ago
    It only takes you three hours if you don't pay someone else to write it for you and provide you with a written brief about how it works, which is what I suspect some candidates must do.
- dahart 2y ago
  Your comment is excessively dismissive. The irony is that parent actually did what you’re suggesting, tried to talk about the interviewee’s solution and found that they didn’t come across as knowledgeable and experienced enough even though their code suggested otherwise. Whether it’s live coding or take-home is mostly irrelevant. Your proposed alternative is absolutely subject to the same problem, AI-written code and LLM-written mental process. Think more carefully about whether it solves anything and exactly what problem it solves, because it does not solve the problem of people trying to game interviews with AI, your suggestion is potentially worse on that axis. The whole point of doing it live is to get to the talking part that you suggested more quickly. Wouldn’t you rather be discussing your thinking immediately and get a sense for what the real questions are and how you’re doing, and have the opportunity to talk about it, than waste several hours doing it at home trying to write something up without getting clues along the way or being able to ask questions, only to have the next guy get hired because they used AI, or because they’re fine with live coding, or because they’re better at writing than coding, or because they got lucky? You have to live code on the job. Do take a moment to consider what the hiring manager needs and whether take-home problems are either more effective or more efficient for the company. Managers want to find the best candidates, and best involves more than coding, it involves communication and collaboration skills too. Live coding can give some indicators of those things, and take-home problems cannot.
- shepardrtc 2y ago
  I did that for my previous job and I loved it. Had plenty of time to get over my nerves and then build something cool. And then brag about my choices in writing.
- QuadmasterXLII 2y ago
  Some people want to be hired based on 25 minutes of easy live coding. It’s ok that you’re not one of them but don’t piss in someone else’s cereal.
zabzonk 2y ago
> made use of exciting C++ casts before ever defining the variable’s types an example of this, please?
7734128 2y ago
> Lots of eye scanning while looking above the window they’d been typing into. Are you expecting people to not reference external material, such as documentation or syntax, and only code from memory?
- colinb 2y ago
  Absolutely not. In my standard intro material I explicitly say otherwise, tell them that actual work involves checking external references, and that I want the interview to be as near to a collaborative experience as it can be in the odd circumstances. I also tell them that they should tell me when they're checking external resources (the CPP reference is what I mostly have in mind, but StackOverflow or whatever is fine with me) so that I understand how they go about solving problems. Because that's the actual important bit. All the coding and the questioning is a proxy for that.

by colinb 2y ago

deleted 2y ago

[deleted]

xandrius 2y ago

It sounds like you want sympathy but it just shows that some people just don't understand the power dynamics of an interview. I believe live coding is a scourge and we should get rid of it altogether. Get a tiny open ended project, which requires more design/architecture skills than actually finishing the solution. You do it at your own time and shouldn't take more than 1-2h. You submit it and provide your mental process in writing. We then hop on a call and we can dicuss it further, talking about possible issues and what to do to get it released if a requirement changed last minute. If you can do that, come across amicable, knowledgeable and experienced enough given the seniority of the role, and feel like you are not reading from an hidden ai window then you pass. "Exciting casts" are absolutely worthless in real life, everyone has to balance shipping vs code artistry.

4dregress 2y ago
100% Another one I like was having to code review a repo which had specific issues in it. Then add some new features. Then in the final stage of the interview you go through it.
colinb 2y ago
[flagged]
gzer0 2y ago
The core issue here is the sheer volume of applicants. Microsoft opened 30 new-grad software engineering positions. Care to guess how many applications they got within 24 hours? 1,000? 10,000? Nope. 100,000 applications. In under a single day. With that kind of applicant pool, I’m honestly not sure what the best approach is—even though, in a perfect world, your suggestion would be the more appropriate route. The reality, however, is that these numbers are just absurd.
- xandrius 2y ago
  I think at that point it's a lottery anyway, pick 50 truly randomly and try those?
  - teddyh 2y ago
    “We don’t want to hire unlucky people.”
- thaumasiotes 2y ago
  > With that kind of applicant pool, I’m honestly not sure what the best approach is You should see the number of people that apply to college.
  - turdprincess 2y ago
    At least in the USA one major piece of the college application is a standardized test - a concept very similar to a Leetcode interview.
    - sotix 2y ago
      A standardized test is considerably more standardized than a leetcode interview though. Not to mention you take it once and then provide the scores to everyone. My process with taking the cpa exam a single time was a much better experience than random leetcode problems every time.
- lordnacho 2y ago
disgruntledphd2 2y ago
> Get a tiny open ended project, which requires more design/architecture skills than actually finishing the solution. You do it at your own time and shouldn't take more than 1-2h. You submit it and provide your mental process in writing. I used to really like the idea of take homes, then I had kids and discovered just how hard it is to find time to do these (particularly for multiple applications while working). Don't get me wrong, I think that they're generally a better test for the actual role, but they're not perfect, and they're game-able by spending way more time on them. Interviewing is hard. Like, ideally, we'd just centralise the administration of these tests and you'd do a few every year (so formal CPD rather than an expectation that people do it in their off time) but that is never gonna happen in the tech industry for various good and bad reasons.
szastupov 2y ago
> I believe live coding is a scourge and we should get rid of it altogether. I would take an hour of live coding any time over a take-home task that is one hour only on paper and takes you three in reality. Engineering is collaboration, and it's fair to expect candidates to talk, solve problems, and explain their solutions. Where we could do better as an industry is the type of problems we give to people. I'm not a fan of LeetCode-style questions, especially when multiple ones are asked. Something closer to Earth would be better. But even if you have to ask something algorithmical, I'd prefer the style of "Advent of Code" exercises where the same problem has variations and multiple levels of complexity.
- thaumasiotes 2y ago
  > But even if you have to ask something algorithmical, I'd prefer the style of "Advent of Code" exercises where the same problem has variations and multiple levels of complexity. That's how Amazon does their interviews.
- tdeck 2y ago
  It only takes you three hours if you don't pay someone else to write it for you and provide you with a written brief about how it works, which is what I suspect some candidates must do.
dahart 2y ago
Your comment is excessively dismissive. The irony is that parent actually did what you’re suggesting, tried to talk about the interviewee’s solution and found that they didn’t come across as knowledgeable and experienced enough even though their code suggested otherwise. Whether it’s live coding or take-home is mostly irrelevant. Your proposed alternative is absolutely subject to the same problem, AI-written code and LLM-written mental process. Think more carefully about whether it solves anything and exactly what problem it solves, because it does not solve the problem of people trying to game interviews with AI, your suggestion is potentially worse on that axis. The whole point of doing it live is to get to the talking part that you suggested more quickly. Wouldn’t you rather be discussing your thinking immediately and get a sense for what the real questions are and how you’re doing, and have the opportunity to talk about it, than waste several hours doing it at home trying to write something up without getting clues along the way or being able to ask questions, only to have the next guy get hired because they used AI, or because they’re fine with live coding, or because they’re better at writing than coding, or because they got lucky? You have to live code on the job. Do take a moment to consider what the hiring manager needs and whether take-home problems are either more effective or more efficient for the company. Managers want to find the best candidates, and best involves more than coding, it involves communication and collaboration skills too. Live coding can give some indicators of those things, and take-home problems cannot.
shepardrtc 2y ago
I did that for my previous job and I loved it. Had plenty of time to get over my nerves and then build something cool. And then brag about my choices in writing.
QuadmasterXLII 2y ago
Some people want to be hired based on 25 minutes of easy live coding. It’s ok that you’re not one of them but don’t piss in someone else’s cereal.

zabzonk 2y ago

> made use of exciting C++ casts before ever defining the variable’s types an example of this, please?

7734128 2y ago

> Lots of eye scanning while looking above the window they’d been typing into. Are you expecting people to not reference external material, such as documentation or syntax, and only code from memory?

colinb 2y ago
Absolutely not. In my standard intro material I explicitly say otherwise, tell them that actual work involves checking external references, and that I want the interview to be as near to a collaborative experience as it can be in the odd circumstances. I also tell them that they should tell me when they're checking external resources (the CPP reference is what I mostly have in mind, but StackOverflow or whatever is fine with me) so that I understand how they go about solving problems. Because that's the actual important bit. All the coding and the questioning is a proxy for that.