3 ms·

I have 15 years of experience, and seem to woo teams every time we do screening calls. Could be how he describes the problem. Most of the time during code scre

I have 15 years of experience, and seem to woo teams every time we do screening calls. Could be how he describes the problem. Most of the time during code screens they don't want you to perfectly solve it. Talk it out. Someone who feels that perfect or bust is the only way to go will fail most of the time. Idk feels like something is missing. He's right, feedback loops suck. Question is... Can he practice doing a phone screening with a friend? Does he know anyone who interviews? Does his current job allow him to interview or sit in some? Just being part of it can give great interview experience. Around 10 years of experience is when I learned a ton of interview skills. Interviewing is indeed a skill in itself.

thr0wawayf00 5y ago
> Talk it out I personally hate this approach. Solving programming problems requires my full focus and vocalizing while trying to think is a challenge (partially due to my stutter). I can either focus on communicating clearly and professionally or I can stfu and code, not both. I’m happy to solve a problem silently and talk about it after I’m done, but I won’t do a phone screen that asks me to word vomit in the middle of coding.
- xyzzy_plugh 5y ago
  How do you feel about collaborative problem solving? A big reason talking-it-out is popular is because it provides signal on your communication, problem solving and collaboration skills. If you sit there for 30 minutes banging out a solution in silence, I get a bit of signal. If you sit there for 30 minutes in silence doing nothing, then you're stuck and you've failed the interview as I didn't get the opportunity to assist. Talking through is so important.
  - soneca 5y ago
    In every real world work problem that is solved collaboratively had some time before where people understood the context and the problem by themselves before. At least they know the codebase, the business goals, the colleague. There is no situation where a boss call two random engineers, throw a completely new problem at their hands and ask them to solve it in 45 minutes.
    - xyzzy_plugh 5y ago
      > There is no situation where a boss call two random engineers, throw a completely new problem at their hands and ask them to solve it in 45 minutes. I don't know what to say to this beyond, absolutely yes this situation exists. The easiest scenario is you are on call and get paged and must solve a critical issue in as few minutes as possible.
      - closeparen 5y ago
        What kind of shop are you working in which requires you to solve algorithms puzzles to resolve outages? Even if we think we see a way to solve an outage with something like this, we generally consider it inappropriate for an outage mitigation scenario, always preferring to rollback / flip feature flags / add capacity / other simple and minimally invasive interventions. Implementing a better or more scalable or more resilient system is important, yes, but is done after the issue is mitigated... not at gunpoint.
        xyzzy_plugh 5y ago
        > always preferring to rollback / flip feature flags / add capacity / other simple and minimally invasive interventions. Sure, that's nice, but you're living in a fantasy if you expect that to always be possible. I also didn't say anything about implementing scalable or more resilient, or even algorithm puzzles. That's not what we're discussing. I'm talking about communicating when problem solving. If solving an outage was always a mundane rollback or simple intervention, then it should've been automated. For example, say a new deploy corrupted the database subtly. How do you recover it? Perhaps you rollback the deploy, create a new database instance from a backup, perform a cutover, lock writes, write a migration to copy records from the old instance to avoid losing data written since the backup, validate the restore, unlock writes, monitor. You probably also need to work with stakeholders to draft and send comms to customers, document the steps you took, answer questions from product folk. This is what I am trying to get signal on in an interview. How do you work on your feet, when it matters most. If you expect to be able to sit in silence for 30 minutes after you were paged while you draft a solution in your head then you're going to have a bad time. For a junior candidate, these expectations are reduced, but this is the bar for a senior candidates. If I wanted you to solve an algorithm puzzle I'd give you the puzzle and tell you to come back tomorrow. If I didn't think you could solve an algorithm puzzle, we wouldn't be having a conversation. Communication is the whole point.
- dkarl 5y ago
  I agree it isn't a real job requirement to be able to switch back and forth quickly between thinking and communicating. I really have a hard time decoding what another person is thinking when I'm solving a problem. It's like I use the same part of my brain for both things, and it has to reboot to switch between them. To mitigate this I try to constantly verbalize things that I'm thinking anyway, like, "This isn't the OO way to do it, but I think the OO way would be a poor match for the problem," and, "In real code I would model each of these item types with a class, but to save time and hopefully get further with the problem I'm going to model them as lists." The more I talk, the less they talk, and the less often I have to reboot into human mode.
- woopwoop 5y ago
  I'm much more pro-leetcode-style-interviews than the median HNer, but I agree with this criticism. It's a very unnatural way of working, and really dilutes the skill signal. In principle, you are learning about how they communicate, but I believe in practice what you suggest, where the candidate has a chance to produce a solution and then explain it afterwards, would be more effective at this as well.
