This post is for those about to graduate a degree in CS, engineering, etc, and
about to venture off, bright-eyed and bushy-tailed, into the tech world, and
wondering how to get a job. Maybe you've done a couple of interviews already
and got an uncomfortable reality check that your 4-5 year degree wasn't enough
to convince people to hire you. Maybe mum and dad were utterly and completely
wrong about how qualified a degree made you. I'm going to give you some hard
facts, some good news, and finally some suggestions for things to prepare
(and how to prepare) before doing interviews.
If you have a bachelor's or honours degree → junior engineer.
The master's degree is the new bachelor's degree.
A degree (of any sort) isn't enough on its own to get you a job in your field.
Tech employers have an irrational fear of training new staff.
You must demonstrate a history of competent teamwork.
You must have skills with tools you probably didn't learn in college.
Many tech employers are set up to exploit and burn out young grads - beware!
Doing tech interviews is a new skill you need to learn.
Writing a tech CV is a new skill you need to learn.
Several stages of interviews are designed to find out if you are a jerk.
If you're used to doing work solo, and not explaining details to others, you will do badly.
Doing a placement or work experience whilst studying is a good idea - make friends and ask for career advice.
The Good News
Good employees are very hard to find, and it can take ages, and be very expensive in terms of opportunity cost - if you're good, you hold the negotiating power, not the employer.
The specific tools and techniques you need to learn for industry are pretty easy to learn.
Getting some coaching for interviews and CVs will make them 100x easier.
If you're a nice person to work with that has real value to a team.
The Best Possible Solution to Bridge the Knowledge Gap
Find a mentor - currently working in the industry - to coach you. This may be a family member or a friend in a senior
tech industry position. If not - approach people and ask for help. Most tech
employees would love to help the next generation but aren't really sure how to
go about it. Send a polite email to someone in your chosen field - maybe not in
a company you are going to apply to - and if they don't want to, ask if they
can recommend someone. Give them a list of the sort of things you need help
with - see the next section for suggestions. Stephanie Hurlburt is always retweeting senior programmers
willing to mentor or answer questions. If you have this gap bridged you'll be
far more confident in interviews, and already know the questions that are coming
and what the answers are.
Don't hate your university or college for not preparing you - the role of the
university should absolutely not be to provide training for the fickle desires
of industry. You would end up with a bunch of rubbish, throw-away skills that
are out of date by the time you graduate. Industry and big corporates approach
universities all the time with lucrative deals so that courses will teach their
exclusive tools and technologies. This used to really piss me off when I would
hear about other lecturers accepting these deals. All of the courses I did like
this when I was studying were extremely expensive and utterly useless. Nobody even asks for UML
diagrams in job ads any more, and certainly not out-of-date proprietary
enterprise software deployments. The tech industry changes its mind entirely about tools and
management strategies every five to ten. We would have been much better served
with more in-depth programming courses and computer science instead.
Things You Need To Get A Tech Job - Checklist
Can write a current tech industry CV to suit the bullets on the job ad.
Know how tech interviews work, how candidates are reviewed, and what the stages are.
What salary to ask for, and how to justify it.
Can demonstrate your value to specific skills in the role.
Know how projects are managed in the current tech industry.
Can demonstrate your experience with teamwork on software projects.
Can demonstrate your knowledge of version control systems and branching strategies.
Can demonstrate your knowledge of Agile project management techniques and software tools.
Can project your personality as being a nice person to work with.
Can clearly explain programming concepts to others (in presentation format).
Have actual experience with many of the specific tools, languages, and techniques on the job ad.
Can work around stupid questions from recruiters without getting grumpy.
Can project confidence. Do not look desperate (this may be hard if you're actually desperate). Will not let them name a low salary because it's a starter role.
Demonstrate that you're ready to start working on real work straight away, and not that you're using the job as a learning opportunity.
You will inevitably end up working in collaboration with non-engineers - designers, artists, performers, customers, etc - if you have a history of being able to do this it will help a lot.
You must be able to solve code problems on the spot - code in front of people or use a whiteboard.
You can see how some insider knowledge is going to help you a lot - ask for
mentorship from someone who has interviewed candidates for similar roles. Start
this earlier - ideally months before you need the job.
Specific Tools and Agile Project Management
The tech industry more or less entirely uses Agile project management now - at
least in name - actual implementation varies a lot. The basic process is this -
the more demonstrable experience you have on team projects working like this the better:
TODO jobs are assigned cards or tickets, and some "story points" to estimate how long they will take. Much like tech support tickets. Concise description and linked jobs are added.
Tickets or cards go into a backlog (a big pile of work to do). This may be in a column on a Kanban-style board (like an actual real board, or a Trello board),
or in a list as you will find in Jira.
Backlog tasks are prioritised (either by the team or by a manager) and assigned to engineers for the next sprint of work in a planning session.
Sprints are usually a fixed period of a week or two. Tickets are highly visible to other team members, and you usually collaborate to some degree on each task.
You constantly communicate the status of each job - when you start, what you're blocked by etc, to the team. Usually in online management software.
When you start a coding task you follow your organisation's version control strategy - some places create a branch for each task, smaller places work in main/trunk and use commits per task, etc. There will be rules and a process.
When you commit work, usually this is tied to continuous integration software/servers that will try to build the software, using your new commit, and report on success/failure.
Committed work doesn't go straight in to the build - you make a pull request, and then most places now use a code review at this point where other developers will try to spot bugs and comment on your work - usually using a diff of the new and old code, but not always.
Reviewed work is either sent to quality assurance for testing (this will be your team in a small company), and finally moved to a "done" column or status.
As you proceed on tasks you update your time estimates or "story points" - note that this is much more flexible than the Gantt chart rubbish they teach in college, but very micro-managey.
Every day you will have a stand-up meeting (literally standing to discourage people rambling on and wasting time).
If you look at job ads in advance (and you should) - almost all of them expect even graduates to have
experience with this process, and related software. You probably don't get this in college.
It's worth getting some practice in a group project:
Absolutely learn how to use some modern project management software. I really like Trello (it's a Todo list with pictures), and use it for my own projects, as well as consulting work to keep clients in the loop. Most employers use Jira.
Try some sprints with a team, and daily stand-ups. This has more to do with communicating work than actually being fast. Most people feel good with short milestones - most people will be broken seemingly endless jobs.
At the very, very least learn and use Git for assignments or projects (GitHub has free private hosting for students).
Try a couple of branching strategies and get used to doing pull requests - a GitHub or Bitbucket project is a great way to practice this.
Do some code reviews.
Get used to finding bugs and reading others' code.
Recruitment agencies may seem like an easy way to get some coaching, but they are pretty
useless unfortunately. They go for quick turn-around to make profits, and will pre-interview
you with very ignorant questions about things that aren't important. If they think you're
suitable for a job, what they do is put you in a pile of CVs that they submit to the company
for that job. Your odds aren't great straight off the bat - and employers know that agencies
are terrible at filtering candidates, and often put the pile straight in the bin. It might
work out for you - just make sure you have a yes answer for every bullet on the job ad, and
tell them what they want to hear. You're IMO far better off applying directly - put the hours
in to researching companies and networking yourself.