4 ms·

I don't understand why this is so hard for so many programmers. As the person frequently on the other side of the table, I can tell you this process is pretty e

by wkirby 5y ago

I don't understand why this is so hard for so many programmers. As the person frequently on the other side of the table, I can tell you this process is pretty easy to get right. Engage with the question. I'm asking it for a reason; you might think it's stupid, but I wouldn't ask if I didn't care what your answer was. You can tell me you think it's stupid, but even better would be to _answer_ the question then _ask_ why I want to know. If the technical problem is easy for you, then demonstrate that it's easy. I actually don't care if you solve the problem (and very few interviewers I've spoken with care either). I care that you can think through a problem, articulate your thought process, and then explain to me the solution you've arrived at. Software development in a team setting is a collaborative process. That collaboration often manifests itself through answering stupid questions, writing pseudo-code on a whiteboard, explaining why your code does what it does, and asking others (politely) why their code is the way it is. The longer I do this work, the more convinced I become that the software part of it represents less than 30% of what makes a good developer, and the interview is not to find the programming savants, rather to weed out people who will make working on a team a nightmare.

jacquesm 5y ago
So you'll end up with team players but with nobody who will actually get the job done. The better way is as the interviewer to do your homework and to engage on the level of the interviewee, so as not to start off with insulting their intelligence. Realize that your company is as much in the hot-seat as the candidate is.
- nawgz 5y ago
  You claim developers that are show skills of collaboration thru acts like vocalizing their thought processes, ensuring mutual understanding of a problem, brainstorming, and ability to approach and deconstruct a technical problem with another person are LESS likely to get things done? I must say, that doesn't check out to me. Writing code is a small part of building apps, and while some organizations have ICs who implement a spec, and a whole team who builds that spec, I think it's clear most orgs would be better off with someone who doesn't require the spec in the first place to figure out what code to write, and doesn't need to be browbeaten to do it in a way that makes sense to their team.
  - jacquesm 5y ago
    No, I'm claiming that both interviewer and interviewee have a similar workload, and that usually only one party feels like they need to engage, the other is in a position of power and is the gatekeeper to 'the job' and so feels no need to engage. I've seen this numerous times and it never ceases to amaze me that these little pointy haired bosses / team leads / whatever you want to call that particular flavor of middle manager this week don't realize that they represent the company during contact with an outsider, which makes them an ambassador of sorts.
    - nawgz 5y ago
      > I'm claiming that both interviewer and interviewee have a similar workload I do not know what this means or what relevance it holds to our context. > and that usually only one party feels like they need to engage, the other is in a position of power and is the gatekeeper to 'the job' and so feels no need to engage Again, what are you saying? Recall, we are discussing the very silly claim that "you'll end up with team players but with nobody who will actually get the job done" based on an interview scenario where the interviewee is required to perform part of the problem-solving a job entails, just not a part which is not explicitly implementing a solution alone (coding). This language about the interviewer not "engaging" and "[not realizing] they represent the company" seems like an entirely separate conversation. Additionally, your usage of "I've seen this numerous times" and initial assumption that the interviewing company would "start off with insulting [the interviewee's] intelligence" don't really make me feel like you're discussing a good-faith interview, instead pre-supposing all interviews are performed in bad faith and interviewees are right to be offended by what they are being ask. I dislike this muchly, but indeed, the top of this comment tree addresses this attitude directly, something you entirely ignored: > [As an interviewer], I'm asking [each question] for a reason; you might think it's stupid, but I wouldn't ask if I didn't care what your answer was So I do not understand why you continued to go forward assuming the interviewing company is acting in bad faith. They are not, that attitude makes no sense, and the context has already directly been set for our conversation that the interviewer is asking this question in good faith because they believe it to be a signal wrt employee value. Please understand, as someone who interviews, one of the critical filters we introduced was evaluating candidates on their interactivity & collaboration. Doing this explicitly has resulted in a marked uptick in the quality of our candidates. Of course, we still aggressively apply filters that ensure these candidates can code and have implemented solutions of similar complexity & domain as we expect them to architect & create, but introducing the collaboration filter has resulted in coworkers of remarkable ability to solve problems quickly and continuously, both as individuals and in direct collaboration. I would easily say you would fail this filter entirely, and you should take care to not allow your bitter attitude to calcify.
