Ask HN: How can I prepare for my new job as a software developer? 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! |
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.
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.
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!
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.
The company pays you to learn their stuff.
So, that's simple : - First, rest right now ! - Second, when you'll be there, work hard !
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.
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.
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.
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.
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.
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.
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.
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.
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
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!!
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.
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.
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.
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
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.
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.
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.