What should I expect when joining a company as a developer in terms of training?

Question

I came across this excellent post:

I recently started my first "grown-up" job as a software developer. As exciting as it is to get paid for doing what I love, I can't help but wonder if I'm expecting waaaay too from a company.

My main issue is that I know virtually nothing about the (very large) application I'm maintaining, or even the business domain...

I was really expecting that someone would sit down with me and give me a nice demo of the ins and outs of the application and the business, but no one seems to be willing or able to do that.

The above post led me to a question that I have:

As a new employee hired on as a developer, what should I expect when joining a company as a developer, in terms of training regarding the company's business domain and business practices?

Answer 1

In a perfect world that does not exist, I would hope that all companies teach:

• How to get what you need to do your job - the tools you need, how to use anything that is specialized in the company, any company specific processes or practices. Basically picking up on the technical particulars that weren't covered in the average training for the field (for example, one assumes a software developer can write code... but if the language is proprietary, there should be docs or a training course).

• What the company is doing/making - some background info on the product or the service or whatever it is that makes money for the company. In cases of consulting, it may just be customer service type training, or information about how billing works.

• How to be successful in the culture - In this bucket I put everything from painfully boring HR classes on sexual harassment, work ethics, and security training, as well as possibly more useful stuff like a quick doc on "how/when to call a meeting" as well as the conscious effort to get new employees into the "vibe" that can't be formally trained, but has to be influenced.

But it will vary wildly by company how formal or well-defined any of this is. A small company may just say - "computer's overe, watercooler is here, we'll send you a demo the next time we do one." A big company may have 6 months of "onboarding" to get a new employee up to speed.

How a company does this will say alot about the company and what they consider important. For example, software firms that create high-end, life-critical systems tend to really emphasize testing and quality assurance - there may be weeks of formal training, and you may be invited to peer reviews and given feedback on your first few projects - all focused on rigorous testing and QA. Another company may be a "fend for yourself" style company, where nothing gets checked over, but when your code needs fixing, you are on the hook for it. Different industries tend to have a different vibe.

Answer 2

In a new job I believe one should expect to be shown the ropes. What that means, however, is different in each company and depends on the position itself and the experience the new comer has as well.

The best introductions to a new job would indeed include all that the asker you have quoted expected, but as experience shows, many employers are not the best at many things, including inductions.

Many companies do not have induction plans at all. Some that do are the ones conducted by HR regarding company policies and procedures and a work related induction never happens.

In many ways, the induction is up to the manager of the new person - and managers certainly vary in their approaches and care for employees...

Answer 3

In a perfect world, you'll be walked through the application and the codebase, and given any supplementary materials you might need in order to maintain the system.

Reality, however, is normally much less idyllic. After all, if there are people to do all that, then they really don't need you all that much. In practice, you should expect a basic introduction to the application, and possibly some old notes that were made on it originally. Often, if you dig around on the company's network enough, you'll find the original design specs of the application, but that's a bit outside of the scope of this question.

Now, this might all seem to paint a very bleak picture, the fact that you will most likely not be given very much direction or training for maintaining a specific application. However, you can mitigate or even eliminate the issue if you are a bit proactive. As long as you know the language used to make the program, you should be able to find plenty of other programs online, written in that same language. Download them, and learn them. Step through the code, line-by-line, and basically read it. You want to be able to read it like a story, and in this way you'll be able to teach yourself the application in the future, when you get to it.

The most important lesson you can ever learn, is how to learn. Once you have that down, have fun!

Answer 4

Possibly, yes. The question I'd have is how mature are the people and processes at the company for handling bringing in new hires? Many places would expect the new hire to "jump in" and learn the stuff on their own without supervision, I'd expect. I'd suspect 80-90% of job descriptions I see will have, "work well with minimal supervision," which is part of what is being asked here is that supervision to bring someone up to speed.

If the company is mature then there should be a contact to assist if there is a question or desire to know more than what reading the documentation, tests, and source code has. However, there is something to be said for what work is being done and what would be useful as if the main application has tens of thousands of lines of code then an overview may not be useful if one is fixing minor functional bugs that don't correspond with an overall tone of the code.

Something to consider is how well is he phrasing this request. Is he conveying a sense of entitlement that everyone is to bend over backwards to spoon feed him? Is he being specific enough in the request for assistance that it can be met? I suspect this is the type of communication expectation that will happen repeatedly if he isn't prepared to be accurate and precise in these requests.

"Baptism by fire" would be a typical situation I'd expect as developers are expected to know how to learn what is needed and use that to solve a problem and move forward. Figuring things out on one's own is part of this process that is rather natural, at least to my mind and in most of the cases I've had in my 13 years of work.