3 ms·

Interviewer's notes: anal_reactor is stubborn, difficult to work with, has little regard for others' opinions, not a team player. Do not recommend hiring.

by bitwize 2mo ago

anal_reactor 2mo ago
Not wrong, especially at the time. I excel when I'm given my own chunk of job to work on with certain degree of freedom. I don't butt uninvited into other people's decisions, I expect others to do the same with me. I totally suck at meetings where the goal of the meeting is to make sure that everyone feels like their voice is being heard. IMO diving people into small groups, sometimes groups of one, with API between them, is the correct way of managing employees. I really dislike the "everyone does everything" paradigm that my current workplace applies because the end result is that there is no design, we just keep stacking features until something gives, and then we have a project "someone please unfuck the application".
- sgarland 2mo ago
  > I totally suck at meetings where the goal of the meeting is to make sure that everyone feels like their voice is being heard. Those are the worst. No, I don’t feel like I need to let Bob feel heard. Bob wants to create a nightmarish stack involving ElasticSearch and Kafka for a problem that grep and a flat text file could realistically handle. I have already explained to Bob that his solution is unnecessarily complex.
  - bitwize 2mo ago
    But is your solution scalable? Resilient against injection attacks? What about o11y? Is literally anyone besides you going to be running these searches? If so, you're going to want to put a UI around it and that means thinking about scalability, data sanitization, and o11y. Maybe Bob knows something about the scope of the problem that you don't? Look mate, software is business and business is marketing. If your solution really is better, you need to market it as such, even to the Bobs of the world. Especially to the Bobs of the world. If you couldn't present it in a way such that it's obvious to Bob and everybody else that your solution is better, that's a failure on your part, not Bob's, the other participants', or the meeting organizers.
    - sgarland 2mo ago
      It is not my responsibility to teach critical thinking and a CS degree to Bob, nor is that in my job description. If Bob can successfully convince our boss and finance team that his solution is necessary, then so be it; I will continue banging my head into the wall. A real anecdote: I once had to explain to other software engineers, during a retro, that the aggregate bandwidth their queries demanded for the result set was far in excess than that of the DB’s capabilities. “This would’ve required 230 Gbps, assuming the DB could’ve fulfilled it.” … “That’s more than a typical top-of-rack switch.” … “It’d be like filling 69 Blu-Ray discs every minute.” “Ohhhhh.” The switch analogy may have gone over their heads, admittedly, but the fact that 230 Gbps on its face didn’t sink in is distressing. Entirely too many devs don’t understand any fundamentals, and as such they can’t do basic back-of-the-envelope calculations, and we wind up with Bobs.
    - anal_reactor 2mo ago
      > If you couldn't present it in a way such that it's obvious to Bob and everybody else that your solution is better, that's a failure on your part, not Bob's, the other participants', or the meeting organizers. I invite you to go to any Arab country and tell them to legalize gay marriage.

Interviewer's notes: anal_reactor is stubborn, difficult to work with, has little regard for others' opinions, not a team player. Do not recommend hiring.

by bitwize 2mo ago

Interviewer's notes: anal_reactor is stubborn, difficult to work with, has little regard for others' opinions, not a team player. Do not recommend hiring.

anal_reactor 2mo ago

Not wrong, especially at the time. I excel when I'm given my own chunk of job to work on with certain degree of freedom. I don't butt uninvited into other people's decisions, I expect others to do the same with me. I totally suck at meetings where the goal of the meeting is to make sure that everyone feels like their voice is being heard. IMO diving people into small groups, sometimes groups of one, with API between them, is the correct way of managing employees. I really dislike the "everyone does everything" paradigm that my current workplace applies because the end result is that there is no design, we just keep stacking features until something gives, and then we have a project "someone please unfuck the application".

sgarland 2mo ago
> I totally suck at meetings where the goal of the meeting is to make sure that everyone feels like their voice is being heard. Those are the worst. No, I don’t feel like I need to let Bob feel heard. Bob wants to create a nightmarish stack involving ElasticSearch and Kafka for a problem that grep and a flat text file could realistically handle. I have already explained to Bob that his solution is unnecessarily complex.
- bitwize 2mo ago
  But is your solution scalable? Resilient against injection attacks? What about o11y? Is literally anyone besides you going to be running these searches? If so, you're going to want to put a UI around it and that means thinking about scalability, data sanitization, and o11y. Maybe Bob knows something about the scope of the problem that you don't? Look mate, software is business and business is marketing. If your solution really is better, you need to market it as such, even to the Bobs of the world. Especially to the Bobs of the world. If you couldn't present it in a way such that it's obvious to Bob and everybody else that your solution is better, that's a failure on your part, not Bob's, the other participants', or the meeting organizers.
  - sgarland 2mo ago
    It is not my responsibility to teach critical thinking and a CS degree to Bob, nor is that in my job description. If Bob can successfully convince our boss and finance team that his solution is necessary, then so be it; I will continue banging my head into the wall. A real anecdote: I once had to explain to other software engineers, during a retro, that the aggregate bandwidth their queries demanded for the result set was far in excess than that of the DB’s capabilities. “This would’ve required 230 Gbps, assuming the DB could’ve fulfilled it.” … “That’s more than a typical top-of-rack switch.” … “It’d be like filling 69 Blu-Ray discs every minute.” “Ohhhhh.” The switch analogy may have gone over their heads, admittedly, but the fact that 230 Gbps on its face didn’t sink in is distressing. Entirely too many devs don’t understand any fundamentals, and as such they can’t do basic back-of-the-envelope calculations, and we wind up with Bobs.
  - anal_reactor 2mo ago
    > If you couldn't present it in a way such that it's obvious to Bob and everybody else that your solution is better, that's a failure on your part, not Bob's, the other participants', or the meeting organizers. I invite you to go to any Arab country and tell them to legalize gay marriage.