You’ve Cracked The Coding Interview, Now What?

So, you’ve managed to crack the coding interview and got yourself a job offer, but now what?

Negotiating your salary

This is one of the most crucial steps to getting a new job, one most programmers ignore.

Far too many programmers take the first offer they are given and don’t spend any effort negotiating their salaries.

This is a huge mistake, for a number of reasons:

• Getting a raise is often more difficult than negotiating a higher salary up front
• Starting at a higher amount will likely mean that raises are worth A LOT more since raises are usually a percentage of your current salary
• In many situations, successfully negotiating your salary will cause you to be treated more like a professional and less like a commodity
• Getting paid more is… better… DUH!

I’ve written up a detailed post talking all about how to negotiate your salary, so I won’t repeat how to do it here, but I definitely recommend you read the post before taking a job offer.

Don’t be afraid to do it.

I know it’s a bit uncomfortable and you might be afraid that it will cause you to lose the offer, but it will be worth it—trust me.

Your first week

Alright, things are looking good. You got a job offer that you are happy with (hopefully you negotiated it), and you are ready to start working, but are you prepared for your first day at the new job?

Your first week at a new job is very important, because it will set some overall impressions that will affect how your boss and coworkers interact with you in the future.

Once people form an opinion about you, it’s often difficult to get them to change it. So, it’s worth taking some time to think carefully about how you want to be perceived.

Dressing the part

One really important factor is dress. How you dress will not only affect what people think of you, but it will also affect how you feel and to some degree the work that you do.

You’ll want to think carefully about the kind of perception you want to give off and what you aspirations are for the company you are working for, before deciding how to dress on your first day.

For example, perhaps the work environment you are joining is very casual and everyone wears flip-flops and tank tops to work. You may want to go ahead and do the same, but perhaps if you want to go down a management track or team lead track, you’d like to look a little more professional than everyone else.

You’ll want to think about this carefully before dressing for your first day of work, because if you show up in flip-flops and an aloha shirt and then later on decide you want to start wearing a suit, it’s not going to seem natural, people are going to wonder what is up. But, if you start off dressing up in a suit, people will just assume that is just who you are.

So, take some time to think carefully about this decision.

Oh, wait, what’s that you say? You want my opinion on the matter?

Well, it’s changed over time, but I would recommend always dressing one-to-two notches above the level of dress that most everyone else does.

Why?

Well, I think it is not likely to ever hurt you, and it can very well help your career. By looking more professional, you are likely to be perceived as more professional. I didn’t follow this advice myself, but I wish I had. Also, by keeping it to just one-to-two notches above what everyone else is doing, you won’t seem too out of place.

Another good hint is to look at how the top level of management dresses and emulate that style and level of formality.

But, it’s totally up to you. If you don’t care about all that, do whatever you like…

(Don’t know how to dress or what to wear, check out the Style Bible.)

Figuring out who’s the leader

The next major thing I’d recommend for your first week, is figuring out who has authority and who is the actual leader of the team—often not the same person.

Basically, you want to figure out who is the most influential person and make sure not to cross them.

If you are paying attention, you can usually figure this out pretty quickly—and it’s really important that you do.

I’ll give you an example from my own experience.

Once upon a time, I took a job where I was going to be a sort of lead/mentor role to the development teams on the project. Well, on my first day, I noticed that someone who was in charge of QA was spending a whole lot of time in the big boss’s office, chatting with him.

I took a mental note of this and I made sure I introduced myself to this person and tried to make a favorable impression—noticing the dynamic.

Well, it turned out this was a good move, because even though this person wasn’t the most competent or likable fellow, it seemed he wielded more power than anyone else in the entire organization. Every time someone was “removed from the project” it was because this person had a chat with the big boss and recommended their removal.

I could have easily clashed with this person and thought that his title indicated that I shouldn’t have anything to worry about—after all, he technically didn’t have any real authority—but that would have been a huge mistake, because he had a high degree of influence.

I’m not saying to be a suck-up-brown-noser, but I am saying that you should at least be aware of the people who wield power—officially and unofficially—and act accordingly. It can make a huge difference in your career.

So, during your first week at a new job, you want to take some time to observe and try to figure out who is influential and who is not.

Understanding the business

One of the biggest mistakes new programmers on a job make—and one I’ve made myself far too many times—is not taking the time to adequately understand the business and the business domain for the software project they are going to be working on.

It’s much more difficult to work on a codebase when you don’t understand the problem the code is trying to solve.

