3 ms·

Maybe I've just drunk the koolaid, but as someone who has given these 'coding challenge' interviews, I: - Do go into them expecting to see a certain solution.

Maybe I've just drunk the koolaid, but as someone who has given these 'coding challenge' interviews, I: - Do go into them expecting to see a certain solution. - Do not penalize people for giving me a different one, if it works. I think that's awesome, personally. - Do ask people if they can think of additional test cases vs. those provided, and I penalize if there's obvious ones that they don't come up with, or if they just give me a bunch of variations of what we've already provided. - Do consider whether people actually read and/or understood the prompt (I read it to them). If I've asked you to write a function that returns a boolean, and you write a function that prints 'true' and doesn't return anything, and after some gentle prodding you don't get it, then you didn't solve the problem. - Do ask for you to talk through your solution and approach so I understand how you're thinking about the problem. I need to know whether you can code, and more importantly that you understand why you're doing what you're doing. I can't ask your prior employer. Not everyone has open source contributions or a portfolio of work they can show me, and no, I am not going to just look at your resume and say "well, they worked for a software company before so clearly they know what they're doing." I prefer take home exercises, where there's less manufactured pressure. I think they also lend themselves to a wider variety of challenge vs. the online 1 hour test using coderpad or something, meaning you may be able to ask something more appropriate for the role. But this approach upsets people as well.

