4 ms·

https://en.wikipedia.org/wiki/Beta_blocker#Performance-enhancing_use https://en.wikipedia.org/wiki/Beta_blocker#Performance-enhan... This post is an alarming d

by b20000 4y ago

https://en.wikipedia.org/wiki/Beta_blocker#Performance-enhancing_use https://en.wikipedia.org/wiki/Beta_blocker#Performance-enhan... This post is an alarming data point showing that leetcode style interviews are damaging to people's health and need to be removed as soon as possible. I personally dealt with the same issues but have refused to use any medication or alcohol to deal with the stress of performing under time pressure. None of this should be necessary.

ugh123 4y ago
How do you recommend we do interviews going forward?
- devoutsalsa 4y ago
  Assume people are smart, tell them about the actual job & and it’s responsibilities, tell them about the challenges of the job, ask them if it actually sounds like an interesting position, and then test them a bit on relevant things to see if they sounds reasonably competent.
  - xkqd 4y ago
    Absolutely preposterous. Are you suggesting we interview folks for the job at hand? Sarcasm aside, I’ve started interviewing people with “mock work day” style materials and it’s been pretty effective at determine who has been doing this for a decade, who can do this with a couple months to ramp up, and who is entirely faking it. I’ll have folks combing through mock stacktraces, creating a new endpoint, connecting to a local database, and even doing a little bit of multithreaded design. I’ll assess completion against quality of the solution and factor in how long it takes someone to complete it.
    - 7speter 4y ago
      Can you tell whose doing it for the first time or are they lumped into fakers?
      - xkqd 4y ago
        That’s a difficult determination to make, but usually that’s the difference between someone who can walk me through the solution and stumble on the implementation, and someone who can’t explain to me what’s going on. Lots of this stuff is language agnostic, so I keep that in mind too. For example, a stacktrace is a stacktrace in any language. However, we usually don’t extend offers to folks doing things for the first time, as we need a quick ramp up. We generally don’t find it too big an ask for engineers to be familiar with the basics of Spring, or can SSH into and debug remote boxes. If someone doesn’t know this, they’re generally a college grad. Otherwise, unfortunately, it’s not the talent we’re looking for.
  - dboreham 4y ago
    So back to what we did pre-Google.
    - devoutsalsa 4y ago
      Or we could make things worse. Let’s just start making all interviews an techno escape room.
- headsoup 4y ago
  With basic honesty, instead of this constant double-bluff pressure chamber approach that is 'the norm.'
- b20000 4y ago
  Evaluate people on past projects. If you have a project, show the code and walk through the code in a screen sharing session. Only show code that is non-confidential. If you do not have code, then first create a small project. That can be done in a week or two. This requires less time than grinding leetcode. Some people will say: but you need to be able to solve a problem in under a few minutes. That is utter bullshit. We all know that development doesn't work that way in reality.
  - PainfullyNormal 4y ago
    > Only show code that is non-confidential. Back in the day, it was normal to get your former boss to sign off on showing a piece of code in your next round of interviews.
    - b20000 4y ago
      I am self employed so I can sign off on anything.
  - 8note 4y ago
    Are you going to convince someone with another day job to do this so you can try to convince them to work at your company instead? This filters out the best
    - 7speter 4y ago
      Those people can’t take a few hours to make a small project? They can just make one and take it to multiple interviewers
    - b20000 4y ago
      If you cannot manage to build something in a few weeks time in your spare time then there is absolutely no way you can be "the best".
      - maxbond 4y ago
        "The best" may spend their "spare" time raising children, doing volunteer work, or simply unwinding - just because you didn't sell that time to an employer doesn't mean there aren't demands on it, or that you're obligated to spend every waking moment engaging in some form of labor. Having personal time to devote to programming isn't a function of job performance, it's a function of your particular life circumstances. And if you created a huge incentive to fabricate personal projects, a cottage industry of people who will create something cool on your GitHub in a way that looks authentic would spring up, and you'd be prioritizing people with the wealth and inclination to cheat over other candidates.
