>We don’t do a really good job of hiring with intent. We decide that we need more people, but we don’t do a really good job of figuring out what we need those people to actually do, and who we actually need to hire. I don't understand what she's talking about here. Every time I see a job opening, the software hiring manager and the team peers know there's a pain point that needs to be solved. E.g. "We need to an embe…
I'm hiring right now, and I read a lot of job descriptions before I wrote ours. [1] I've definitely seen what she's talking about: generic go-hire-engineers job descriptions. I also think the kind of thing you describe, hiring for a very specific technology, is a similar failure mode. The technological pain point of the moment rarely lasts; the more stable needs are actually organizational. For example, over the next…
We’re Bad at Interviewing Developers – Interview with Kerri Miller
41–50 of 101 posts
Re: We’re Bad at Interviewing Developers – Interview with Kerri Miller
#42Earlier quoted context omitted.
Depends on the individual's preferences and life situation. I was offered a contract-to-hire position earlier this year, and turned it down because the contract term happened to coincide with the expected birthdate of our third child. Even though I was confident that I would succeed in the position, I didn't want to deal with any uncertainty around that date. Also, in the United States, health insurance is usually ti…
Also if I were employed at a good company but was possibly interested in leaving, I would never leave it for a contract-to-perm position.
I hear this position often when people talking about contract-to-perm, and I just don't see it. If you're good at what you do, and people enjoy working with you, why wouldn't you take a contract to perm position? The only reasons I can see are that you are afraid you don't get the job (well, then you wouldn't have been a good fit if they hired you) or you end up not liking the team/company as much (same as if they had hired you.)
So, why wouldn't you? And I don't buy the 'I have a good job' line, because you wouldn't even be entertaining offers if you weren't interested in leaving your current role.
Re: We’re Bad at Interviewing Developers – Interview with Kerri Miller
#43Contract to perm is the best way by far. In the UK the contract rates are typically significantly higher, so even if the person isn't offered a job at the end they aren't bothered. Everyone wins
Isn't it probably also due to the fact that the UK offers unemployment and healthcare benefits that far surpass what is offered here in the States? So that there is a safety if at the end of the contract you are left with no offer.
Re: We’re Bad at Interviewing Developers – Interview with Kerri Miller
#44Contract to perm is the best way by far. In the UK the contract rates are typically significantly higher, so even if the person isn't offered a job at the end they aren't bothered. Everyone wins
For whom?
It's bad for the worker because you're going to work for a company that is admitting by its behavior that it has little confidence in its abiliity to assess talent. Where else is it weak? (My experience shows that those who can't assess talent usually can't do a whole lot of other important things, too.)
It's bad for the company because it limits its pool of candidates. Good luck recruiting desirable high achievers by telling them you can't tell if they're good enough to hire.
Assessing talent and determining long term resource requirements is like anything else in I.T.: it's fundamental and must be mastered to become any good. Contract to perm is a red flag that something is wrong.
Re: We’re Bad at Interviewing Developers – Interview with Kerri Miller
#45Testing for communication skills is awesome advice and probably rarely ever consciously focused on.
As a related note, the best predictor of university physics scores is high school English scores. Why? Because physics is about making a conceptual model. i.e. telling a story about a problem. And then solving it. For interviewing, communications skills are a must. People will be working in a team, and must be able to explain themselves. And get along with others. Another thing rarely checked for is the flip side...…
Likewise, the best predictor of on job performance is on job performance.
If this isn't a recent grad, interviewing on the resume will tell you more any proxy for on job performance. Sure, people may be seeking to step up from a drudgery type job, but I think that usually comes out (citation needed, I admit). "I wanted to replace the terrible X with the wonderful Y, but I was over ruled".
"question about why this was rational".
"rational explanation ensues"
"want a job here?"
I admit it ain't perfect, people lie on resumes and take credit for other people's work, but we all know the whiteboard tests and other things are just voodoo. Google's hiring data proves it out - only one person in their company was able to give better than chance ratings based on interviews.
And, who really cares about resume inflation? I'm scrupulously honest in my resume, but if someone can describe all the trade offs, costs, and benefits of an architecture from a previous job, and answer speculative questions about it ("what would you change if you needed to scale X"), then heck, they can probably do the job. If I understand engineering and am an active contributor, what more do you want? No, "doesn't get nervous during a highly artificial situation of whiteboarding" is not a rational want, since it will not add 1 dollar to your bottom line.
Re: We’re Bad at Interviewing Developers – Interview with Kerri Miller
#46That is, they may treat you like a rockstar when they sign you, but then if you complain because you got a crappy Dell laptop that was a hand-me-down from a salesman who couldn't sell, that your build process takes 40 minutes and that this could cut that to 20 minutes. Of course they have the "sick system" excuse that there is no money, but you get blamed for complaining about the 40 minute build, and then you get blamed that it takes forever to do anything because you are always waiting for that 40 minute build to finish and the system is such a house of cards that if you work on anything else in parallel whatever you would have learned from that 40 minute build is invalidated.
Re: We’re Bad at Interviewing Developers – Interview with Kerri Miller
#47Earlier quoted context omitted.
Also if I were employed at a good company but was possibly interested in leaving, I would never leave it for a contract-to-perm position.
Do you doubt your skills? Why are you interviewing if you're employed at a good company? I hear this position often when people talking about contract-to-perm, and I just don't see it. If you're good at what you do, and people enjoy working with you, why wouldn't you take a contract to perm position? The only reasons I can see are that you are afraid you don't get the job (well, then you wouldn't have been a good fit…
Or, you rubbed the wrong, politically-connected person the wrong way. Yes, this is always a danger, but a contract employee is more expendable and easier to get rid of.
Or, they weren't really looking for a permanent hire and this was just a means of tricking someone into a contract who wouldn't otherwise take one.
Or, the company hits a rough patch and decides to freeze hiring to avoid layoffs.
There are a whole host of things that could go wrong in a contract situation that are either tempered or nonexistent when you are permanent.
Re: We’re Bad at Interviewing Developers – Interview with Kerri Miller
#48Contract to perm is the best way by far. In the UK the contract rates are typically significantly higher, so even if the person isn't offered a job at the end they aren't bothered. Everyone wins
Contract to perm is the best way by far. For whom? It's bad for the worker because you're going to work for a company that is admitting by its behavior that it has little confidence in its abiliity to assess talent. Where else is it weak? (My experience shows that those who can't assess talent usually can't do a whole lot of other important things, too.) It's bad for the company because it limits its pool of candidat…
You seem to think that willingness to admit that assessing fit for a particular job is unreliable without actually experience of the candidate working in the real conditions is correlated with the relative degree to which the company is unable to assess such skills relative other companies (rather than being driven by the degree to which the company is aware of difficulties affecting all companies hiring for similar jobs, or differences in the features of the specific job which make assessment difficult.)
There is no justification that I can see for this assumption.
Re: We’re Bad at Interviewing Developers – Interview with Kerri Miller
#49It tires me that there is so much talk about the problem of hiring developers and very little about the problem of "what do you do once you hire them?" That is, they may treat you like a rockstar when they sign you, but then if you complain because you got a crappy Dell laptop that was a hand-me-down from a salesman who couldn't sell, that your build process takes 40 minutes and that this could cut that to 20 minutes…
Re: We’re Bad at Interviewing Developers – Interview with Kerri Miller
#50It tires me that there is so much talk about the problem of hiring developers and very little about the problem of "what do you do once you hire them?" That is, they may treat you like a rockstar when they sign you, but then if you complain because you got a crappy Dell laptop that was a hand-me-down from a salesman who couldn't sell, that your build process takes 40 minutes and that this could cut that to 20 minutes…
Every company I've interviewed at definitely seemed to make developer happiness a priority (especially the smallest ones). Even the smallest of startups (ie. one guy with a tiny seed round) understand that buying your developers great gear is an essential investment.