@Zenith said in interview attire 2019:
Not on the first. I'm writing computer code to execute a process, not laying out a magazine page. If baby can't read Pascal casing or Allman brackets, that's baby's problem. "Readability" is also more of an issue when you don't document your code or it has to be fixed over and over and over. The sort of developer throwing rocks at my work would be lucky to live in a glass house on both fronts.
It comes off as fairly hostile, or at least giving the impression of "rock star". The wording sounds like "Are you going to let me do real work, or just a bunch of fucking useless bullshit?"
It says to the interviewer "I am not only stubborn about my way being the right way, but I will refuse to do work any other way". Not a team player-- and if you're that adamant about something like bracket placement, what else are you going to dig your feet in for? Is hiring you just going to be a struggle / fight every time?
And saying "do I get to do this good thing, or only this shitty thing" is extremely dismissive of anything that isn't "this good thing". A non-techie could take it as "oh, he's one of those programmers who looks down on everyone else". A programmer might think "is he just going to dump code and expect us to figure it out". Maybe there's the person who actually wrote the style guide interviewing you. Or there is (almost certainly) a history of no-longer-employed-there programmers who did just diarrhea out a bunch of code, and they spent hours or days trying to read it. Are you going to be making maintainable code?
@Zenith said in interview attire 2019:
Second, slightly. Why shouldn't I ask how my time would be divided between meetings and work? Meetings are almost universally a waste of time.
.... and interview is a meeting.
It's also a overly hostile "thing I want to do, or utter bullshit" dichotomy. Do they want to put up with eye rolls and "uhhhhg, fine" every time there's a meeting? If you are dismissive of all meetings, then is that a reflection on your ability to prioritize? Sure, some meetings aren't as valuable as others, so will you be valuable in the ones that they do have? It also says "I don't consider anything other than coding to be real work". If you're presenting yourself as "not just a janitor", then you have to be involved in other aspects of development than just typing. Planing, scoping, working out requirements with clients, kickoff meetings to go over business requirements, validating business requirements from a technical point of view.
Very few places want "just someone who will sit there and code". You seem to be very disparaging about H1Bs, yet want to do the same thing they do.
Asking about "What would my typical day / week look like" is more on point. Let them tell you what your responsibilities would be. It's their job to sell the position to you / woo you. If they lay out a day full of nothing but meetings, etc, then you can make your decision without coming off as hostile. Or you can show interest by asking follow up questions. "So that morning progress meeting, what goes on in there? Is it everyone, or just a few people?"
@Zenith said in interview attire 2019:
Third, yes, this is paraphrased. Sometimes it comes out as "what happens if I find a bug in the code? do you have bug reporting facilities?"
That's better wording.
@Zenith said in interview attire 2019:
've had jobs where the underlying "framework" was full of bugs that impeded my work. Parts outright didn't work, the owner wouldn't fix them (locked repository), and I was scolded for working around them after a meeting where "we" were scolded about missing yet another deadline.
Find a diplomatic way of saying that, and you have your prepped answer for "Tell me about a time when you hit a major roadblock, or missed a deadline, because of external factors".
@Zenith said in interview attire 2019:
Fourth, as often as I've been told "fix this without changing anything or else," I don't want stuck doing just maintenance work.
"Is he going to come in and just spend all his time rewriting the codebase we've developed over the past decade?"
Maintenance and bug fixing is an integral part of any codebase. It's very rare for someone to work exclusively on new features / projects, and never existing code (or their own older code).
The only way I can ever hope to advance is to do a project my way and show superior results.
See above re: overly hostile and dismissive of things that don't meet your standards. Especially if you're hinting that the only way to advance is to stomp on the work of others.
(FYI: I'm presenting all of the above as someone who does do the majority of interviews for developers at my company. You obviously have a very specific goal in mind for the job you're hunting for. But even if you are interviewing for that perfect job-- low meetings, lots of new projects, good bug tracking tools, etc-- you can still snatch defeat from the jaws of victory with a bad interview)