@patio11's starfighter project could help this...
We’re Bad at Interviewing Developers – Interview with Kerri Miller
21–30 of 101 posts
Re: We’re Bad at Interviewing Developers – Interview with Kerri Miller
#22Contract 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
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.
Re: We’re Bad at Interviewing Developers – Interview with Kerri Miller
#23>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…
If you "need a developer to port the Java code to Go", you need a contractor. Once the Java code is ported to Go, they're done, and there will be no more Java code to port to Go, so... why would you hire a permanent employee on the basis of their ability to port Java code to Go?
The point of a permanent software development teammember is to add to the capabilities of your engineering staff. What is it you want them to add?
What I think she means by 'hiring with intent' is this - identify what you need to add to the team to create the kind of team you need. That could mean someone with more follow-through, or someone who will explore and innovate more. Someone with big-picture systemic thinking skills, or someone detail-oriented who will sweat the little things.
Re: We’re Bad at Interviewing Developers – Interview with Kerri Miller
#24As a non-CS graduate looking for my first full-time job as a Junior Developer I can only ask one thing of prospective employers. Please give clear feedback that will help give direction to the candidate if you reject them.
I have done a number of code challenges and while I don't mind doing the challenges (I look at them as training) and I can always create a working solution there is nothing worse than receiving a simple 'we won't be continuing with your application' email with no other feedback. If you are going to take up a candidates time with a code challenge the least you can do is help the candidate become a better developer by providing constructive feedback. You owe it to the applicant and also to the community at large.
I have had about a 50/50 experience in this regard. Of all the companies that reject me with good feedback I am left feeling content that I have improved as a candidate throughout the process. The others who don't provide feedback leave me feeling like I've wasted some time that would be better spent reading about best practices and techniques or developing my own software.
Re: We’re Bad at Interviewing Developers – Interview with Kerri Miller
#25I love the idea of asking the candidate to "teach me something, preferably something nontechnical."
It sounds like a great way to test for communication skills while also learning something about the person's interests. Plus it could make the process a lot more fun for the interviewer.
However I expect it would depend as much on the personality of the interviewer as on the interviewee. And at least in the US, it could have legal implications if you decide not to hire someone because they didn't have anything "interesting" to teach you.
Re: We’re Bad at Interviewing Developers – Interview with Kerri Miller
#26Earlier 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 came into my current position as a CtH, but that was only because I was laid off at the time. So with CtH, you either get people who want to stay contractors, or people who are unemployed.
Re: We’re Bad at Interviewing Developers – Interview with Kerri Miller
#27As a non-CS graduate looking for my first full-time job as a Junior Developer I can only ask one thing of prospective employers. Please give clear feedback that will help give direction to the candidate if you reject them. I have done a number of code challenges and while I don't mind doing the challenges (I look at them as training) and I can always create a working solution there is nothing worse than receiving a s…
I typically give smaller challenges and review with candidate in real time via google docs. There's no type ahead but the challenges are more about understanding the approach to solving rather than if it compiles. One can argue the value of arbitrary tasks, but I've found that it certainly gives me good feedback to how someone writes software from self refactoring, following a perceived coding standard, and if they attempt to test there code. Just my take
Re: We’re Bad at Interviewing Developers – Interview with Kerri Miller
#28As a non-CS graduate looking for my first full-time job as a Junior Developer I can only ask one thing of prospective employers. Please give clear feedback that will help give direction to the candidate if you reject them. I have done a number of code challenges and while I don't mind doing the challenges (I look at them as training) and I can always create a working solution there is nothing worse than receiving a s…
Some companies are loath to exposing themselves to any kind of litigation. And to some extent, it's understandable. Some people can feel deserving and that someone turned them down because something about them personally rather than their direct abilities. And there is truth to both sides. Some employers discriminate on irrelevant things, and some employees have bad attitudes (personalities) or are simply incompetent.
Still, as an individual, I am resistant to the current tend where employers look for "someone we'd like to hang out with". I have a life, I don't share the same interests of a recent grad. When I was a recent grad I didn't like the collegiate attitude anyway. So, it's off-putting, but it's a big filter nowadays. It's let's have lunch with the team so you can get to know them....
Re: We’re Bad at Interviewing Developers – Interview with Kerri Miller
#29Earlier 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.
I came into my current position as a CtH, but that was only because I was laid off at the time. So with CtH, you either get people who want to stay contractors, or people who are unemployed.
That was my situation. After spending a the better part of a decade in other positions, I was trying to get back into a full-time dev position.
Re: We’re Bad at Interviewing Developers – Interview with Kerri Miller
#30>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…
If you "need a developer to port the Java code to Go", you need a contractor. Once the Java code is ported to Go, they're done, and there will be no more Java code to port to Go, so... why would you hire a permanent employee on the basis of their ability to port Java code to Go? The point of a permanent software development teammember is to add to the capabilities of your engineering staff. What is it you want them t…
>If you "need a developer to port the Java code to Go", you need a contractor. Once the Java code is ported to Go, they're done, and there will be no more Java code to port to Go, so... why would you hire a permanent employee on the basis of their ability to port Java code to Go?
My examples are being interpreted too literally. They are not tasks that must literally go into the job description. Instead, they are bullet points of internal thinking as to what the additional programmer will do. He/she will convert the Java code; and can also refactor the batch data load, and add 2-factor to customer logins, etc. A laundry list of "things to do" gets built up and it justifies another full-time employee. However, sometimes one item such as "make website scale to 1000x users" can be so large in scope that it will require many FTEs just to work on that one objective.
I've just not seen a situation where a team would hire a new developer and he/she just sit there for days and weeks twiddling their thumbs because the company doesn't know what to do with them. Yes, the new programmer may do nothing because of bureaucracy (IT hasn't created userids yet, repository access not granted, etc). Other than that, the hiring manager usually has a an idea of how the new programmer is supposed to add value.