It really rubs my fucking rhubarb the wrong way when I am in a technical interview and the interviewer starts asking me some random assed questions either technical or voodoo doodoo mumbo jumbo personality type questions.
I understand they have to ask something in a interview but its the questions in of themselves that they choose that has me hanging the phone up on their hot ear.
After years in the industry I have come to the conclusion I am actually no longer employable! I am crankier than bag of cats on their period!
Where can i get a job as a programmer where class A assholes can apply? I mean with all this diversity and inclusion woke culture surely they can include me in their inclusion diversity quota . Assholes need to eat too you knoe, and the garbage cans are slim pickings these days i'm only getting pure slope now with all the grabbing hands!
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.
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.
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?
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.
Only bad places, where you'll work with other miserable people. Most good places have a "No Assholes Allowed" rule.
> After years in the industry
If you're jumping through all these hoops after years, you might not be as good as you think you are. You make up for the ego hit by thinking interviews and the questions they ask are beneath you. When really, they're doing exactly what they're intended for. Weeding out asshole developers that think they're better than they are.
I've worked with/under/managed tech gods who were dicks and I would work with normal people who aren't at that tech level 10/10 times. I am worried with the current direction towards remote work there will be more space for assholes.
blizzard, amazon, apple, facebook and to a certain extend microsoft are filled with assholes and foster that culture, yet are considered good places to work at (for a long time at least)
1. If they want me to napkin code, I call it quits immediately, even if I know the code they want me to write be heart. Watching me write code on a whiteboard or piece of paper has no demonstratable connection to how I work day-in and day-out. Places like this would be both a waste of their time to hire me, and a waste of my time to interview for. I always ask up front about this if I'm unsure how the interview goes.
2. I set myself up to control the interview. I bring my laptop, ready with a bunch of work I've done that I can show off. When I sit down, I ask "Hey, I brought a bunch of interesting projects that I can show off, is that alright?" If they aren't interested in seeing that, they are clearly not interested in the sort of work I do, and not interested to see how I can fit into their team.
3. Ask what their typical day is like. This includes asking what the most painful part of their day is.
4. I want to know specifically who I need to talk to and who would need to talk to me to finish my work. The higher the number of people I need to talk to, and the lower the number of people who talk to me is a real bad sign. Reporting to and trying to appease multiple bosses with completely different goals and timelines is bad. Also, if there is no one under me, then job clearly doesn't respect or desire mentorship.
Sometimes I skip some of these steps, and obviously your mileage will vary, but always ask the questions that give you answers to how you like to work. For instance, if you want a cubical and want to put on headphones, ask about the office layout, and what expectations the company has for your communication abilities.
Still that kind of coding environment can get annoying, so maybe you're trying to avoid those aspects too :) Personally now have enough money where I have zero interest to participate in those kind of employee environments, it's not something I'd choose to do and am happy to have exited it. Only want to work on own projects and ventures on own terms.
Anyway, that's why my policy is to just say no to whiteboarding during interviews. I'd rather sit at a computer with another human who wants to see me succeed over stand at a whiteboard with people that want to dissect how I think.
Drawing an architecture diagram or so, sure, but code? I would definitely prefer to work with people who know how to do screensharing and work over a problem in the code using an actual editor.
If they do standups, see if you can sit (edit: er, stand?) in on a couple before you say "yes" to an offer. You can spot most of the worst agile pathologies pretty fast that way, and since those can reach "making me an anxious wreck 24/7" levels of bad, you definitely want to know.
Annually raise your fee by 25%. You'll find better paying gigs with companies that appreciate you even more.
btw: since this post serves as a one-person who wants to be hired: your website is down.
My brand is hard truths.
Unfortunately, not many people want that product. But just enough do to keep me employed.
That would be a very interesting startup.
These were both technically brilliant but would backstab, take credit for others work, deflect blame, even include customers on copy when scolding me etc, so I'd definitely classify them as Class A A##holes.
BTW: Are you sure you qualify as Class A? The kind of technical brilliance these guys had, combined with such utter lack of respect for others and also the galls to be totally open about not respecting others, that is quite rare...
I live by a moral code, but many have called me an asshole, because I will say “you don’t know what the hell you are doing” to people I believe are incompetent (instead of smiling wanly). But I don’t steal credit or tell lies.
I (try to at least) make sure that I praise in public and correct in private as far as possible, and I work on a team that does the same.
That said, even when I worked with certain Class A's mentioned above I was happy to take advice as long as it could go both ways.
When it turned out it was also "rules for thee, not for me" I got another job.