3 ms·
You claim developers that are show skills of collaboration thru acts like vocalizing their thought processes, ensuring mutual understanding of a problem, brains
by 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 agoNo, 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.