Archive for the ‘Career Advice’ Category

The One Page Guide to Getting A New Java Job

how to get a new java job

Bookmark this now. It’s a long post.

Hi.

If you’re reading this then it means you’ve decided you want a new job. You’ve made the right decision. The market is in your favour- there are lots of jobs going and not nearly enough programmers out there to fit demand. As a result wages are going up and the best developers can ask for a lot. You’re no longer limited to the standard 10% bump when you change jobs.

So, all that stands between you and a ton of cash is getting an interview. Then being amazing at the interview.

I’ve tried to condense the basics of the process from start (resume) to finish (yay job!) in this post. That means it’s a big post. If you’ve got time now then great, otherwise bookmark it. This will be your go-to place for your job hunt.

Read the whole thing through from start to finish. Then come back and remind your self of the various bits as and when you need them. Even if you don’t think you don’t need a section, read it anyway. You will find something useful I promise.

BOOKMARK THIS PAGE NOW

But why are you doing this?

Because I’m convinced you’re going to find this page so useful you’ll then buy my amazing book, Java Interview Bootcamp, which is like this page but on steroids. It’s 84 pages of greatness on how to smash the interview process.

But this page isn’t a sales page. It’s an honest attempt at condensing the whole process down into one consumable page in the hope that it will help people. If at the end you decide you want more then the book is there.

I get emails from people most days to say thanks, either for the book or the website, as it’s helped them get a new job. That feels awesome. If I help you, then do drop me an email, as I’d love to hear from you.

But who are you?

Hi, I’m Sam Atkinson. I’m a Lead Java Developer and been working in financial institutions for over 7 years now and have been lucky enough to be involved in the hiring process for most of my career, culminating in designing the interview process for my most recent department. I’ve interviewed candidates of all levels from graduate to senior in my time and became increasingly frustrated with the process. Interviews aren’t hard, they just require a bit of preparation on the part of the candidate.

Remember, read the whole thing from top to bottom!

 

Step 1: Resume

To get a job, first you must have a resume. Resumes are easy if you know what you’re doing, which you will do after you read this.

Here are the 2 main pieces of advice you need.

  1. It must be shorter than 2 pages
  2. Do not lie

If you take nothing away from this page, just heed those words. When we’re hiring we get a lot (and I mean a lot) of resumes. No one has time to read them. Normally we’ll be looking for a couple of key phrases (for me it’s normally TDD), but generally we’re just looking to make sure you are a Java developer and you’ve got sufficient experience. If you send me 4 pages I will not read it past the first 2 pages.

If you send me a 1 page CV, I will herald you as a hero and you will get bonus points.

Do not lie. Even on a resume it’s obvious when you lie. If you do sneak it past you’ll get found out on interview and tarnish your reputation (and that matters, because the world of Java devs is a surprisingly small one, despite being huge in number).

An extension of this- do not put a huge list of technologies on your CV. You cannot be good at all those technologies. This amounts to a lie. When you’re describing each role you’ve had, mention the key technologies you’ve used in there.

It’s ok to have multiple resumes- if a role specifically says you need to have AWS experience, tweak your resume to highlight your AWS experience. That’s much better than listing all the technologies in the world and hoping you hit a match.

Don’t list any Microsoft office product. Kinda goes without saying you can type a word doc. (Yes, people really do do this.)

Google Docs has a whole bunch of pretty resume templates. Use one of those.

Keep your document well spaced out. When I say max 2 pages, I mean 2 pages at 12 or 14pt, not at 7pt with no whitespace.

 

Step 2. What to do with your resume

If you can and are willing, use a recruiter. Sure, they have a bad rep. There are some terrible ones out there. But it’s their job to get you a job (that’s how they get paid). It also means you don’t have to write cover letter after cover letter. Cover letters are depressing, even more so when you never hear back.

Ask friends. They may know or have used a recruiter and recommend/tolerate them. Go with these people. If not, just do some basic research on linkedin/twitter/the web to see if you can find out any info.

Go for coffee with recruiters. They’ll pay and free coffee is great. If you like them then roll with it. But remember- they’re working for you. Don’t let them pressure you into any jobs you don’t want to do, or later on to take a salary you’re not comfortable with. They’re just after their pot of gold, and you need to look after your own.