- yongjik 5y ago
  Can't speak of others, but when I'm doing interview I never "take points off" for not talking while coding - as long as they're building the answer in the correct direction, that's all I want. I think "talking while coding" is, at least in theory, for the benefit of the candidate - if they're "thinking aloud" and about to make a mistake which may take 20 minutes to recover, the interviewer can gently nudge them in the correct direction.
  - Justsignedup 5y ago
    It's not about talk while coding. It's about letting your interviewer know what strategy you employ. I fully expect Sr engineers to talk about why they choose the approach they do, and then implement it. I can adjust their approach while I hear about it, and then let them code it up. This whole being silent and focus coding is bs I think. When you're doing the typing part, don't talk, just code. When you're doing the strategy part, talk. I want to see how you'll be able to express your strategy to your coworkers when a real actually challenging problem occurs. Also. Algo problems are worthless. They only tell me you know how to cram. Don't do those, they don't actually answer anything. If I see that in an interview that's a flag for me that their eng culture might have issues. Only exception would be if you're applying to a job where you'll be doing that all day.
- mikelevins 5y ago
  I'm with you. I can solve programming problems OR carry on a conversation. I cannot do both at the same time. It isn't just coding. The same quirk shows up in other ways. For example, I also cannot carry on a conversation and navigate. I can drive safely while conversing, but I cannot navigate. When my daughter was a teenager she exploited this quirk for laughs: get in the car with Dad; start for destination; bring up interesting topic; wait to see what random place we end up going; profit! I can explain my thinking after the fact. I just can't do the thinking while conversing. I've been working as a consultant for a while now. Communication is a big part of the job. My current client is one that has come back repeatedly, and that pretty much lets me set the terms I want, and gives me broad discretion to decide how things are to be done. I presume that means they're happy with the results so far and want more of the same. I do have to communicate effectively in that job. I collaborate with a VP to set directions, vet R&D proposals, choose implementation strategies, pick tools, guide other contributors, and so on. So I have to be able to communicate effectively. I also write the majority of working code in the current set of projects we're working on. What I don't have to do is write code while carrying on conversations. It's a good thing I don't have to do that, because I can't. I can pair program, as long as my collaborator understands that when I need to really think about a problem, I have to leave the session to do it. I can rejoin once I've figured out what I'm thinking about, and I can explain what I thought of. The collaborators I'm working with now are used to it by now, and it's a normal part of our collaborative cadence. I can hunt bugs in a pair session, similar to the way that I can drive just fine while conversing; I just can't navigate, or do involved creative problem solving. I'm not exactly sure what the difference is; just that there's a certain kind of thinking I need to do that gets blocked by conversation. "I'm trying to think, but nothing happens." I'm useless in tech-interview coding, so I just don't do it anymore. I've told several companies that wanted me to go through their coding interviews that they should just give me the lowest possible score on that part of the interview, and if they still wanted to talk to me about the job, I'd be happy to talk to them. Nobody has taken me up on that specific proposal, but I have gotten nice offers a couple of times after I thoroughly bombed coding interviews. Those experiences made me question how seriously those companies took their own processes.
cosmotic 5y ago
I talked it out recently and it quickly became apparent that the interviewer considered my list of "this is how I wouldn't do it" as a list of "these are approaches I would actually consider".

thr0wawayf00 5y ago

> Talk it out I personally hate this approach. Solving programming problems requires my full focus and vocalizing while trying to think is a challenge (partially due to my stutter). I can either focus on communicating clearly and professionally or I can stfu and code, not both. I’m happy to solve a problem silently and talk about it after I’m done, but I won’t do a phone screen that asks me to word vomit in the middle of coding.

xyzzy_plugh 5y ago
How do you feel about collaborative problem solving? A big reason talking-it-out is popular is because it provides signal on your communication, problem solving and collaboration skills. If you sit there for 30 minutes banging out a solution in silence, I get a bit of signal. If you sit there for 30 minutes in silence doing nothing, then you're stuck and you've failed the interview as I didn't get the opportunity to assist. Talking through is so important.
- soneca 5y ago
  In every real world work problem that is solved collaboratively had some time before where people understood the context and the problem by themselves before. At least they know the codebase, the business goals, the colleague. There is no situation where a boss call two random engineers, throw a completely new problem at their hands and ask them to solve it in 45 minutes.
  - xyzzy_plugh 5y ago
    > There is no situation where a boss call two random engineers, throw a completely new problem at their hands and ask them to solve it in 45 minutes. I don't know what to say to this beyond, absolutely yes this situation exists. The easiest scenario is you are on call and get paged and must solve a critical issue in as few minutes as possible.
    - closeparen 5y ago
      What kind of shop are you working in which requires you to solve algorithms puzzles to resolve outages? Even if we think we see a way to solve an outage with something like this, we generally consider it inappropriate for an outage mitigation scenario, always preferring to rollback / flip feature flags / add capacity / other simple and minimally invasive interventions. Implementing a better or more scalable or more resilient system is important, yes, but is done after the issue is mitigated... not at gunpoint.
      - xyzzy_plugh 5y ago
        > always preferring to rollback / flip feature flags / add capacity / other simple and minimally invasive interventions. Sure, that's nice, but you're living in a fantasy if you expect that to always be possible. I also didn't say anything about implementing scalable or more resilient, or even algorithm puzzles. That's not what we're discussing. I'm talking about communicating when problem solving. If solving an outage was always a mundane rollback or simple intervention, then it should've been automated. For example, say a new deploy corrupted the database subtly. How do you recover it? Perhaps you rollback the deploy, create a new database instance from a backup, perform a cutover, lock writes, write a migration to copy records from the old instance to avoid losing data written since the backup, validate the restore, unlock writes, monitor. You probably also need to work with stakeholders to draft and send comms to customers, document the steps you took, answer questions from product folk. This is what I am trying to get signal on in an interview. How do you work on your feet, when it matters most. If you expect to be able to sit in silence for 30 minutes after you were paged while you draft a solution in your head then you're going to have a bad time. For a junior candidate, these expectations are reduced, but this is the bar for a senior candidates. If I wanted you to solve an algorithm puzzle I'd give you the puzzle and tell you to come back tomorrow. If I didn't think you could solve an algorithm puzzle, we wouldn't be having a conversation. Communication is the whole point.
