it's also interesting that (anectodally, talking to people I know) the longer one's career is the more unlikely they are to want to switch jobs just based on having to deal with interviews, which of course makes it more likely they don't go for that cool interesting job they might flourish even more in, and makes it also harder for companies to hire as there are less available people around than there would be otherwise.
It's like, yes, you've spent 20 years in progressively more architectural roles, however the decision to hire you or not is based on whiteboarding algorithms you last had to legitimately write out years ago in university and crammed on for a few weeks before this interview.
While I was in university 20 years ago for fun I wrote an iterative AVL tree library in C (everybody else seemed to do it recursive), it was difficult but rewarding, but not something I am very likely to do nowadays and if you ask me to whiteboard the rotation logic I am not very likely to do it correctly and would have no impact whatsoever on my ability to do the job at hand (because in a working environment if somebody asked me to write for production say a red black tree from scratch I would not trust my memory but take out my Cormen book and go from there, or look at AOCP)
When I have interviewed in the past, I've always tried to ask more about the candidate's past and whys of certain decisions, if somebody put on their resume that, say, they designed an API for something, I might ask them what they did for versioning, for schema, what about atomicity, do they expose txns or not, drawbacks for each, and then branch out towards general concurrency and so on and on, you can learn a lot more about how somebody thinks by drilling down from something they worked on than by hazing them on algorithms 101
I actually enjoy going to interviews (and performing them). I'm less likely to switch jobs because of a perceived increased risk. I'm at a place with a good manager, good workload, and lots of stability. If I make a change (say, for more salary and more perks) I get, in return, an unknown manager, unknown workload, and unknown stability. As I get older, I have both more obligations and an increased risk of coming under the spectre of age discrimination. At some point the risks start to outweigh the benefits, as long as I'm not unhappy in my current position.
There are some companies that I won't even bother with anymore because it is pointless to go through their meat grinder interview process again and again. If you're already employed, you have basically 10 vacation days to blow each year, and I'll be damned if I'm going to blow another one on a day-long grilling where at the end they're just going to say, "Oh, looks like you didn't go to Stanford! Such a shame..."
I agree with your observation but I've always found that attitude a little odd.
If you find interviewing beneath you, what else about the job are you going to find beneath you?
Do you find it beneath you, or is that just some kind of excuse for a worry that you might not do well in an interview?
I've interviewed for various jobs tons of times over the course of my career and I've never minded a coding session (either on a whiteboard or an actual computer). They're never really all that hard. It's an easy way to show your stuff and give the company more confidence that you actually know what you're doing. It's not a big time commitment. What's the problem?
Many people have had a different experience from yours. Idiotic, irrelevant coding questions; clueless technical interviewers using the interview as an opportunity to stroke their ego, or having no idea of good questions to ask.
I don't consider interviewing "beneath me", but its a two-way street. I prepared for my job and this interview. If the prospective company shows a serious lack of skill/professionalism, its not only a red flag, its demoralizing, especially when they approached me. I've had this happen multiple times. I've also had great, well-considered experiences. Thank goodness.
Ya, you're prolly right that that I just haven't personally experienced much on the "opportunity to stroke their ego, or having no idea of good questions to ask" side of the spectrum. I think if I did though, I'd mostly just laugh it off? It would make it clear that I didn't want to work some place, and it's not like good engineers lack for opportunities these days.
Some people just seem to get UPSET about it though. I guess that's the real part I don't understand. Why the intensity? Not from you specifically, but from some folks.
you don't understand, I don't consider it beneath me at all, I mean, you have to interview somebody to know if they are a good fit, but I don't see why interviews have to be hazing rituals on things mostly unrelated with what they are supposed to measure.
If you've interviewed tons it means that interviewing and whiteboard coding algorithms is a skill you have developed and are keeping current (because you interview tons, so you do it often) so you actually enjoy "showing it off" given that it is part of your core competencies
I would love to do an interview where there is a genuine technical discussion on actual hard problems one might find in a job (say, expanding on my scenario above, what are the pros/cons if you design an API to expose txns, why would/wouldn't you want to do it, and mitigations/tradeoffs you would have to deal with in each scenario) what I wouldn't love is going for an interview with 20 years experience and being asked to whiteboard random algorithms off the top of my head unless I am applying for a position where that is required (hint: I wouldn't)
All I, and others, want is for interviews to reflect reality, where you ask me what I am good at, I show it by examples and answers, and then I ask you if what I am good at is a good fit for the position, where you ask me what type of environment I work best in (collaborative, go and do your own thing, agile, waterfall, ...) and I ask you what type of environment your company provides and if it's a good fit, and then once we figure out that yes, I can work here and what I can do for you is what you need, we have a mature discussion on compensation and it's all done.
Assume you decide to have a custom house built and are interviewing architects for the job, are you going to ask them for their portfolio, for their ideas on flow, for what architects are their inspiration, for how they would be able to make your ideas on how a house should be real, or would you put them in front of a whiteboard and ask them to draw a bathroom cabinet from scratch and fail them if they forget to put the stop on the rails so the drawer does not come out when you pull it out?
I guess maybe I've just been lucky (or perhaps have chosen which companies to talk to well) in that I've always had discussions closer to your "what are the pros/cons if you design an API to expose txns" example than "implement a red/black tree off the top of your head." Perhaps this is coloring my judgement.
Honestly if someone asked me to code a red/black tree, I'd probably say "I remember that term, but I don't for the life of me remember what it is exactly. If you want to give me part of the answer I can probably logic out the details on my own but I'm not going to do well on your memorization test."
Shit, that bit about the architect is fucking brilliant. I'm going to gratefully steal it and keep it close to my heart. I've done a bit of hiring and interviewing, and always try to keep it valuable and productive for the candidates, eliminating as much gruel from the process as possible. Sometimes, it requires convincing others not to do some nonsense they think is valuable. This is the perfect analogy for helping people understand.
It's not the feeling that it's beneath you, it's that it's illogical. If interviews made sense, nobody would have a problem with them. Until we find a way to conduct interviews in such a way that it can properly judge a candidates abilities, people will continue to feel this way.
>If interviews made sense, nobody would have a problem with them.
Not always. Interviews can be a very stressful and uncomfortable experience for some people. Even good interviews that make sense when the candidate is a perfect fit. Especially when you aren't job hopping and interviewing every two years so you're out of practice.
Honestly I don't even care to interview people, I'd much rather not.
I have been working in tech for a few years and have experienced a variety of company sizes and technologies (FTE and freelance).
What I will say is that in all these jobs, by an order of magnitude, the interview process was the biggest slog, and the most emotionally taxing part.
[wearing hiring manager hat]
The problem with demanding syntactically correct code on a whiteboard, as a test of developer ability, is the colossal false negative rate. Your personal data point doesn't generalise, sorry.
I went to an interview where the CIO commented on my incorrect syntax on the white board. Of the 2 other people in the room, 1 who would actually be the direct report for this position said that the compiler and resharper would have caught it so no big deal.
It's like, yes, you've spent 20 years in progressively more architectural roles, however the decision to hire you or not is based on whiteboarding algorithms you last had to legitimately write out years ago in university and crammed on for a few weeks before this interview.
While I was in university 20 years ago for fun I wrote an iterative AVL tree library in C (everybody else seemed to do it recursive), it was difficult but rewarding, but not something I am very likely to do nowadays and if you ask me to whiteboard the rotation logic I am not very likely to do it correctly and would have no impact whatsoever on my ability to do the job at hand (because in a working environment if somebody asked me to write for production say a red black tree from scratch I would not trust my memory but take out my Cormen book and go from there, or look at AOCP)
When I have interviewed in the past, I've always tried to ask more about the candidate's past and whys of certain decisions, if somebody put on their resume that, say, they designed an API for something, I might ask them what they did for versioning, for schema, what about atomicity, do they expose txns or not, drawbacks for each, and then branch out towards general concurrency and so on and on, you can learn a lot more about how somebody thinks by drilling down from something they worked on than by hazing them on algorithms 101