If you can’t/won’t use recruiters, then there are any number of job sites out there; stackoverflow has a good job section and HackerNews has a monthly jobs section full of gold. Then there’s the usual boring ones like indeed, monster etc. which serve a purpose if you’re short on places to send it to.

Whatever you do, make a spreadsheet which says:

  • Where you sent your resume
  • How you sent it
  • What date

Because it will quickly become a bloodbath as you send it everywhere and utterly lose track. Either way, the interviews will start to roll in.

If you do have to do a cover letter, start by writing one generic one that’s really good, then customise it per-time. They’ll mostly end up very similar anyway. Talk about why the role excites you (new challenges! Opportunities to work with new people! Broadening of horizons!).

 

Step 3: Phone Interview

This will vary depending on the company- not everyone does a phone interview, but it tends to be pretty common. The main purpose of a phone interview is two fold:

  • Check if you can kinda program Java
  • Check if you are insane

I’m only being a little facetious here. I’ve had phone interviews with people that would struggle with Hello World, because they’ve been told to write a CV that emphasises Java when in fact they’re a python dev.

As far as sanity goes, there are a lot of people who you can tell quite quickly would not fit on your team, either because they’re too quiet/loud/obnoxious/weird. Phone interviews are good for screening this.

From your perspective as the interviewee, do some Java prep. Just some basic core Java stuff (I’ll discuss this in more detail below). Most people think that because they’re programming Java day in day out that they don’t need to prepare.

They are wrong.

The fact is most interviews I’ve experienced have nothing to do with the day to day life of a Java programmer. You can read post after post after post online about how the interview process for developers is broken, and they’re all spot on. It’s terrible.

However, if you acknowledge that fact then it’s incredibly easy to game the system. The first step is to do some basic revision. It is a test after all! We’re not talking about weekends spent knee deep in Effective Java. Just some basic core Java revision. See below for more.

The second thing you can do is learn some manners. Here’s how the start of a regular phone interview should go.

 

Hi is that John?

Hello, yes this is John

Hi John, it’s Sam from Awesome Co.

Hi Sam! I’ve been expecting your call, how are things?

Good thanks, how are you?

Good, a little nervous but good

Awesome, well no need to be nervous. We’re just going to have a short phone interview today to get a basic understanding of your Java skills and some stuff around dev practices, and then you can ask us some questions. Does that sound good?

Sure, sounds good

 

That’s not a difficult conversation right? John was expecting the call, had the good courtesy to ask me how I was, and was capable of having a conversation of multiple sentences.

I have (repeatedly) had the following on phone interviews:

  • The person hasn’t found a room/quiet space to take the call in so the first 5 minutes are spent with them running around trying to find a free room
  • The candidate will refuse to engage in any sort of conversation, and will limit all sentences to 2 words or less.
  • The candidate has forgotten the interview all together
  • And my personal favourite, the candidate sounds like I’ve really inconvenienced them and/or they really could not care less about the interview

So, here’s the simplest phone interview advice I can give. Be prepared for the call with a good phone line and a quiet room. Sound like you care about the job and interview. Sound passionate about the job and the technologies you’ve worked with/will work on.

This will put you ahead of at least 60% of your rivals.

Do some core Java practice before the call.

This will put you ahead of 90% of your rivals.

 

Step 4: Face to Face interview

Well done! You get to go in and talk in person!

Here’s some Deja Vu. A candidate comes in for an interview. I go to meet them from reception.

 

Dave?

Hi, yes!

Hi Dave, I’m Sam, how’s things?

Shake hands

Good thanks! Nice building you’ve got here

Yeh it’s not bad but the lifts are terrible! You in work today?

Yeh just nipped out, said I had a doctors appointment. We’re just building up to a release at the moment but it’s not till the end of the week

How often do you guys release?

…Conversation continues…

 

Isn’t that a nice easy conversation? Here’s what happens surprisingly often:

  • Candidate will refuse to engage in conversation and will only respond in one or two word sentences. This is not an exaggeration by the way- I’ve repeatedly had candidates appear actively hostile
  • Candidate has a limp hand shake
  • Candidate crushes my hand
  • Candidate is dressed in jeans and t-shirt