dkarl 5y ago
I agree it isn't a real job requirement to be able to switch back and forth quickly between thinking and communicating. I really have a hard time decoding what another person is thinking when I'm solving a problem. It's like I use the same part of my brain for both things, and it has to reboot to switch between them. To mitigate this I try to constantly verbalize things that I'm thinking anyway, like, "This isn't the OO way to do it, but I think the OO way would be a poor match for the problem," and, "In real code I would model each of these item types with a class, but to save time and hopefully get further with the problem I'm going to model them as lists." The more I talk, the less they talk, and the less often I have to reboot into human mode.
woopwoop 5y ago
I'm much more pro-leetcode-style-interviews than the median HNer, but I agree with this criticism. It's a very unnatural way of working, and really dilutes the skill signal. In principle, you are learning about how they communicate, but I believe in practice what you suggest, where the candidate has a chance to produce a solution and then explain it afterwards, would be more effective at this as well.
yongjik 5y ago
Can't speak of others, but when I'm doing interview I never "take points off" for not talking while coding - as long as they're building the answer in the correct direction, that's all I want. I think "talking while coding" is, at least in theory, for the benefit of the candidate - if they're "thinking aloud" and about to make a mistake which may take 20 minutes to recover, the interviewer can gently nudge them in the correct direction.
- Justsignedup 5y ago
  It's not about talk while coding. It's about letting your interviewer know what strategy you employ. I fully expect Sr engineers to talk about why they choose the approach they do, and then implement it. I can adjust their approach while I hear about it, and then let them code it up. This whole being silent and focus coding is bs I think. When you're doing the typing part, don't talk, just code. When you're doing the strategy part, talk. I want to see how you'll be able to express your strategy to your coworkers when a real actually challenging problem occurs. Also. Algo problems are worthless. They only tell me you know how to cram. Don't do those, they don't actually answer anything. If I see that in an interview that's a flag for me that their eng culture might have issues. Only exception would be if you're applying to a job where you'll be doing that all day.
mikelevins 5y ago
I'm with you. I can solve programming problems OR carry on a conversation. I cannot do both at the same time. It isn't just coding. The same quirk shows up in other ways. For example, I also cannot carry on a conversation and navigate. I can drive safely while conversing, but I cannot navigate. When my daughter was a teenager she exploited this quirk for laughs: get in the car with Dad; start for destination; bring up interesting topic; wait to see what random place we end up going; profit! I can explain my thinking after the fact. I just can't do the thinking while conversing. I've been working as a consultant for a while now. Communication is a big part of the job. My current client is one that has come back repeatedly, and that pretty much lets me set the terms I want, and gives me broad discretion to decide how things are to be done. I presume that means they're happy with the results so far and want more of the same. I do have to communicate effectively in that job. I collaborate with a VP to set directions, vet R&D proposals, choose implementation strategies, pick tools, guide other contributors, and so on. So I have to be able to communicate effectively. I also write the majority of working code in the current set of projects we're working on. What I don't have to do is write code while carrying on conversations. It's a good thing I don't have to do that, because I can't. I can pair program, as long as my collaborator understands that when I need to really think about a problem, I have to leave the session to do it. I can rejoin once I've figured out what I'm thinking about, and I can explain what I thought of. The collaborators I'm working with now are used to it by now, and it's a normal part of our collaborative cadence. I can hunt bugs in a pair session, similar to the way that I can drive just fine while conversing; I just can't navigate, or do involved creative problem solving. I'm not exactly sure what the difference is; just that there's a certain kind of thinking I need to do that gets blocked by conversation. "I'm trying to think, but nothing happens." I'm useless in tech-interview coding, so I just don't do it anymore. I've told several companies that wanted me to go through their coding interviews that they should just give me the lowest possible score on that part of the interview, and if they still wanted to talk to me about the job, I'd be happy to talk to them. Nobody has taken me up on that specific proposal, but I have gotten nice offers a couple of times after I thoroughly bombed coding interviews. Those experiences made me question how seriously those companies took their own processes.

cosmotic 5y ago

I talked it out recently and it quickly became apparent that the interviewer considered my list of "this is how I wouldn't do it" as a list of "these are approaches I would actually consider".