[dsiegel2275]

Learning their stack is good advice. You'll impress folks if you can hit the ground running.

Another area that I'd recommend is start to learn the business domain. If your company builds accounting software - start to learn some basic accounting principles. If your company builds healthcare insurance software, start to learn about the relationships between healthcare providers, insurance providers, health plans, etc. Software systems are built to model business domains, account for constraints in the domain, and deliver value for users in that domain. Knowing the ins and outs of the domain will make it easier for you to learn about the software when you first start, but also will allow you to grow into an engineer that can solve problems and deliver real value to your employer.

I've had the luxury of working on software in domains that were highly technical (nuclear reactor inspection and repair) and unique (military command and control over tactical networks). Understanding the domain at hand has always been crucial to my success.

[vkjv]

+1 to learning the business domain and the jargon associated. In my experience, domain specific code tends to be littered with jargon that makes it difficult to understand if you do not understand the vocabulary.

Unfortunately, much of this can even be business specific. It would be helpful to find out if they have any of this documented. It probably isn't documented within the software team, but, it most likely is for other business units!

[mardurhack]

Thank you for the advice. The company doesn't focus on any particular domain but handles many different projects.

[mabbo]

Then find out what your team in particular works on right now, and learn about that.

[rajeshmr]

+1