Again, the simplest piece of advice I can offer is don’t be hostile to your interviewer. Studies show that a first impression is made in 7 seconds. Dress well (I prefer trousers and shirt. Suits are too formal, but whatever you’re comfortable in… as long as it’s not jeans and t-shirt. Unless you’re going to a startup maybe?), smile, make conversation. Have a quick read of DZone or Engadget before you go to the interview so you have some general nerd news to discuss, and be prepared to answer questions about your project/how your team works.

It’s genuinely worth practicing your handshake if you’re not confident with yours. It really does make a difference to your first impression.

Now you’re past the first 7 seconds, you can get onto the actual interview. All companies are different; maybe you’ll get 3 people in a panel, maybe you’ll get three people one after an other, or maybe you’ll get something completely different. Just try and be calm- your interviewer knows it’s a high stress situation. Take a deep breath when you get a question, or maybe a sip of water, and think about what you’re going to say. Otherwise you’ll just ramble on and on and not have a concise focused point. This is hard, and the area I used to suffer with most. Give concise answers, and ask “would you like me to elaborate?”. That way the interview can drive how long your answer should be.

In terms of questions, you are going to get asked about algorithms and big o. It happens in basically every Java interview in existence. They’ll give you some data problem and ask how you would sort/search/organise it. Then they’ll ask the big o of it. It sucks, because the correct answer is.

“I’d Google it”.

But that doesn’t seem to cut the mustard. Any interview question where the answer could be “I’d Google it” means it’s probably a crappy interview question. But it still stands between you and the pot of gold.

SO READ UP ON IT AND PRACTICE.

Just as with the phone interviews, you need to practice Core Java again, as they’ll probably pull some sort of patterns question up. Make sure, before this interview and before the phone interview, you’ve got a good, well rehearsed answer for:

  • What is deadlock? What is livelock?
  • How would you implement Singleton in Java?
  • What are your thoughts on checked exceptions?
  • How does an ArrayList/LinkedList work? Why would you choose each?

That’s a random set of 4 questions, but at least one of these (or something similar) seems to come up all the time. I had an email only last week from someone who got asked the Singleton question, and ironically the interviewer didn’t know you could make a Singleton using an enum in Java.

You really do need to prepare for this stuff. I’ve seen the most senior developers trip over their tongue trying to explain deadlock, which is a pretty easy concept in reality. It’s not that they didn’t know what it was, they were just poor at explaining it. And that’s the ball game! Being able to explain complex things in a simple manner is one of the most important traits the best developers have. Practice your answers kids.

Make sure you’ve done your research on:

  • Threading & Executors
  • Data Structures and Algorithms
  • Multithreading and collections
  • JVM, Tuning and Memory Leaks
  • Exceptions
  • Basic OOP
  • Design Patterns

Above and beyond this will depend on the interview. If you know they’re big into Spring then practice Spring. If it’s a web dev team then build yourself a full stack project at home to practice.

Reading up on this stuff is a must, but if you can then use that to build yourself little projects and code samples at home then it’s even better. It’s a great way to learn by doing, particularly if you can build something useful. Then you can throw it up on GitHub and reference it in the interview. “Oh Spring Boot, yeh, I’ve been playing with that the last couple of weeks to build interesting thing here, I can send you a link to the GitHub if you like?”. As an interviewer I get really excited by developers who play with code outside work.

No, really.

The internet has given the impression that you won’t get a job unless you’ve got a super high score on stack overflow and a 100 contributions to open source.

This is baloney.

Sure, if you’re going for the Netflixs of this world then that stuff will really help, but for the majority of Java jobs it’s no big deal, because most Java devs are happy to go home and stop coding. They go outside and have families and things.

BUT

If you have a few projects or websites or really anything, then that’s cool. Put it on your resume and talk about it at interviews. It clearly demonstrates that you’re actually interested in technology, and it makes me really want to hire you.

 

Step 5: Programming interview

I hope you have a programming interview. If someone is willing to hire you, as a programmer, without seeing you program, you should be very worried. This is still the case with most interviews though.

If you’re lucky enough to be interviewing for a team awesome enough to want to see your coding skills, then take a long deep breath. It’s a really scary prospect, coding in front of people and having them judge you.

Talk as you code. If you go silent the interviewers won’t know what you’re thinking, and a good pairing session involves lots of sharing. However, be sensible and try to stay focused. They don’t need you to talk through how you’re creating a List as they can see the code. Talk about your design and solution.

One of the main things we’re looking for is your ability to handle the IDE. You’re spending something around 4–6 hours a day in your dev environment and we expect you to be able to use it properly. Specifically, know your shortcuts. Simple things like knowing how to create variables, insert new parameters and extract fields should be part of your toolbox already but if not then now is the time to learn. There is no way to get to a no faster than manually copying and pasting a new parameter around the codebase.

That said, if you don’t know a shortcut but think there may be one then ask. It shows you’re keen to learn and want to be efficient, and that’s good.

Don’t eagerly optimise. Do the minimum to make it work, and if you’re concerned about performance explain to your interviewer after you’ve got a green test and the optomise from their if necessary. A lot of people try to implement a full scale Amazon stack when they’re being asked to sort 10 items.

 

Step 6: Job offer

Because you’ve read all this, and bought the book, and done your practice, you’ve now got job offers coming in. Great! Feel free to donate some of your new paycheck my way.

This can still be a complex bit. We nerds suck at negotiation, and that’s fine, because it’s hard.

The big secret is that, with the exception of maybe some tiny companies, your future boss doesn’t care what you want for your salary. As long as it’s not stratospherically above your peerage, they’ll generally just give it a green light. So, don’t limit yourself to +10%.

Try not to commit to a number at the start of the interview process. Lines such as “I’m sure we can work something out if both parties are keen” will do just fine. Then when the negotiation starts, aim high. Ideally, you’ll have them come to you with a figure first (don’t let them know what you’re on at the moment. That’s irrelevant. The pay should be related to the market, not to what your last firm is paying you).

Then ask for more. Like, $15,000 more. Or whatever “A hell of a lot more” is in your currency.

Do you realise, as someone trying to hire, how hard it is to find good staff? It’s near impossible. If I’ve dragged you through 3 or 4 stages of interview and I, along with my team, have decided we want you on board, then we’re going to be willing to bend over backwards somewhat for you. You have the power. It just might not be that obvious.

You may not get the 15k, but it’s a point to start negotiations at. Pure cash can be replaced with benefits, holidays, conference trips or whatever you find valuable. The reality is on a MegaCorp spreadsheet you are an insignificant decimal point anomaly. You are very important to the team, but insignificant to the firms balance sheet.

Whatever you do, make sure you earn enough money that money is no longer a problem. If you go to work and you’re thinking about how you should be earning more you will not be happy and you will not last.

So, in summary of this entire piece…

  • Be a nice person to your interviewers and anyone involved in the process
  • Take the time to prepare for interviews

What you need now

So I told you I had a book. I hope you’ve found this missive to be eminently useful to you. However there is still much more to learn, and that’s all in Java Interview Bootcamp.

The book covers all of the soft skills stuff in a lot more detail. Like, incredibly precise, do-this-and-you-will-get-the-job detail.

It also covers all the Core Java stuff you need to review in details. It’s got one of the best overviews of Big O notation available (according to people that have read it, not just my ego).

Here’s what you get:

  • Java Interview Bootcamp eBook in PDF, ePUB and .mobi formats: In the first section of the book you will learn to craft the perfect resume, land interviews and thoroughly prepare whether it be a phone, face to face or programming test.
  • 2 example resumes: A Junior and Senior resume for you to use as a base to write your own
  • Online resume template: It’s good to keep your resume online so you can guarantee the latest version. A free template for you to customise and host.

 

And as a bonus, if you sign up now I’ll send you a practice interview and solution sheet, a full PDF script of an example interview along with all the answers to help you prepare.

 

You’ll get all this in your inbox today for just $14. 

That’s the cost of lunch.

Read the book risk free: If you buy and you’re not satisfied, you can have your money back. 100% refund. I don’t want your money if I’ve not helped you with your interviews.

Click the big BUY button below.

Testimonials

”Hi Sam,

I just wanted to thank you for writing the book and sharing your experience with Java interviews. It was helpful in guiding me to concentrate on the important topics and the key knowledge from each, allowing me to drill down into each topic and not lose focus on the way.

I am usually quite nervous at interviews, but the tips you mention in the book helped calm my nerves. I just want to applaud you in writing this book for fellow programmers!”

Anthony Carr

 

