Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How can I prepare for my new job as a software developer?
45 points by mardurhack on July 22, 2015 | hide | past | favorite | 44 comments
Hello,

In September I will start my first real job as a software developer (mainly backend) in a great company. What's the best thing I can do to prepare for it (i.e. to quickstart instead of having to learn everything on the job)? Study algorithms and refresh some of the stuff I studied in my CS courses? Or learn the stack they use on a daily basis in depth (e.g. frameworks, DBs, etc.)?

Thank 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.


+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!


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


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


+1


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.


Gonna second this. Do something fun, whatever it is. You don’t need to be a hero the first day. Go in well-rested, motivated, and open-minded.

The company pays you to learn their stuff.


Moreover, they need you to learn how it works in your future team. And for that you need to work there.

So, that's simple : - First, rest right now ! - Second, when you'll be there, work hard !


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 would also avoid preparing for the role directly but prepare for software "in general".

You can learn a stack but still not have a great grasp of how MVC actually works and how the framework interacts with the database.

Instead of going over algorithms or frameworks, I would make sure you understand basic data structures and databases. You're going to be working with these no matter where you go.

For data structures, I would focus on hash maps and queues; you'll likely be using those much more than anything else. I would make sure to have a solid foundation in SQL queries because then you'll know what the framework's ORM is doing. Also you mentioned working on backend, so SQL should be your bread and butter (you need to know to avoid N+1 queries, etc).

I've gotten many interviews and at least one job based primarily (after being a nice person to work with, anyway) on having a good foundation in SQL; I wrote a toy ORM and put it on github.


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 be the guy that spends two weeks on a problem that could've been solved in 15 minutes by asking someone for help.

This! I am eternally repeating this to our first line support people where we need to resolve things with 8-16 working hours. If they're still scratching heads after 4-5 hours then they should be hitting up the back room team for advice and guidance.

In addition, we then make sure that the "how the issue was resolved" is written up so, stuck into our internal KB wiki for future reference.

But yes, bottom line don't be afraid to ask, and don't be afraid to ask more if you still don't quite understand the solution/reasoning. I'd rather you kept asking until you "totally get it" rather than you wandering off with a vague understanding and breaking a production environment.


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.


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.


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 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.


Absolutely the best career advice I've ever received, btw.

In my first "bigboy" job, a nine-month contract-to-hire gig at a very well known financial, I failed to violate this initial expectation. I did great work there (eventually) but was still not hired full-time because my slow start left lingering questions for a few key people that were never answered.

Some managers fought to keep me, but it wasn't enough. On the day I was terminated, my manager told me that the one piece of advice he would give me was that wherever I go, make sure to kick ass right away. I've followed this ever since and it has paid huge dividends (constant, rapid promotions).

Always be delivering value.


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 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.


This is sound advice. The technical side of things is important, but do not focus on it myopically. As you are no-doubt already relatively strong technically, it may be worth making a little time to improve your understanding of the business, improve your negotiating skills, etc.

Another useful skill is the art of software project estimation: see e.g. _Estimation Games_ [1] by Rob Thomsett, or Dadhacker's _Keeping Sharp_ [2].

[1] http://www.thomsett.com.au/library/item/estimation-games

[2] http://www.dadhacker.com/blog/?p=2267


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!!


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.


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.


Ack, I said I would attach a blog post, and then didn't: http://blog.regehr.org/archives/199


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.


Thanks, sound advice! I have already some experience with most of the tools they use but I was wondering if I should focus more on doing, e.g., programming challenges on sites like Top Coder or complete tutorial after tutorial about the stack. They use git by the way and I have been using it for a while now.


eh you already got hired, I would relax. Its not like they expect you to start and already know everything. Plus, take time to be away from a computer before you are locked into one full time.


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


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.


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 +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.


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


Thank you. The language will be mostly Python. Being pragmatic is a good thing but I guess that comes after I start working.


Is this Python 2 or 3? The ecosystems are pretty different


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.


Folks here have given great advice, i would like to add : read a lot of books. In general, read a lot.


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.


A previous thread on HN recommended Uncle Bob's Clean Code book. I found it super helpful as I started my first programming job. I followed it up by reading Clean Coder for some career advice.

I think the idea of "quick starting" a new job since you have no previous professional experience may set unrealistic expectations and pressure on yourself. They probably have budgeted on-boarding time for you to figure out some of their stack and lined up some "intro" level work to help you get acclimated.

My advice is be ready to introduce yourself and be honest with your familiarity with the tools they use. Your co-workers probably have awesome things to teach you if you just ask.


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.


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.


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.


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.


Take it easy ! Be nice to all, make friends, enjoy your day and everything will fall in place as long as you show enthusiasm to learn and be proactive.


Learn how to stay curious. Don't spend your time on learning things you will learn at work.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: