Ask HN: How can I prepare for my new job as a software developer?

Learn the stack they use, play with it, make sure you understand it. Also, find out what version control system they use and get comfortable using it - source control's vital stuff when working in a team and something that you may well have not really used so far in CS.

If the company is profitable, study up on what the company does to make money. Look at the business side of things rather than the technology side. As a software guy, your job is to create stuff that people will buy, increase productivity, or reduce expenses.

Learn the stack. Chances are, your work will be pretty different from anything you learnt in your cs courses.

Depends on the job, but algorithms and stuff in the real world are highly technical matters and rarely successful companies will put youngsters against them.

The best way to make a good impression is to learn their stack and be familiar with their tools.

For example, if they use 'Docker' try to get familiar with Docker. If they use git, rails, MySQL and Redis try to familiarize yourself with basic concepts. Try to create a similar setup and re-create the environment at home, etc. Play with it, try to read a few tutorials about it, learn the slang quickly.

However, don't be afraid to ask. Do your homework and when not sure ask, the more specific the question, the better. Especially in the beginning asking (even stupid questions) could save your day.

If you already got hired, I would just relax. Get some exercise, find a couple good books [1] you can read later when you want to take your mind off work.

Then, when you start work, pour over the source code. Understand it. Ask or research anything you don't understand. Make a list of things that suck about it -- there likely will be a lot of technical debt, but who knows...

If you want to get ahead, combine working harder than anyone else with the concepts you will absorb by reading The Power Broker [2].

[1] I say a book instead of NetFlix or games, because if you read at night, with a red light, you'll become sleepy and get a good night's rest, but watching TV or playing games will keep you up, and you'll go into work tired.

[2] Don't mistake this book for some self help or business genera, it's page-turning biography by one of the best journalists of our time.

In addition to learning the stack, you will also need to learn their processes for basic stuff like making changes: how do they match up the reason for a change (new requirement, bug etc) to the actual delta in their repository. Do they use Git? Learn Git. Do they use Jira? Learn that. These are tools you will use for work every day, but they are often not covered in CS courses.

It would've been useful if you'd at least posted the language. My recommendation is this: be pragmatic. I've been asked plenty of times to forgo software development principles to get a product out the door ("hardcode this", "copy/paste that"). I never copy/paste, but I have hardcoded things to get a product shipped on time. You may have a better idea of how to do a lot of things, but only bring it up when you understand the full implications of your changes. Initiative is good, careless prattle is bad.

Groking business logic can ultimately make you more valuable than your software development skills, and nobody hires you for software development alone. Be humble (I myself sometimes fail this when I word something too strongly), be honest, be malleable.

Honestly, without some sense on the stack, size of the codebase, type of company and team size, that's about as much advice as I can give you

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.

It couldn't hurt to go back and review but I'd ask them for what tools they use and what they think you should study.

You will also want to be familiar with some tools to debug code for their stack. They'll likely give you some bugs to track down to start off with. Definitely install and play with whatever database they are using.

Not really to prepare, but during your first weeks identify the best programmers there and look through their commits. Books, tutorials, etc are good, but nothing like seeing how a good programmer writes code and solves problems on a day to day basis.

Make sure you keep your ears open for advice from more senior folks in the company, and ask questions when you don't understand something or get stuck. You'll be fine.

Don't be the guy that spends two weeks on a problem that could've been solved in 15 minutes by asking someone for help.

Don't let your job let the only thing to teach you. Self learn. Do things that are out of your reach. Other languages and tasks can teach you a great deal about the inner workings of software development.

Learning their software stack is good, but also learn the tools and best practices that they are implementing. When I started my first job while I was still in school, I had learned little to nothing about unit testing, version control systems, continuous integration, and agile process, which were all in use at this place. It made my integration with the team that much harder because I didn't completely speak their language.

Another vote for "learn the stack".

Also, if you have the contact info of any developer/lead you'll be working with, reach out to them and ask what you can get a jump start familiarizing yourself with. I've had interns do this and it definitely made a noticeable difference. I mostly told them to get familiar with the stack and gave them quality free resources (while stressing it was voluntary). They didn't come in an expert or anything, but it did seem to help their heads from spinning too much during the first day/week.

I have had three "bigboy" software jobs in my career and the same thing has always served me well:

It is always the expectation of those charged with the task of training or managing you that early-on you will start slow and be an impediment to the company. If you can figure out a way to violate that expectation, e.g. produce something meaningful in your first 1-2 weeks, you will have made a good impression that will last for a while. Build on that impression.

A lot of the posts here focus on content. I would focus on process. Since you're new to the job your head WILL be spinning, so it's important for you to setup a way to work through the "newness".

Bring a notebook and a timer. Understand what your immediate report's expectations of you are and then set up a schedule for yourself to help yourself meet those expectations. I'm assuming that since it sounds like you're new/junior hire, the expectations, at least initially, will be low. Use this time to create a rhythm for yourself on a hour-to-hour, day-to-day, week-to-week basis so that you yourself can see your progress and understand what you're doing.

Nothing is more discouraging than being pumped for a job, putting in a lot of hours, but not really realizing where the time has gone (which was my experience initially) with very little positive results to show for.