“I’ve already bought your book ‘Java Interview Bootcamp’ and have got some great pointers and tips from it – Its a great piece of work. I’ve been in the IT world for more than 20 years and wanted a book to just review Java”

Paul S

 

“Thanks Sam, It was really helpful. It helped me summarize the topics I should be concentrating upon.”

Raj R

“When I was reading this book I asked my self a lot: “Why I didn’t read this book before?” Several days before I started reading the book I had an interview. And I was quite surprised when I noticed that the book describes an interview which is exactly the same. All that questions I was asked are here, just in front of me. But it’s a little bit late. So here’s an obvious advice: if you want to be prepared for the interview try to read this book before, not after.

 

The book contains two big and logically separated parts. First part describes an interview process starting with CV and ending with personal talk. Here you’ll find an information how to prepare yourself to the interview. One of the key points is soft skills. Second part is about technical stuff like OOP, core Java and algorithms. If you’re new in Java, this part will help you to find main topics to learn and improve. If you’re already good as a Java programmer, you can use this part as a reference. It’s quite helpful to refresh your knowledge, especially if you had no interview practice for some time.”

Artem K

 

“Java Interview Bootcamp is very well written in a clear and concise fashion, which is something that can be rare in books about programming. Atkinson writes in a friendly and conversational tone, without ever sounding less than professional. It focuses specifically on Java, but I think it is general enough to apply to any programming interview. Certainly the first half is, which focuses on interview skills and developing a good resume.

 

The second section focusses on core Java knowledge, and is clearly explained and gets right to the point. It’s a great resource to have an experienced programmer and interviewer lay out exactly what knowledge is important to carry into an interview and a job. As someone who is preparing to break into programming professionally, I am so glad that Atkinson wrote this book. Many times I have wondered what, specifically, to focus on for the interview process.

 

The field of programming is so vast that, at times, it is easy to become overwhelmed with what to focus on. Java Interview Bootcamp does a great job in narrowing that down. Highly recomended!!!”

Jeff C

FAQ

Q: I’m a Junior Developer, is this for me?

A: Yes! Any interviewer is going to want to know you have a good grasp of the basics of Java upon which to base any training they give you. The book will get you fully prepared around Core Java concepts. You’ve probably also not done much interviewing, from either side of the table. This will help you prepare, and you really do need to prepare. Interviews are very daunting for a junior.

Q: I’m a Senior Developer. Is this for me?

Yes! Most of the dumb stuff I’ve seen in interviews is from senior candidates who think they don’t need to prepare in any way because they’re senior. Do not fall into this trap. You’re going to be expected to be exceptionally good at the soft skills as well as development. Java Interview Bootcamp will help you with all of this. It’s a tool in your weaponry- it shouldn’t be your only preperation, but it’s a vital tool in helping you.

Q: I really need help preparing for Spring/Hibernate/Web Development!

Upon buying the book you’ll recieve an email course which includes all of the content from Java Interview Bootcamp as well as pointing you to my favourite courses online to take to prepare for all those things and much more.

 

 

Build Your Network at Every Opportunity

Build Your Network

We developers are an introverted bunch. As a rule, an ideal day would involve coming to my desk and coding. No meetings, no one popping by with a “Can I just ask you…”. Just me, my headphones, and coding. No one else.

I’m sure this unicorn concept of a day fits pretty similar to yours, and that’s great. But I’ve found that one of the most important things I can do for my career has been to flip this on its head and talk to as many people possible. The great and wonderful world of “networking”. It’s a bit of a cliche and the sort of thing to expect from a LinkedIn recruiter post, but I’ve found in my career that it genuinely is who you know, not what, that matters most.

I have found this has proven itself time and time again in my career. I’m sure you’ve seen many cases where people are in senior positions who seem less qualified or wholly unsuitable for such a position. These are people who know how to build a network and make connections and then leverage them for their own use. If you feel that your career has perhaps stalled then this is very likely a key area you need to improve.

Let me clarify one thing. Networking rarely means being in a room of random people, with a drink in one hand and lots of awkward, cold introductions. These introductions rarely lead anywhere or add any value (although the free drink is always welcome). But there are some reliable tactics I have found for finding new connections that endure and provide value to both sides.

