dmohs/hiringprocess.ad

## hiringprocess.ad
= Hiring Process

== Candidate Selection

=== Levels

For associate engineers, the candidate must have done something outside of schoolwork. This could be a personal project, a contribution to an open-source project, or an internship or other part-time work.

For software engineers, I expect proficiency in at least one language and one technology. For example, JavaScript and React, Java and Postgres, etc.

For a senior engineer, I expect expert-level proficiency in one language and technology and proficiency in the complements. For example, an expert in functional programming must also be proficient in object-oriented programming. An expert in a statically-typed language must also be proficient in a dynamically-typed language. I also expect some proficiency in automation, error handling, logging, infrastructure. A person at this level should be able to design and build a microservice and the surrounding infrastructure in such a way as that it aligns with good engineering principles. Finally, I expect some mentorship experience.

Principal engineers must have multiple areas of deep expertise, a developed engineering philosophy, and leadership characteristics. A principal engineer should make sound technology choices according to their engineering philosophy and should be able to explain those choices in a way that a non-engineer can understand the tradeoffs.

A senior principal engineer is someone who has mastered all of the above and continues to practice toward mastery.

=== Evaluation

Evaluation criteria gets more strict at higher levels. At software engineer and below, attitude is the most important. We look for humility, leadership qualities, good judgement, and taking ownership and responsibility.

At higher levels, expertise plays a role in selection. Specific technologies are not as important as breadth in skills, so programming languages matter less, but an expert in object-oriented programming with only proficiency at functional programming will have a difficult ramp-up at the Broad.

To evaluate whether a candidate would be successful, I need to see a code sample. The code sample needs to be substantial. A twenty-line program could be enough if it shows creativity and a thousand line program could be mostly boilerplate, which is noise and doesn't give me any information on the person's proficiency, except to show that the person isn't good at eliminating boilerplate and so is not likely a candidate for a senior-level position.

A resume is helpful to evaluate experience. A cover letter could substitute.

The candidate should receive my engineering philosophy https://gist.asciidoctor.org/?fa16682ee191e635facf905706d26fb6&no-header-footer=[[1]] to ensure they are likely to be happy in our engineering culture. They should also browse our code repos (examples: https://github.com/DataBiosphere/terra-ui[[2]], https://github.com/all-of-us/workbench[[3]]) to ensure they would feel competent contributing code there. Finally, they should consider watching my last talk https://www.youtube.com/watch?v=RQkKFgnP7_k[[4]] for more culture alignment.

== Interview Process

1. Half-hour phone interview.
2. Hour meeting in-person.
3. On-site interview.

For the in-person meeting, candidates should expect an in-depth conversation about their own code, my engineering philosophy, our code repos, and culture alignment (deeper than the phone interview). The on-site interview can be scheduled immediately following the in-person meeting if that conversation goes well.

The on-site interview includes a take-home coding exercise that we will send to the candidate via email, so it must be scheduled far-enough out to allow the candidate adequate time to think about the problem, schedule time to complete it, and return it to the interview panel in time for them to evaluate it before the day of the interview. It should take them a few hours to complete. I suggest that a week out is a reasonable minimum, give or take a day.
	= Hiring Process

	== Candidate Selection

	=== Levels

	For associate engineers, the candidate must have done something outside of schoolwork. This could be a personal project, a contribution to an open-source project, or an internship or other part-time work.

	For software engineers, I expect proficiency in at least one language and one technology. For example, JavaScript and React, Java and Postgres, etc.

	For a senior engineer, I expect expert-level proficiency in one language and technology and proficiency in the complements. For example, an expert in functional programming must also be proficient in object-oriented programming. An expert in a statically-typed language must also be proficient in a dynamically-typed language. I also expect some proficiency in automation, error handling, logging, infrastructure. A person at this level should be able to design and build a microservice and the surrounding infrastructure in such a way as that it aligns with good engineering principles. Finally, I expect some mentorship experience.

	Principal engineers must have multiple areas of deep expertise, a developed engineering philosophy, and leadership characteristics. A principal engineer should make sound technology choices according to their engineering philosophy and should be able to explain those choices in a way that a non-engineer can understand the tradeoffs.

	A senior principal engineer is someone who has mastered all of the above and continues to practice toward mastery.

	=== Evaluation

	Evaluation criteria gets more strict at higher levels. At software engineer and below, attitude is the most important. We look for humility, leadership qualities, good judgement, and taking ownership and responsibility.

	At higher levels, expertise plays a role in selection. Specific technologies are not as important as breadth in skills, so programming languages matter less, but an expert in object-oriented programming with only proficiency at functional programming will have a difficult ramp-up at the Broad.

	To evaluate whether a candidate would be successful, I need to see a code sample. The code sample needs to be substantial. A twenty-line program could be enough if it shows creativity and a thousand line program could be mostly boilerplate, which is noise and doesn't give me any information on the person's proficiency, except to show that the person isn't good at eliminating boilerplate and so is not likely a candidate for a senior-level position.

	A resume is helpful to evaluate experience. A cover letter could substitute.

	The candidate should receive my engineering philosophy https://gist.asciidoctor.org/?fa16682ee191e635facf905706d26fb6&no-header-footer=[[1]] to ensure they are likely to be happy in our engineering culture. They should also browse our code repos (examples: https://github.com/DataBiosphere/terra-ui[[2]], https://github.com/all-of-us/workbench[[3]]) to ensure they would feel competent contributing code there. Finally, they should consider watching my last talk https://www.youtube.com/watch?v=RQkKFgnP7_k[[4]] for more culture alignment.

	== Interview Process

	1. Half-hour phone interview.
	2. Hour meeting in-person.
	3. On-site interview.

	For the in-person meeting, candidates should expect an in-depth conversation about their own code, my engineering philosophy, our code repos, and culture alignment (deeper than the phone interview). The on-site interview can be scheduled immediately following the in-person meeting if that conversation goes well.

	The on-site interview includes a take-home coding exercise that we will send to the candidate via email, so it must be scheduled far-enough out to allow the candidate adequate time to think about the problem, schedule time to complete it, and return it to the interview panel in time for them to evaluate it before the day of the interview. It should take them a few hours to complete. I suggest that a week out is a reasonable minimum, give or take a day.