- davidthewatson 4y ago
  Don't treat programming as performance art. Some are great performers, but many are not. Don't force them to do something that's unnatural like code on a whiteboard. A whiteboard is not an interactive medium. A computer is. It's OK to riff on a computer the way you do on guitar. I know few that get it right the first time. Everybody thinks its all orchestration but Joe Beda points out the improvisation going back at least five years. He wasn't the first and likely won't be the last. You may see Donald Knuth once in a career. It's rare. Don't expect it from everyone. As an interviewee I use badly copied FAANG style as a red flag. Most will cargo cult interview styles copying what they've seen without thinking much about it. I've seen people memorize and pass interviews because Gayle Laakman McDowell's book was so overused. Do we really believe memorizing the book is better than not testing everyone exactly the same? I don't. As a person who's sat on both sides of the table, I'm a huge believer in technical conversations, but I believe that's very different than code. To me, programming is not a performance art. I recommend a few things: 1. Ask for sample code, preferably with git history showing that the author did most of the work or it was pairs or something like that. Ask lots of code review questions: why, how, alternatives, etc. Public github repos are fine. Private git repos are fine too. It's the history that tells the story both in terms of code frequency, velocity, revisions, tests, style, etc. 2. Use a pull request style in which the interviewee is the reviewer: what's wrong with this code? How should it improve? Is it good enough for MVP? What about production? Good opportunity to test whether they can speak truth to power when you show them rubbish that is patently wrong. I always hated reviewing bosses code when I had to march into their office and tell them they needed to fix their broken class inheritance or whatever. Interview is a good time to test for assertiveness. 3. Use pairs style where the interviewer is the keyboard/mouse driver and the interviewee is the navigator/commenter keeping the driver on track. 4. Ask them to bring their own hw/sw stack. Examine the choices and reach your own conclusions asking questions about why/how they arrive at their stack when no one is guiding the choices but them or their influencers. They don't really need to do much, more than a show/tell, explaining choices and why/how. To me, this is really interesting philosophically, particularly if it gets into stuff like *nix that are not the typical ubuntu, fedora, etc. and go off into arch derivatives or left field in a telling, R&D way such as shell, package managers, tmux, language, lint, tests, and so on. Hope this helps.
- deleted 4y ago
  [deleted]