The first and most important thing is to always try and help other people when the opportunity arises. That opportunity could be an active one, such as a department email asking for volunteers for a working group, or a passive one where you overhear another team is struggling with a piece of technology you’re experienced in. Either way, throw your hat into the ring. I’ve found that simply putting myself forward to help and do someone a favour is a great way to get myself registered in their good books and remembered for the future. Don’t be selective about your assignments either; it’s tempting to think that if a person can’t obviously benefit your career then they’re not worth the time. However I’ve seen so many times that a connection that is seemingly useless will then be able to introduce me to a useful contact, or will at some point move job to somewhere they can provide me help.

Two simple addendum to this; if you’re on email to someone that you don’t yet know answering a question of some sort, always append on the email “let me know if I can help with anything else”. Showing a simple willingness to help leaves a good impression and can lead to further discussion. Secondly, if you think the person could be a good contact then ask to go for a coffee. Everyone needs a break from work and it’s a great way to meet some new contacts.

You should always be seeking to improve your network. If your boss mentions someone in another department you don’t know, ask for an introduction. If someone in your team mentions they know a contact in another team who can help with the project, ask to be included next time they meet. You can never have too many contacts, and the most useful ones are often the ones that you least expect.

An interesting twist on this is to ask for help from new contacts. People like to be valued and to have people ask their opinion. If your colleague John knows Paul and that he’s the expert on Hazelcast and you’re looking to start learning, then go and ask Paul if he’d be willing to spend an hour to chat with you. It’s a great way to learn and make a new connection.

One thing that took me a while to get my head round made a huge difference to my networking: senior people in the organisation are just as accessible as juniors. I’ve found that unless you’re talking about the executive C level folk, most people are happy to spend the time to grab a coffee for a chat. Obviously this is even easier if you have someone that can introduce you, but even a cold email introduction will normally go far. Try and base it around a subject though; a simple “Hi I’d like to get coffee” might come across as strange, but “Hi, I was wondering if I could buy you a coffee to chat about announcement X whilst you’re in town” has always worked well for me.

It’s also important to “put yourself out there”. This is something that isn’t natural to us nerds, but seek the high profile. If there is a highly visible project then try and get on it. Create your own extra curricular projects in and out of work to try and build your reputation. These sort of things get your name in front of more eyes and increase the opportunity to meet new people.

Despite my initial disparagement, networking events can have a place in building good connections. The important thing is the format of the event. One of my favourite examples is Startup Weekend (which I’ve written about before). When you’re forming an actual team and working with a group closely for the best part of 3 days it’s a great way to make proper lasting connections. Activity based networking with team interaction (and competition) tends to lend itself better to strong connections than casual networking events.

The most important piece of advice I can offer: never ever write off a connection. Unless you really can’t stand someone, always part ways amicably with people (particularly colleagues that are leaving). The world of IT is ridiculously small and bad reputations can spread quickly. Conversely, I’ve been amazed at how some people I’ve worked with have jumped to impressive and surprising places.

This advice all sounds relatively cold and heartless — talks of connections and contacts purely for the sake of career benefit. In the real world it doesn’t end up like this though. We are naturally drawn to stay in contact with the people we meet and like and get on with, which means your network will naturally grow with people who you like and enjoy working with. The important thing to pay attention to is that you must actively seek to increase the size of your network. It will directly accelerate the speed of your career. The more people who know you (and speak highly of you) the likelier you are to be put up for promotions, for the exciting projects, and to have someone defend you when you are being bad mouthed behind your back.

Why aren’t you writing online?

Why aren't you (1)

One of the things I’ve found surprising whilst working with DZone is the seeming lack of tech blogs in the universe. All the people in our MVB program get syndicated into one big giant feed. And there really isn’t that much content!

I strongly believe that writing online is one of the most important things you can do for your tech career. Here’s why:

1. It Puts You Out There

I think one of the reasons a lot of people don’t write blogs is a fear that they will be speaking out into the void. They’ll put some content up and no one will ever see it.

Let’s for a second assume that’s true (it isn’t and I’ll explain why shortly). Even if no one ever reads your stuff then you still have a repository of material that you can point recruiters and other potential employees to. It shows that you’re using your brain and that you have an opinion, and having an opinion is one of the most important traits of a senior developer. Putting your website on your CV or business card means someone can go there and see what you’re about, what you stand for, what you’re up to, and what you know. That’s valuable in itself.