whimsicalism 4y ago
> But this approach upsets people as well. Ultimately you have to realize that any process that is gating people from an opportunity & resources is going to upset people. People have an amazing capacity to make up elaborate reasons and narratives for things to be unfair, especially when there is a group of them.
haswell 4y ago
> I need to know whether you can code, and more importantly that you understand why you're doing what you're doing. I haven't gone through the interview process since 2013, so I might be a bit behind here, but are these challenges still happening under pressure in a highly time constrained environment? Because if they are, and if you interview me, you will probably not learn whether or not I can code, or if I know why I'm doing what I'm doing. I know this is a subject that has been discussed to death, but all this tells you is whether the candidate is good at high pressure coding exercises. I'm on sabbatical and half considering semi-retirement, but economic pressures are pushing me in the direction of seeking work. If there's one thing I do know, it's that I will pass on companies who insist on this kind of exercise. Let me take it home, and that's a different story. I know that not everyone will be happy with every approach, but time and time again, I've found the high pressure exercises useless, and that includes when I'm interviewing candidates. One dev team at my former company passed on me because I didn't do well in one of these high pressure exercises. A different team picked me up (they didn't believe in this type of exercise), and I spent over 8 years at the company and was known as a top performer.
- saxonww 4y ago
  I try to point out at the beginning that we understand it's manufactured pressure, and try to ease their minds if we can before getting started. In particular, we ask people to solve the problems in whatever language they are most comfortable with, and that it's an open book test; we're not testing you on whether you've memorized the Python standard library. This can certainly make things interesting! I've spent most of my career with perl, python, c#, and java, so the guy deciding to do his challenge in clojure was perhaps more of a challenge for me than it was for him. I don't think there's a universal definition of 'high pressure,' so I am not sure what else to say about this. It's certainly not a fishbowl experience where you're surrounded by 20 people yelling and pleading for you to save their lives by writing a function to reverse a string in place. And while I've read that this happens elsewhere, we're not critiquing you on the spot and arguing with you about why using this technique causes the interpreter to do some less efficient thing and how could you be so stupid. We try to coach and offer suggestions though, to help a candidate get to the right answer. That doesn't mean they necessarily passed - if we have to basically give you the answer, then you didn't solve the problem, and the coding interview is one of several inputs into a hiring decision - but I don't like to let candidates leave feeling like they failed if I can help it. I like to find at least one thing to praise about the solutions they turn in and tell them why I liked what they did. It is not the point of these interviews to ruin someone's day or make them feel worthless. All that said, we can only do so much. Ultimately whether you feel an environment is high pressure is on you, and how you handle it is also on you. We would regret missing out on a good candidate but I'm sure it happens. There are other candidates, and other opportunities for those we've missed out on.
  - haswell 4y ago
    > Ultimately whether you feel an environment is high pressure is on you, and how you handle it is also on you. Obviously that is subjective, but this is on everyone involved, especially the company creating said environment. Twitter 2.0 is an obvious (if extreme) example. The bottom line is that the whole approach is manufactured, and not indicative of real world problem solving skills or what the candidate will be dealing with on the team. > We would regret missing out on a good candidate but I'm sure it happens. It absolutely happens, and I’d bet good money that it happens often. Whether they realize it or not, most teams that take this approach end up creating an environment that is skewed towards a particular kind of personality, and that is ultimately a net negative in the long run. Back to my personal anecdote (which I’ve observed over and over throughout my career), the teams that rely too heavily on this approach end up rather dysfunctional and unbalanced over time. The team that turned me down was disbanded after some horrific security issues came to the surface. They were so focused on whether candidates could solve certain algorithms that they apparently didn’t verify that these devs understood the fundamentals of client-side vs. server-side validation and why they’re important (and not the same thing). But those devs could bang out a chess algorithm on a whiteboard with the best of them. I’m not saying that’s how you’re running things, but in my experience, teams that overemphasize this are doing so at the expense of far more important indicators. It takes a lot of discipline and care to not let this become a crutch. I’m also not saying it isn’t important to verify that a candidate has the necessary skills, but having a conversation about person’s learning style, how they got into development, how they go about taking on new tasks, etc can go a long way. I care more about mindset and approach to information acquisition than I do about what a candidate can whip up in a hour. Sitting down together and going over some existing code (after giving them enough time to absorb it) while having a discussion about the nuances of that code is far more collaborative, and in my experience far more likely to indicate whether or not the candidate knows what’s going on. I’ve spoken to many like minded and high performing colleagues who will not consider companies that are overly focused on this. Another colleague was recently offered a position after going through such a process, but bailed when they failed to follow up with enough meaningful conversation. Her conclusion: if that’s all they care about, I don’t trust that they’ve built a good team. There’s a growing contingent of the types of people who you’d want the most, but will not consider your team for doing this.
bobleeswagger 4y ago
> I need to know whether you can code On the flip-side, how much time do you spend explaining to an interviewee what hurdles they must overcome in order to code in the first place? Cultural blocks? Inefficiencies that don't have an owner or visibility to the greater org? If your infra is well architected and any random engineer can start contributing within a week to a month, kudos. In my experience, way too much energy is put into "can they do the job?" when the energy should be in "is this an environment where engineers can do their job?"
- saxonww 4y ago
  This is a good question. At least where I'm working, we have multiple conversations with a candidate throughout the interview process. When I have the opportunity, I do talk about technical or process challenges we have and try to be up front about aspects of a job that we know from experience can be a problem for some people. For example, I'm on an internal tooling team, and so there's a support component where we have to be accessible and accountable to devs who encounter problems using tools we've created. We have a support rotation where one person a sprint is primarily tasked with being the first contact for people with questions, problems, etc. We've had people on the team before who didn't like this and it showed because they put little effort into it. So now we're very up front during the interviews that this is part of the job; we don't want to hire someone who will be unhappy in the role. It's what we think is the best we can do. It's hard to answer about cultural blocks, because I haven't experienced those myself. I'm not sure how to even approach that; "hey, I see you're $different, here's some potential challenges you may need to deal with" ? That seems like it is as likely to offend as aid. That said, we do try to get a candidate in front of a variety of people, both to get a sense of how they deal with different people, and to give the candidate an opportunity to get feedback from people in different parts of the organization.
b20000 4y ago
you forgot to mention that you don't care about their experience relevant for the position, other projects they completed succesfully on their own, code they have written themselves for these projects, and you also forget to mention that you expect them to provide the optimal solution in under 2 minutes, and if they don't, they are out. you also seem to think that everyone is able to talk while they are coding, which is not the case.

whimsicalism 4y ago

> But this approach upsets people as well. Ultimately you have to realize that any process that is gating people from an opportunity & resources is going to upset people. People have an amazing capacity to make up elaborate reasons and narratives for things to be unfair, especially when there is a group of them.

haswell 4y ago

> I need to know whether you can code, and more importantly that you understand why you're doing what you're doing. I haven't gone through the interview process since 2013, so I might be a bit behind here, but are these challenges still happening under pressure in a highly time constrained environment? Because if they are, and if you interview me, you will probably not learn whether or not I can code, or if I know why I'm doing what I'm doing. I know this is a subject that has been discussed to death, but all this tells you is whether the candidate is good at high pressure coding exercises. I'm on sabbatical and half considering semi-retirement, but economic pressures are pushing me in the direction of seeking work. If there's one thing I do know, it's that I will pass on companies who insist on this kind of exercise. Let me take it home, and that's a different story. I know that not everyone will be happy with every approach, but time and time again, I've found the high pressure exercises useless, and that includes when I'm interviewing candidates. One dev team at my former company passed on me because I didn't do well in one of these high pressure exercises. A different team picked me up (they didn't believe in this type of exercise), and I spent over 8 years at the company and was known as a top performer.

saxonww 4y ago
I try to point out at the beginning that we understand it's manufactured pressure, and try to ease their minds if we can before getting started. In particular, we ask people to solve the problems in whatever language they are most comfortable with, and that it's an open book test; we're not testing you on whether you've memorized the Python standard library. This can certainly make things interesting! I've spent most of my career with perl, python, c#, and java, so the guy deciding to do his challenge in clojure was perhaps more of a challenge for me than it was for him. I don't think there's a universal definition of 'high pressure,' so I am not sure what else to say about this. It's certainly not a fishbowl experience where you're surrounded by 20 people yelling and pleading for you to save their lives by writing a function to reverse a string in place. And while I've read that this happens elsewhere, we're not critiquing you on the spot and arguing with you about why using this technique causes the interpreter to do some less efficient thing and how could you be so stupid. We try to coach and offer suggestions though, to help a candidate get to the right answer. That doesn't mean they necessarily passed - if we have to basically give you the answer, then you didn't solve the problem, and the coding interview is one of several inputs into a hiring decision - but I don't like to let candidates leave feeling like they failed if I can help it. I like to find at least one thing to praise about the solutions they turn in and tell them why I liked what they did. It is not the point of these interviews to ruin someone's day or make them feel worthless. All that said, we can only do so much. Ultimately whether you feel an environment is high pressure is on you, and how you handle it is also on you. We would regret missing out on a good candidate but I'm sure it happens. There are other candidates, and other opportunities for those we've missed out on.
- haswell 4y ago
  > Ultimately whether you feel an environment is high pressure is on you, and how you handle it is also on you. Obviously that is subjective, but this is on everyone involved, especially the company creating said environment. Twitter 2.0 is an obvious (if extreme) example. The bottom line is that the whole approach is manufactured, and not indicative of real world problem solving skills or what the candidate will be dealing with on the team. > We would regret missing out on a good candidate but I'm sure it happens. It absolutely happens, and I’d bet good money that it happens often. Whether they realize it or not, most teams that take this approach end up creating an environment that is skewed towards a particular kind of personality, and that is ultimately a net negative in the long run. Back to my personal anecdote (which I’ve observed over and over throughout my career), the teams that rely too heavily on this approach end up rather dysfunctional and unbalanced over time. The team that turned me down was disbanded after some horrific security issues came to the surface. They were so focused on whether candidates could solve certain algorithms that they apparently didn’t verify that these devs understood the fundamentals of client-side vs. server-side validation and why they’re important (and not the same thing). But those devs could bang out a chess algorithm on a whiteboard with the best of them. I’m not saying that’s how you’re running things, but in my experience, teams that overemphasize this are doing so at the expense of far more important indicators. It takes a lot of discipline and care to not let this become a crutch. I’m also not saying it isn’t important to verify that a candidate has the necessary skills, but having a conversation about person’s learning style, how they got into development, how they go about taking on new tasks, etc can go a long way. I care more about mindset and approach to information acquisition than I do about what a candidate can whip up in a hour. Sitting down together and going over some existing code (after giving them enough time to absorb it) while having a discussion about the nuances of that code is far more collaborative, and in my experience far more likely to indicate whether or not the candidate knows what’s going on. I’ve spoken to many like minded and high performing colleagues who will not consider companies that are overly focused on this. Another colleague was recently offered a position after going through such a process, but bailed when they failed to follow up with enough meaningful conversation. Her conclusion: if that’s all they care about, I don’t trust that they’ve built a good team. There’s a growing contingent of the types of people who you’d want the most, but will not consider your team for doing this.

bobleeswagger 4y ago

> I need to know whether you can code On the flip-side, how much time do you spend explaining to an interviewee what hurdles they must overcome in order to code in the first place? Cultural blocks? Inefficiencies that don't have an owner or visibility to the greater org? If your infra is well architected and any random engineer can start contributing within a week to a month, kudos. In my experience, way too much energy is put into "can they do the job?" when the energy should be in "is this an environment where engineers can do their job?"

saxonww 4y ago
This is a good question. At least where I'm working, we have multiple conversations with a candidate throughout the interview process. When I have the opportunity, I do talk about technical or process challenges we have and try to be up front about aspects of a job that we know from experience can be a problem for some people. For example, I'm on an internal tooling team, and so there's a support component where we have to be accessible and accountable to devs who encounter problems using tools we've created. We have a support rotation where one person a sprint is primarily tasked with being the first contact for people with questions, problems, etc. We've had people on the team before who didn't like this and it showed because they put little effort into it. So now we're very up front during the interviews that this is part of the job; we don't want to hire someone who will be unhappy in the role. It's what we think is the best we can do. It's hard to answer about cultural blocks, because I haven't experienced those myself. I'm not sure how to even approach that; "hey, I see you're $different, here's some potential challenges you may need to deal with" ? That seems like it is as likely to offend as aid. That said, we do try to get a candidate in front of a variety of people, both to get a sense of how they deal with different people, and to give the candidate an opportunity to get feedback from people in different parts of the organization.

b20000 4y ago

you forgot to mention that you don't care about their experience relevant for the position, other projects they completed succesfully on their own, code they have written themselves for these projects, and you also forget to mention that you expect them to provide the optimal solution in under 2 minutes, and if they don't, they are out. you also seem to think that everyone is able to talk while they are coding, which is not the case.