- mikedelago 4y ago
  The technical interview for my current job was phenomenal. It was a leetcode style interview (maybe it was through hackerrank? I dont remember), but it was just writing code to hit a JSON-based HTTP API and collect the results into a list. I was encouraged to google things, and explain what I was thinking about in relation to the task. The task was trivial if you've done it before, but probably not easy if you didn't know how to write code. While doing that task, I was able to expand on my knowledge by talking about what my code was doing. It was in python, and I was doing it recursively (because that's what I like), so I was talking about how performance optimizations would be to make it iterative instead, if needed. I got into explaining this was because python doesn't have TCO recursion, so it just blows up the call stack if it's too large. The interviewers were chatty, and were happy to banter and in general be cordial during the interview as well, which I really liked. At the end of it, I felt really good about the interview and was confident that I had "passed".
rjh29 4y ago
I mean I understand it, but there is an almost unlimited supply of positions available, and no real reason to be stressed by an interview. The worst thing that can happen is you fail it and try the next one.
- b20000 4y ago
  It sounds like you never had to deal with a mental health issue and have a personality that is compatible with the process. That is great. Not everyone has that luxury. Many engineers are introverted people, possibly dealing with things like inferiority complex, imposter syndrome, anxiety, depression and more.
  - puttycat 4y ago
    Thank you.
  - rjh29 4y ago
    Please don't presume anything about people's mental health. I have alcoholism, social anxiety and depression. I stated my point badly, obviously anxiety is not rational, but on a rational level the stakes of a job interview are quite low (you can take another). It's not like stage fright where if you mess up your performance you could lose your job - you'll likely never see these people again. In that respect it's a bit closer to social anxiety.
- PainfullyNormal 4y ago
  It's hard to understand if you're not affected by it. You've heard the term "Stage Fright"? This is the same. Something about being put in a "performance" situation triggers the fight or flight reflex. At first, you're a deer in the headlights. Then, your body floods with adrenaline. The whole thing makes higher level thinking extremely difficult. I don't agree with the parent poster that it's "damaging to people's health", though. It's just something that happens. You recover pretty fast afterwards.
- oarabbus_ 4y ago
  I mean many tens of thousands of people have been laid off in recent weeks. If you're single and have savings in the bank, sure, maybe it's not a big deal, just look for the next one. If you've got a spouse, children, and mortgage, the stakes are different.
anotherbadlogin 4y ago
zackoverflow 4y ago
Interesting that the wiki says that the performance enhancing effect comes from a lower heart rate, which is something you can influence with practice. You can lower your resting heart rate naturally through exercise over time, and meditation and breathing techniques with practice give you control of your heart rate in the moment.

by b20000 4y ago

ugh123 4y ago

How do you recommend we do interviews going forward?

devoutsalsa 4y ago
Assume people are smart, tell them about the actual job & and it’s responsibilities, tell them about the challenges of the job, ask them if it actually sounds like an interesting position, and then test them a bit on relevant things to see if they sounds reasonably competent.
- xkqd 4y ago
  Absolutely preposterous. Are you suggesting we interview folks for the job at hand? Sarcasm aside, I’ve started interviewing people with “mock work day” style materials and it’s been pretty effective at determine who has been doing this for a decade, who can do this with a couple months to ramp up, and who is entirely faking it. I’ll have folks combing through mock stacktraces, creating a new endpoint, connecting to a local database, and even doing a little bit of multithreaded design. I’ll assess completion against quality of the solution and factor in how long it takes someone to complete it.
  - 7speter 4y ago
    Can you tell whose doing it for the first time or are they lumped into fakers?
    - xkqd 4y ago
      That’s a difficult determination to make, but usually that’s the difference between someone who can walk me through the solution and stumble on the implementation, and someone who can’t explain to me what’s going on. Lots of this stuff is language agnostic, so I keep that in mind too. For example, a stacktrace is a stacktrace in any language. However, we usually don’t extend offers to folks doing things for the first time, as we need a quick ramp up. We generally don’t find it too big an ask for engineers to be familiar with the basics of Spring, or can SSH into and debug remote boxes. If someone doesn’t know this, they’re generally a college grad. Otherwise, unfortunately, it’s not the talent we’re looking for.
- dboreham 4y ago
  So back to what we did pre-Google.
  - devoutsalsa 4y ago
    Or we could make things worse. Let’s just start making all interviews an techno escape room.
headsoup 4y ago
With basic honesty, instead of this constant double-bluff pressure chamber approach that is 'the norm.'
b20000 4y ago
Evaluate people on past projects. If you have a project, show the code and walk through the code in a screen sharing session. Only show code that is non-confidential. If you do not have code, then first create a small project. That can be done in a week or two. This requires less time than grinding leetcode. Some people will say: but you need to be able to solve a problem in under a few minutes. That is utter bullshit. We all know that development doesn't work that way in reality.
- PainfullyNormal 4y ago
  > Only show code that is non-confidential. Back in the day, it was normal to get your former boss to sign off on showing a piece of code in your next round of interviews.
  - b20000 4y ago
    I am self employed so I can sign off on anything.
- 8note 4y ago
  Are you going to convince someone with another day job to do this so you can try to convince them to work at your company instead? This filters out the best
  - 7speter 4y ago
    Those people can’t take a few hours to make a small project? They can just make one and take it to multiple interviewers
  - b20000 4y ago
    If you cannot manage to build something in a few weeks time in your spare time then there is absolutely no way you can be "the best".
    - maxbond 4y ago
      "The best" may spend their "spare" time raising children, doing volunteer work, or simply unwinding - just because you didn't sell that time to an employer doesn't mean there aren't demands on it, or that you're obligated to spend every waking moment engaging in some form of labor. Having personal time to devote to programming isn't a function of job performance, it's a function of your particular life circumstances. And if you created a huge incentive to fabricate personal projects, a cottage industry of people who will create something cool on your GitHub in a way that looks authentic would spring up, and you'd be prioritizing people with the wealth and inclination to cheat over other candidates.
davidthewatson 4y ago
Don't treat programming as performance art. Some are great performers, but many are not. Don't force them to do something that's unnatural like code on a whiteboard. A whiteboard is not an interactive medium. A computer is. It's OK to riff on a computer the way you do on guitar. I know few that get it right the first time. Everybody thinks its all orchestration but Joe Beda points out the improvisation going back at least five years. He wasn't the first and likely won't be the last. You may see Donald Knuth once in a career. It's rare. Don't expect it from everyone. As an interviewee I use badly copied FAANG style as a red flag. Most will cargo cult interview styles copying what they've seen without thinking much about it. I've seen people memorize and pass interviews because Gayle Laakman McDowell's book was so overused. Do we really believe memorizing the book is better than not testing everyone exactly the same? I don't. As a person who's sat on both sides of the table, I'm a huge believer in technical conversations, but I believe that's very different than code. To me, programming is not a performance art. I recommend a few things: 1. Ask for sample code, preferably with git history showing that the author did most of the work or it was pairs or something like that. Ask lots of code review questions: why, how, alternatives, etc. Public github repos are fine. Private git repos are fine too. It's the history that tells the story both in terms of code frequency, velocity, revisions, tests, style, etc. 2. Use a pull request style in which the interviewee is the reviewer: what's wrong with this code? How should it improve? Is it good enough for MVP? What about production? Good opportunity to test whether they can speak truth to power when you show them rubbish that is patently wrong. I always hated reviewing bosses code when I had to march into their office and tell them they needed to fix their broken class inheritance or whatever. Interview is a good time to test for assertiveness. 3. Use pairs style where the interviewer is the keyboard/mouse driver and the interviewee is the navigator/commenter keeping the driver on track. 4. Ask them to bring their own hw/sw stack. Examine the choices and reach your own conclusions asking questions about why/how they arrive at their stack when no one is guiding the choices but them or their influencers. They don't really need to do much, more than a show/tell, explaining choices and why/how. To me, this is really interesting philosophically, particularly if it gets into stuff like *nix that are not the typical ubuntu, fedora, etc. and go off into arch derivatives or left field in a telling, R&D way such as shell, package managers, tmux, language, lint, tests, and so on. Hope this helps.
deleted 4y ago
[deleted]
mikedelago 4y ago
The technical interview for my current job was phenomenal. It was a leetcode style interview (maybe it was through hackerrank? I dont remember), but it was just writing code to hit a JSON-based HTTP API and collect the results into a list. I was encouraged to google things, and explain what I was thinking about in relation to the task. The task was trivial if you've done it before, but probably not easy if you didn't know how to write code. While doing that task, I was able to expand on my knowledge by talking about what my code was doing. It was in python, and I was doing it recursively (because that's what I like), so I was talking about how performance optimizations would be to make it iterative instead, if needed. I got into explaining this was because python doesn't have TCO recursion, so it just blows up the call stack if it's too large. The interviewers were chatty, and were happy to banter and in general be cordial during the interview as well, which I really liked. At the end of it, I felt really good about the interview and was confident that I had "passed".

rjh29 4y ago

I mean I understand it, but there is an almost unlimited supply of positions available, and no real reason to be stressed by an interview. The worst thing that can happen is you fail it and try the next one.

b20000 4y ago
It sounds like you never had to deal with a mental health issue and have a personality that is compatible with the process. That is great. Not everyone has that luxury. Many engineers are introverted people, possibly dealing with things like inferiority complex, imposter syndrome, anxiety, depression and more.
- puttycat 4y ago
  Thank you.
- rjh29 4y ago
  Please don't presume anything about people's mental health. I have alcoholism, social anxiety and depression. I stated my point badly, obviously anxiety is not rational, but on a rational level the stakes of a job interview are quite low (you can take another). It's not like stage fright where if you mess up your performance you could lose your job - you'll likely never see these people again. In that respect it's a bit closer to social anxiety.
PainfullyNormal 4y ago
It's hard to understand if you're not affected by it. You've heard the term "Stage Fright"? This is the same. Something about being put in a "performance" situation triggers the fight or flight reflex. At first, you're a deer in the headlights. Then, your body floods with adrenaline. The whole thing makes higher level thinking extremely difficult. I don't agree with the parent poster that it's "damaging to people's health", though. It's just something that happens. You recover pretty fast afterwards.
oarabbus_ 4y ago
I mean many tens of thousands of people have been laid off in recent weeks. If you're single and have savings in the bank, sure, maybe it's not a big deal, just look for the next one. If you've got a spouse, children, and mortgage, the stakes are different.

anotherbadlogin 4y ago

zackoverflow 4y ago

Interesting that the wiki says that the performance enhancing effect comes from a lower heart rate, which is something you can influence with practice. You can lower your resting heart rate naturally through exercise over time, and meditation and breathing techniques with practice give you control of your heart rate in the moment.