3 ms·

> you're not going to be productive with real code for a few months I've hired several engineers who get productive within the first week. Most manage to get i

> you're not going to be productive with real code for a few months I've hired several engineers who get productive within the first week. Most manage to get in a PR and deploy to production by the end of the first day. If it's taking a few months before the candidate can get productive, something has gone horrifically wrong.

rootusrootus 6y ago
> ... something has gone horrifically wrong Agree 100%. And in most cases it probably isn't a problem with the candidate. It's a problem with the existing software and development process. It shouldn't take someone months to become useful on a new project.
masonhensley 6y ago
We've probably all seen or heard of places where a developer sits around for weeks, going to standups with their status update - "waiting on license XYZ" or waiting for access to the project (git, TFS, jira, vpns etc). It's a huge problem in many orgs. It's also a good sniff test if you're interviewing. Slow and steady might be up your alley too. There's definitely a hierarchy of security and compliance needs depending on the org, but many orgs loose the forest for the trees.
pmiller2 6y ago
> If it's taking a few months before the candidate can get productive, something has gone horrifically wrong. There's a big difference between "deployed their first PR" and "getting productive." The latter implies the engineer knows or has figured out how to use your source control, CI, and deployment processes. That probably is something most people can manage in a day, with proper instruction, provided the code change itself is simple enough. The latter means they're familiar with large parts of the codebase and are able to make changes, and have an idea how the major parts interact. This is what takes a few months.
ryanianian 6y ago
Solving a maze problem or fixing a gimme CSS or unit-test bug is significantly different development from what even junior-level engineers do on a regular basis after a few months in. The kinds of code you get on any sort of interview or one-day homework assignment are significantly different from what you'll see in 3 months. If not, as you say, something has gone horrifically wrong.

rootusrootus 6y ago

> ... something has gone horrifically wrong Agree 100%. And in most cases it probably isn't a problem with the candidate. It's a problem with the existing software and development process. It shouldn't take someone months to become useful on a new project.

masonhensley 6y ago

We've probably all seen or heard of places where a developer sits around for weeks, going to standups with their status update - "waiting on license XYZ" or waiting for access to the project (git, TFS, jira, vpns etc). It's a huge problem in many orgs. It's also a good sniff test if you're interviewing. Slow and steady might be up your alley too. There's definitely a hierarchy of security and compliance needs depending on the org, but many orgs loose the forest for the trees.

pmiller2 6y ago

> If it's taking a few months before the candidate can get productive, something has gone horrifically wrong. There's a big difference between "deployed their first PR" and "getting productive." The latter implies the engineer knows or has figured out how to use your source control, CI, and deployment processes. That probably is something most people can manage in a day, with proper instruction, provided the code change itself is simple enough. The latter means they're familiar with large parts of the codebase and are able to make changes, and have an idea how the major parts interact. This is what takes a few months.

ryanianian 6y ago

Solving a maze problem or fixing a gimme CSS or unit-test bug is significantly different development from what even junior-level engineers do on a regular basis after a few months in. The kinds of code you get on any sort of interview or one-day homework assignment are significantly different from what you'll see in 3 months. If not, as you say, something has gone horrifically wrong.