The reality is you won’t be shouting into the void either. As long as your site is registered on Google Webmaster tools even if you do zero promotion you’ll eventually get indexed and start to appear in the rankings. Places like Bing and Yahoo have very poor algorithms that mean any post can get to the number one spot with very little effort. You’ll start to see some traffic trickle through.

It’s easy to promote your stuff as well. If you’re spending the time to write these posts you should be proud and want to show them off. The easiest place is Reddit; pop your post on whatever the relevant subforum is (e.g. /r/Java) and watch the hits roll in. Reddit is a finnicky beast though; it’s better to hang around for a bit and post on some other topics before posting your own on there, or else you’ll be downvoted to oblivion. A little interest in the community can go a long way.

DZone is genuinely a great tool (I’m not being paid to say this). You can submit posts on your site and they’ll go into the big article feed where people can up and downvote them. You can register for the MVB program where DZone will repost your blogs and guarantee you an audience (with links back to your blog). Or you can even write directly for DZone! It guarantees people will see what you have to say.

2. It Makes You Try New Stuff Out

I have a strict schedule of putting two posts out a week. I’m at a particular disadvantage as I’m travelling at the moment and don’t have a day job to write about, but I’m forced to look at new technologies to play with to write about. And it’s awesome! I always found it hard to check out new tech and libraries purely for the sake of checking them out — I need a purpose to motivate me. Writing a blog post is that purpose. It’s well established that teaching is a great way to learn about new things as well. I’ve been able to play with and learn Dropwizard, Wiremock, and Grafana along the way which I wouldn’t have otherwise. You have to prepare to get a few things wrong (I got a few scathing comments when I incorrectly named the ELK stack in this post), but overall it keeps the brain active and you constantly learning. This can only help your career as you can bring new things to the table in the day job.

3. It Makes You Formulate and Explain Your Opinions

It would be too hard for me to churn out new technology posts every single time, if only for simple time constraint reasons. As a result a lot of my posts are opinion pieces, often around code style, approach, or design.

When putting this sort of thing down to paper (or screen) you have to consciously take a position and explain yourself. This is difficult for sure but I guarantee it throws you out as a better developer on the other side. For me one of the most important facets of a senior developer is to have opinions and to be able to back them up and explain them. One of the best developers I have ever worked with is incredibly opinionated and has a strong explanation for every single one of them. It can be incredibly frustrating sometimes, but if you can prove him wrong he will happily change his mind which is the ideal for a tech lead.

Writing a regular blog is enabling me to take the steps towards this level of seniority. I have always had strong opinions on stuff (always in beta and happy to change), but when it comes down to really explaining them to someone I often faltered and struggled to do them justice. Each and every opinion I write about I have to be able to fully justify and explain over the course of 700-1000 words.

That’s not to say everyone agrees with me. I’ve in fact discovered that disagreement is the main reason people will bother to comment. And that’s fine. You’re never going to get everyone to agree, and for every sensible comment there’s going to be two from trolls. You learn to accept and get past this.

4. It Will Get You Noticed

Throw enough stuff at the wall and eventually something’s going to stick. Not everything you write will be gold but some pieces will be brilliant and they will get noticed, you just need to be patient. My most popular post ever was one called “Why I Hate Spring”. Whilst it had always been popular on my personal blog (popular being relative, as my blog had very little traffic) about 2 years after writing it someone picked it up and reposted it somewhere (reddit or twitter or DZone, not sure where the origin was yet) and it blew up. My website had 3000 hits in a day (and it had only had about 6000 in 3 years) and many more in the various other places it was posted. I actually got into discussions with the leaders of Spring. It was a pretty landmark moment.

Since writing with DZone (and the much larger audience that it brings than my blog) it’s gotten me noticed a lot more. In my day job (that I’m on sabbatical from) the posts get regularly syndicated and discussed internally, increasing my profile which can only be a good thing. It contributed to me landing my first ever conference talk at Redhat DevNation in June. It’s allowed me to get into conversations with the guy that invented Google Docs along with key community members in Spring, JavaEE and other areas.

So if you don’t have a blog you’re regularly posting to yet, why not start now?

 

This post originally appeared on DZone.