By that I mean, understand the current system / requirements for new system in such a way that you effectively work alone, if you need.<p>And in general, how is the on boarding process? Do you normally have a mentor/guide to ask questions, or do you just learn by doing? Do you do pair coding in the first few weeks?
One of my mentors, a former Fortune 500 CEO turned business school professor, told me it takes 2 years for an employee to become full trained in a job. I've found that to also be true for technical jobs.<p>I've also found that it takes about 6 months to start understanding the system without hand holding from a manager or senior developer.<p>To get up to speed, I'd recommend starting with the smallest projects first: simple bug fixes, pair programming, and doing some support work. That will get you seeing how the software is used and which lines of code correspond to the different pieces of software. You can move on to bigger projects once you get your feet under you.<p>I wrote more about getting up to speed at a new job on my blog: <a href="https://www.climbuptheladder.com/how-to-succeed-in-a-new-job/" rel="nofollow">https://www.climbuptheladder.com/how-to-succeed-in-a-new-job...</a>.
That really depends on the company and the software they are building.<p>I work in healthcare and before I was hired I was told it would take me about 6 months to become productive (understand the system, the jargon,..).<p>The first month I had a mentor that I did some pair programming with, in which I was mostly watching at first and then being the programmer. I also had courses on how to use the software and was taken to many meetings to get 'context' of what we worked on.<p>All in all I became productive around 4-5 months (developing new features without bothering colleagues too much and leading some own projects)<p>--<p>At a job before the current one I was not really guided at all, but they had written tutorials about how to work with their software. And in the tutorial you build a 'new' feature as you went along using more and more complex features of their framework.<p>No pair programming and actually felt more like a university course (as you kind of got graded via code reviews and had to retake a tutorial step if you failed).<p>I would actually recommend the first approach.
One or two days; setup dev environment, database connections(local or remote), checkout code, build, start, debug. Start working tickets, features or bugs. Ask for direction when I need it. I usually don't. The truth is in the code, if you ask you just get people's out dated information. But I've working the same stack for > 10 years (Java enterprise).<p>Learning the domain takes longer of course, but you don't need domain knowledge to fix bugs or put buttons on a page.
I would think it would depend on many factors.<p>For starters:<p>1. What the nature of the work is.<p>2. What the culture of the company is, and if you have adequate help from other folks you work with.<p>3. How quickly you learn.<p>That makes it a challenging question to answer, as it seems like a moving target.
I'll say, when you join a new company, it takes some time when you feel you are "involved" and care about the company.<p>> If the product involves 50+ engineering team members, then 2-4 months takes you to onboard, and post that you learn new things and feel involved in day to day.
Time to minimal productivity, at the cost of pestering coworkers often: a few days. Time to basic, awkward autonomy: a few weeks. Time to full participation: about a year. Time to leadership: 2-4 years.