- lloydgrossman 5y ago
  > So you'll end up with team players but with nobody who will actually get the job done. There are plenty of developers that are capable of writing code and explaining how and why they've done it. Your difficulty communicating ideas doesn't directly translate to being a better developer. >The better way is as the interviewer to do your homework and to engage on the level of the interviewee I'm not sure you've ever reviewed resumes, but they pretty frequently absolutely suck, targeted or not targeted, or otherwise not accurately representing skills. It can go from completely clueless "buzzword bingo" to "obviously I'm skilled enough to not need to mention the silly stuff like TCP" >Realize that your company is as much in the hot-seat as the candidate is. ...and for those companies that do understand that? Where is the substance to this comment? What stance are you taking or solutions you proposing?

by wkirby 5y ago

jacquesm 5y ago

So you'll end up with team players but with nobody who will actually get the job done. The better way is as the interviewer to do your homework and to engage on the level of the interviewee, so as not to start off with insulting their intelligence. Realize that your company is as much in the hot-seat as the candidate is.

nawgz 5y ago
You claim developers that are show skills of collaboration thru acts like vocalizing their thought processes, ensuring mutual understanding of a problem, brainstorming, and ability to approach and deconstruct a technical problem with another person are LESS likely to get things done? I must say, that doesn't check out to me. Writing code is a small part of building apps, and while some organizations have ICs who implement a spec, and a whole team who builds that spec, I think it's clear most orgs would be better off with someone who doesn't require the spec in the first place to figure out what code to write, and doesn't need to be browbeaten to do it in a way that makes sense to their team.
- jacquesm 5y ago
  No, I'm claiming that both interviewer and interviewee have a similar workload, and that usually only one party feels like they need to engage, the other is in a position of power and is the gatekeeper to 'the job' and so feels no need to engage. I've seen this numerous times and it never ceases to amaze me that these little pointy haired bosses / team leads / whatever you want to call that particular flavor of middle manager this week don't realize that they represent the company during contact with an outsider, which makes them an ambassador of sorts.
  - nawgz 5y ago
    > I'm claiming that both interviewer and interviewee have a similar workload I do not know what this means or what relevance it holds to our context. > and that usually only one party feels like they need to engage, the other is in a position of power and is the gatekeeper to 'the job' and so feels no need to engage Again, what are you saying? Recall, we are discussing the very silly claim that "you'll end up with team players but with nobody who will actually get the job done" based on an interview scenario where the interviewee is required to perform part of the problem-solving a job entails, just not a part which is not explicitly implementing a solution alone (coding). This language about the interviewer not "engaging" and "[not realizing] they represent the company" seems like an entirely separate conversation. Additionally, your usage of "I've seen this numerous times" and initial assumption that the interviewing company would "start off with insulting [the interviewee's] intelligence" don't really make me feel like you're discussing a good-faith interview, instead pre-supposing all interviews are performed in bad faith and interviewees are right to be offended by what they are being ask. I dislike this muchly, but indeed, the top of this comment tree addresses this attitude directly, something you entirely ignored: > [As an interviewer], I'm asking [each question] for a reason; you might think it's stupid, but I wouldn't ask if I didn't care what your answer was So I do not understand why you continued to go forward assuming the interviewing company is acting in bad faith. They are not, that attitude makes no sense, and the context has already directly been set for our conversation that the interviewer is asking this question in good faith because they believe it to be a signal wrt employee value. Please understand, as someone who interviews, one of the critical filters we introduced was evaluating candidates on their interactivity & collaboration. Doing this explicitly has resulted in a marked uptick in the quality of our candidates. Of course, we still aggressively apply filters that ensure these candidates can code and have implemented solutions of similar complexity & domain as we expect them to architect & create, but introducing the collaboration filter has resulted in coworkers of remarkable ability to solve problems quickly and continuously, both as individuals and in direct collaboration. I would easily say you would fail this filter entirely, and you should take care to not allow your bitter attitude to calcify.
lloydgrossman 5y ago
> So you'll end up with team players but with nobody who will actually get the job done. There are plenty of developers that are capable of writing code and explaining how and why they've done it. Your difficulty communicating ideas doesn't directly translate to being a better developer. >The better way is as the interviewer to do your homework and to engage on the level of the interviewee I'm not sure you've ever reviewed resumes, but they pretty frequently absolutely suck, targeted or not targeted, or otherwise not accurately representing skills. It can go from completely clueless "buzzword bingo" to "obviously I'm skilled enough to not need to mention the silly stuff like TCP" >Realize that your company is as much in the hot-seat as the candidate is. ...and for those companies that do understand that? Where is the substance to this comment? What stance are you taking or solutions you proposing?