It’s almost always a good idea to try and achieve some level of domain expertise first, before spending too much time in the actual code.

Yes, I know this is boring. Yes, I know you just want to get started and write some code…

But, if you are willing to take the time to learn about and understand the underlying business, you’ll do a much better job, get a lot less frustrated and find more long term success and satisfaction with your job.

Too many times, I’ve jumped right into the code and never really took the time to understand the business domain that the code was built around. This resulted in hours of frustration as I tried to learn just enough about the problem I was trying to solve to write the code to solve that particular problem instead of understanding the bigger picture.

When you don’t have a good grasp on the bigger picture, you end up spending a lot of time spinning your wheels as you are trying to understand a single puzzle piece without understanding what the entire puzzle is supposed to look like in the end.

Trust me on this one. Take the time early to read up on, ask questions and do whatever it takes to understand the business and the problem domain.

Familiarize yourself with the codebase and tools

Once you have at least some understanding of the problem domain, it’s time to actually look at and try to understand the code and tools used to develop the code.

The best thing to do is to try and get a local version of the code and build working on your development machine, so that you can explore and interact with the application you’ll be working on.

This process can be painful, but it’s worth the time to do it right—and more importantly understand what is going on.

If someone is helping you set up your development environment, ask plenty of questions and take plenty of notes.

You want to make sure you understand not just what you need to do to build the codebase, but why you need to do certain things and how the system fits together.

It can be extremely frustrating trying to work a system that you don’t understand. It’s also a lot more difficult to remember steps when you don’t understand why you are doing them.

So, even though you may be a bit embarrassed, don’t be afraid to ask questions and get thorough explanations about the system you are working with and why it functions as it does.

Once you have your machine setup, make sure you take some time to step through the code. Ideally, you should step through some transactions in the system that take you from the front end to the back end and back again, so that you understand exactly how data makes its way from the user interface to the backend systems and back up to the user.

(By the way, check out Working Effectively With Legacy Code for a great book on the subject.)

Just set a break-point in the code and step through it to follow it down. This is one of the best ways to get a quick understanding of a complex system.

Also, take some time to understand and familiarize yourself with the tools you’ll be using. You can waste a lot of time if you don’t.

Get in the habit of weekly reporting

One of the first things I almost always did at a new job is to start, voluntarily, sending weekly reports to my boss.

I always start this habit on the first week of a new job, and I recommend continuing it for as long as you are employed.

I basically just create a new email each week that I put in my drafts folder and every day I add a few bullets stating what I accomplished that day.

Then, at the end of the week, I send that weekly report to my boss along with any additional comments I have.

On the first week of a new job, I highly recommend sending one of these weekly reports and stating that you want to make your boss’s job easier by letting him or her know exactly what you were working on each week.

This will likely get you on the good side of your boss, very quickly and you’ll be building up a good history of what you’ve accomplished over time that can help you in many situations. Here are a few:

• Asking for a raise. You can easily show what you did and why you deserve a raise.
• Avoiding the axe. Usually resources that are deemed unproductive get cut first. It’s difficult to be seen as unproductive when you are sending weekly reports talking about everything you are doing.
• Yearly or quarterly reviews. It’s pretty nice to list 50 accomplishments with exact dates you accomplished them instead of scraping the barrel to figure out what you did all year.
• Defending accusations. One time someone tried to accuse me of not doing work and goofing off instead and of fudging my hours. Little did they know that I had full documentation of what I did every single day of the year. Let’s just say their accusations actually ended up blowing up in their face and I wasn’t the one who lost their job.

Anyway, I think you get the point.

So, set up a weekly reporting habit on your first week and make sure you save all the weekly emails you send out.

For bonus points, see if you can get away with CC’ing your boss’s boss (just as a FYI.)

If you want more details on weekly reports and how I structure them, check out the career section in my book, “Soft Skills: The Software Developer’s Life Manual.”

Some final advice

Starting a new job can be intimidating, and you might feel a bit insecure and that you have something to prove, but resist the urge.

Instead, ask plenty of questions and be humble. You’ve got the job already, so you don’t have to prove yourself right away by pretending like you know it all.

Try to make good impressions and be open and honest about what you don’t know and then try and learn it as quickly as possible. Avoid being defensive or arrogant and just try to be an overall friendly person.

Remember, your first week is going to set the tone for all your future interactions at your new job, so you want to make sure you make the right kind of first impression. It will be very difficult to change that impression later on.

Too many software developers get past the interview then don’t think much about what happens next. Don’t be one of them!