Read The Pragmatic Programmer, then Code Complete 2. These books will help you approach problems and people. Most important thing I've learned is to write code other people can read. A lot of times that person can be future you.

Learn design patterns, approaches to getting requirements, and how to read/create diagrams.

Learn how to write unit tests.

Learn source control tools and how to use them. If it's a command line, know how to do this from the command line.

Learn best practices for your language and get really good at your editor/IDE. (For instance, I use VIM with syntastic and pylint to check PEP8 compliance).

Learn to type quickly and accurately. This helps with everything.

If you've done those, enjoy your Summer! It's the last one you'll ever have :).

Some other things that would be fun:

- Set up a Docker image

- Write a REST API server in Python on a Linux OS

- Build in authentication, authorization, documentation

- Have Docker build and run your REST API server

- Set up a load balancer container to distribute load between multiple Docker containers

- Set up a shared cache like Redis or Memcache with containers

- Set up a MySQL Database

- Write unit tests for API

- Have Docker container automatically build, test, and deploy when you check in code

That will bring up a lot of questions of how you design things and how everything is tied together. Maybe you will just be working on a small part of this, but then you might know why things are done a certain way or how to do them better. That's where you can make a difference and distinguish yourself. You can bring a fresh perspective. Don't take anything for granted. Ask questions when they need to be asked. Learn how things can be improved.

Another +1 to learning the business domain and the jargon associated. I work in the real estate software industry, and our Rails app is nothing but models of leads, agents, brokers, properties, etc. Knowing that an Agent belongs_to a Broker and a Broker has_many Agents is invaluable and obvious once I understand a bit about how a real estate brokerage works.

Regardless of what you do over the summer (reading up on their stack is good advice as others said), find a mentor as soon as you can. Someone who has been in the industry for a while.

My advice would be to work on debugging. It's where I struggled most early on in my first job, and where our current intern is weakest (despite being really good overall).

If you're working on a large system and haven't worked with one, you're going to end up lost a lot. Debugging a complex web app is very different than debugging an algorithm.

Here is a blog post that discusses the topic and links to four books on the topic. David Agans' _Debugging_ ended up helping me quite a bit.

A second point I'd make is to learn the idea of refactoring as a systematic process. Early on, I wanted to refactor everything, but didn't know how to refactor safely and methodically. Martin Fowler's refactoring book is not exciting, but it gets the message across that refactoring is not just "changing stuff to make it better" but a process.

Here's what I did to prepare for my latest job.

1. Break the time remaining into one or two week blocks.

2. Assign one layer of their stack to each week, starting at the bottom. ( e.g. OS )

3. Each morning make and practice flashcards for terminology or things that just need to be memorised, about the tech in that stack layer. ( e.g. What is the /opt dir for?)

4. Each afternoon work on a small project around that layer. (e.g. cmd prompt customisation)

5. Get plenty of sleep so you actually retain this information.

A week or two before starting, find out whom you will be reporting to. Get in touch with that person and ask about what kind of tasks they have in mind for you and whether it would be useful to prepare in any way.

Other than that, I wouldn't do anything.

Algorithms and CS stuff: you might not ever see it again.

If you study four algorithms, but you are asked to work on a fifth one that is completely unrelated, that is of no use. In development, you brush the dust off the specific algorithm or theory that is needed for a task, when that time comes.

Ok I'm guessing you're a new grad. If you're already working this might not apply.

Use this time to do things OTHER than work. Work out. Travel. Rest. Visit friends. spend time with family. Read for fun.

The other suggestions here are all good. very useful. It's just that this is a great opportunity to do things you can't do when working. Once you start your career it's VERY unusual to get a month or more time off. It might feel like you have lots of time on your hands, but the opportunity you have is actually brief.

I especially recommend travel. If you're young and single, you can afford to travel cheap. You know you have a job starting, so it's ok to spend now knowing you have income ahead.

I think many other people have posted good advice on how to get ready. I just want to second the other post that recommends against preparing for it.

When you interviewed and got hired they knew your qualifications and knew you might not know some things. You're about to get paid to learn what they need you to learn. I don't really see why you should your own personal time learning something for them.

Instead, I'd recommend you spend this time relaxing and learning things that YOU want to learn. This is going to be good for the company most likely in the long term anyway (assuming it's related to CS anyhow) and you probably aren't going to have as much time to do it after you start working. This will also make it less likely for you to get burned out in my opinion.

I think it's easy to feel a lot of pressure at the beginning to know everything and to be productive right from the start. Hopefully this isn't necessary. Everyone will expect you to need to be familiarize yourself with the tools and the code base. They aren't paying you until September, and they know that.

Unless this is a short-time consulting gig, they haven't hired you for what you can do in the first month, but what you can do over the course of a year or two. It's okay to learn on the job; it may seem like a lot of time to you when you first start, but in the context of recruiting, your yearly salary and benefits, providing your office, etc, the time you spend learning in the first few weeks is nothing.

I think the most important thing is to be relaxed and have your non-work affairs in order as best as possible. You don't want to be distracted by stuff at home while you at work, if possible. If you are like me, you will also find it very hard to turn your brain off when you go home at the end of the day for the first month or two, and it's important to have things going that are interesting and relaxing (hiking, movies, craft, trivia night, whatever). And whatever those things are for you, do them a lot now while you have the time!!