Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFD 151 Assessing software engineering candidates #114

Open
bcantrill opened this issue Oct 5, 2018 · 4 comments
Open

RFD 151 Assessing software engineering candidates #114

bcantrill opened this issue Oct 5, 2018 · 4 comments

Comments

@bcantrill
Copy link
Contributor

@bcantrill bcantrill commented Oct 5, 2018

While RFD 151 is in a "publish" state (as in reflects several iterations of internal discussion), this remains an evergreen topic on which many in the industry have different perspectives: we wish to explicitly leave this issue open to encourage discussion of the approach outlined here -- and to give ourselves the opportunity to improve the RFD accordingly! Comments and discussion welcome!

@jbogard
Copy link

@jbogard jbogard commented Oct 5, 2018

Really glad to see this published publicly! Too many companies keep their interview process opaque/private, like it's a game to win.

On the coding aptitude, we've tried to create as level as a playing field as possible - accounting for different backgrounds, schedules, commitments both inside and outside of work, etc. Coding in person proved to be a negative filter - the added pressure and stress meant we were eliminating bad and good candidates.

Open-ended coding assessments were shown to be too restrictive of a positive filter - it only let the good candidates through who also had significant time to dedicate outside of their normal job. Which meant that some folks in a terrible current situation, working very long hours, did not have long stretches of time for this.

So we blended both. A take-home exercise that can be completed a little at a time. Uniform for everyone to remove any requirement on a specific technology. Problems that steadily grew more challenging in terms of design, so that we could objectively determine depth of skill. And on the plus side it proved a great negative filter for those with big egos - who thought they were too good for a coding test :)

Another thing we learned the hard way - don't give direct feedback to a candidate on why they are not moving on in the process. Even when we felt really good about doing it, it always ends badly, no matter how empathetic we are.

@bcantrill
Copy link
Contributor Author

@bcantrill bcantrill commented Oct 5, 2018

@jbogard: Good thoughts! And yes, this is broadly our experience as well. In terms of giving feedback to candidates: absolutely agreed -- which is why we put so much back on the candidate themselves. (Most candidates don't move forward for a very simple reason: because they lose interest. It's amazing how many candidates who are supposedly excited about working for us never bother to follow up with answers to such basic questions!)

@mrp149
Copy link

@mrp149 mrp149 commented Nov 12, 2018

In the practical case, I found this RFD to be very useful. For me, it seems like goodwill to make the hiring process open and transparent for both parties. Technology, whatever it is, is just technology. The most important element of any development is that the team (of individuals) is driven by the same idea. Keeping the team in good “health” is one of the difficult parts of any development, because ideas may be the same, but a variety of individual goals makes the team very fragile. Thus, the elevation of this standard at the very beginning of interaction with a potential team member is the right decision - the transparency is a great tool, and it helps to create a true team spirit.

@jeffallen
Copy link

@jeffallen jeffallen commented Feb 13, 2019

I am currently hiring someone for my team, and I found this very helpful. Happily, we have already put in place some of these things.

In a large organisation, it can happen that there are many job openings, and it's not exactly clear where the candidate should be hired. The attendees of the post-interview meeting must not make a qualified "hire" recommendation like, "hire, but not in my group". This sounds obvious, but it is a rule taught to me by people who had seen it happen, and who had seen the damage it could cause.

It is very helpful to hold yourself and your colleagues to the standard that there is only "hire" and "do not hire". The razor edge between those two choices requires you to look deeply into the evidence you've collected and make a real decision. I really like the formulation of "insufficient info" to explain what is needed to get off the fence.

The hiring manager and senior people needs to (as always) be cognisant of his/her power to cause people to agree with them. They need to refrain from giving any positive/negative signals until junior people have been able to freely express themselves.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.