Of course it's not good, it's magic disguised as science.
It's theoretically possible, but we're nowhere near the level of tech to be able to pull it off.
It's basically a money grab.
250 karma · joined August 22, 2020
It's theoretically possible, but we're nowhere near the level of tech to be able to pull it off.
It's basically a money grab.
The fact that the internet exists and the interviewer could have used an online utility doesn't change my responsibility in that equation, that's just nuts.
It was a VPS automated deployment system that could deploy both windows and linux to various datacenters around the world while also installing some 50+ pieces of software (as configured).
What I said was that "movement" was a building block of life and your response was "no, cause if you do polka-STYLE movement while trying to lay bricks, you'll FAIL".
Right, but what they both have in common is movement. The fact that you felt the need to add style is exactly why I'm correct.
But also, I really really dislike when others talk about "optimizing" people. It's not possible to optimize your hiring process for anything useful. Due to this, there should be a lot more empathy in the hiring process than their actually is because everyone wants to make it robot-like by "optimizing" something.
The company itself wasn't actually solving complex problems and therefore the developers involved couldn't actually understand the level of complexity I was able to deal with.
I get the feeling a lot of developers believe dealing with state in a react app is a complex problem, but I've been doing this stuff for 25+ years and left that behind as complex long ago. I know that's probably going to come across as arrogant, but it's how I feel about the entire thing. I see people all the time squabbling online over very specific source code related things as if they're important.
Technically speaking, if we're in an interview to "optimize for the right thing", then we would just have them come in and type.
But we all know that's also optimizing for "the wrong thing" despite it being what we do physically day in and day out.
This is because you _CAN'T_ "optimize for the right thing" in an interview. It's not possible and this needs to be acknowledged.
Therefore you go for something else. Anyone who is a software developer can listen to a 5-10 minute presentation from another developer and start forming general, broad opinions. They can then start asking questions afterwards to help clarify those opinions.
But the Q&A also has another purpose. Way too often interviewers will come to conclusions that don't follow (non-sequitur). I once had someone tell me they didn't feel I would be a team player because I told them as long as I had headphones, open office would be ok. The main difference I've found between business people and technical people is that business people will ask clarifying questions. The Q&A sets the expectation for the _INTERVIEWER_ to ask clarifying questions.
You know what's unreasonable? Interviewing a bricklayer and asking them to describe how they lay bricks over the phone. And this is why your comparison to singing is hugely flawed. The phone is literally designed for carrying and hearing voices, not for more complex things.
You act as if it's literally impossible to figure out if someone can code unless you're trying to do it over the phone.
> This line from your comment is interesting to me though: "I've seen people actively be wrong in what they're looking for, as in technically wrong and therefore I failed". I frequently ask questions where I expect the candidate to want to clarifications or challenge what I'm saying.
I once had someone ask me what _type_ was returned from a controller in asp.net MVC, and when I gave the technically correct response this person told me I was wrong, a view is returned, then immediately ended the call. The number of times I've seen stuff like this happen is way too high.
But more than that, I want to address the attitude in that last point. This is a _HUGE_ problem with interviewers. They often come to conclusions they ought not come to based upon the circumstances. And the defenseless interviewee's are left trying to suss out hidden requirements like "expects them to ask clarifying questions". Interviewee's come in and have to try and navigate these byzantine, hidden requirements. And the question is, why do interviewers have hidden requirements like this? Because they know if they're _HONEST_ and communicate what they're looking for, the candidate will give it to them. That by itself should be a wake up call that interview's are hostile and un-real.
I'm just in a position in my career that I have the leverage to refuse to play those games. If you do something like that, you fundamentally have no clue how to actually hire people, and I refuse to bring any value to you or your company.
1. Those are the building blocks of software, and
2. They don't stop being useful when you move from domain A to domain B
If there's one thing I don't want to do, it's work by assignment. I'm not a school kid, I'm a professional software developer. I'll tell you what needs to be done. You can inform me of the goals you have for the company, and I'll make sure that happens.
What I'm saying is that despite all my successes, you would consider me a 'dud'.
At the end of it the biggest burning question they had was "where are the unit tests". I was like ... you see this circle here with this label inside it? This was critical to the entire system and therefore had unit tests surrounding it.
didn't get the job, they seemed kind of annoyed that I didn't get into great detail about things like unit tests and instead talked mostly about the architectural problems I solved.
I wish companies actually valued that level of knowledge.
Because they disqualified themselves from hiring me. What I remember from that phone screen was getting mentally _TIRED_, sighing, and then lying about not being able to do it.
Seriously, don't fucking ask me to describe code or algorithms over the phone. The number of times I've had someone do some variation of this over my lifetime is such that I don't want to have you as a co-worker or a manager.
Do you know why I have this attitude? Because the number of times I've seen people actively be wrong in what they're looking for, as in technically wrong and therefore I failed, is enough that I've decided if you think this is the right way to go about hiring, you're doing it wrong and I don't want to be in that hellhole.
It allows your company to learn, to get a feel for the person's ability to communicate, and to stay away from stupid things like tests.
It's also easily the best interviewing process I've ever experienced.
---
edit: Since it appears that multiple people have taken this to represent an hour+ long presentation, let me clarify here.
A better way to think about this would be a long-form discussion about a topic. The initial "talk" would be 5-10 minutes, with a Q&A afterwards to ask for clarifying questions.
I've been working in this field for over 25 years. I spent roughly 30 minutes of prep for the interview and it was easily the best interview process I've ever experienced.
There's a habit of technical folks to come to conclusions they shouldn't, and this is a perfect example. It generally manifests itself in interviews where the technical interviewer will come to conclusions that don't necessarily follow, only in this case it's not in an interview, but with respect to fellow co-workers.
I mean, you can see the hubris in the poster, who would have you believe that they're somehow "training" their management to "spot poor co-workers". Yeah, ok.... sure you are. Because managers are like monkeys apparently?
Oh also...
-- I have deleted a long comment I was going to reply with as I'm sure you are not open to hearing actual counter arguments. I don't want to waste my time. --
My reply instead is to read more carefully, think more carefully, and do not throw puerile thoughtless sentences out like the last one in your reply above.
Weird... it seems I too can go with the better than thou act.
Wikileaks would time their release of information for political effect.
It's not that I'll outright refuse to use a header-only lib, only that I very very strongly prefer not using them.
In my current vehicle I can change stations without taking my eyes off the road, I don't feel as if I'd be able to do that if it were on a touch screen due to the lack of tactile feedback.
Also, I've rented a few vehicles and I've never seen one that didn't have things like A/C on the touch screen, which is part of why I've formed the opinion I have. OTOH, what I've rented are minivans, where A/C is a bit more complex since it will often have a "driver/passenger" dichotomy as well as a "front/back"dichotomy.
I just don't want to be interacting with it in a touch screen way while driving.
the average loan for a new vehicle is 3-5 years. Is it your belief that you're likely to default on that loan, therefore why would you learn the system in your vehicle?
The average ownership length for a car is roughly 6 years. Taking the time to learn a system that you'll have for anywhere from 3-6 years is completely reasonable.
This is the very definition of #firstworldproblems.