
Ask HN: How can I prepare for my new job as a software developer? - mardurhack
Hello,<p>In September I will start my first real job as a software developer (mainly backend) in a great company. What&#x27;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.)?<p>Thank you!
======
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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

~~~
shoo
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](http://www.thomsett.com.au/library/item/estimation-games)

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

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

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

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

~~~
hyperpape
Ack, I said I would attach a blog post, and then didn't:
[http://blog.regehr.org/archives/199](http://blog.regehr.org/archives/199)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

