May 23, 2016
|
9 min read
How to land your dream startup tech job after uni
Insider tips to making yourself useful before you even graduate.
by
Timon Sotiropoulos
Lead Software Engineer
When I studied at RMIT I saw students from a broad range of fields that had made the shift into Information Technology (IT) – photographers, project managers, trained economists, teachers. Even my undergraduate degree was in music.
Yet, for all those students that completed the same course as me – a Master of Information Technology – most of them had changed back to their original field and weren't successful at transitioning from their old careers into their new one. Even though they were now qualified as Masters students in the field of IT.
With university enrolments for IT and Computer Science degrees, we have seen a steady growth of the number of students commencing these courses since 2011.
This has coincided with new Masters degrees that can be completed by coursework with an undergraduate degree in any field, instead of only a traditional Computer Science degree.
Now, I respect that the changing nature of the IT Industry is a particularly difficult one for many people to keep up with.
To take what feels like the daily evolving culture of the industry, then try to not only navigate those changes, but to upgrade a major universities' syllabus to try and reflect them, just isn't going to work.
I, however, was one of the lucky ones. I managed to not only secure an internship, but a good one that gave me the industry specific training that I needed to be useful to an actual tech business. Skills that out of course graduates should know about, but were barely, if ever, touched on at uni.
This is a short intro to what I think are some of the most important things I learnt during my internship and during the first six months after finishing my Masters.
It was absolutely ludicrous that no where in my course, before I started my internship, had the concept of a code repository like Git had even been mentioned. I had completed a subject called 'Advanced Programming' and collaborated code on other projects with students, but still had no idea what a repository was.
Imagine the horror on my colleagues' face when a new intern rocks up on his first day, only to reply with the blankest of stares when asked to pull down the repository from 'GitHub'.
The most ridiculous part about this is that instead of learning how to add code to a repository, we were taught to back up our code by zipping it and emailing it to our personal RMIT email accounts. Instead of using the industry standard for code sharing and version control, we were told to send emails. It still sounds insane saying it out loud. A simple crash course on Git, (http://www.sitepoint.com/git-for-beginners/) even if we had to pull a zipped copy of the repository down to submit it through the online portal, would have made a lot more sense.
When I started my internship, besides having been exposed to quite a few things and having a good grasp on the fundamentals of what programming was, I had no real programming value.
I remember being asked in my interview what I thought I was currently worth as a programmer. Even though I thought at the time, "well, $10 an hour seems fair for my skills," I knew I was still a fair way off being actually employable in the real world.
So, at the beginning of my internship, after being given my first assignment of 'learning front end web-dev', I didn't just work hard, I also studied and spent all my time working on a short course that would train me in all the front end web-dev stuff I needed.
I used teamtreehouse.com which has a free trial, excellent videos as well as a great 'stream' that covers all the required basics of Front-End Web Development. I drove my housemates insane listening to all those videos at twice the speed all day everyday, but after two weeks I had given myself the basic skills to actually start being useful to the business.
If you are really struggling for where to start completely and you still can't get the basics down I highly recommend doing beginner courses in a lot of different languages.
I tried to learn Ruby, Python, Javascript, C++ and even C (although that was a dramatic failure) before I finally was introduced and settled on Java at Uni.
The good thing about this approach was that I was constantly going over the very basics of programming, how to set variables, how to declare functions, how to write for loops, something that at the time felt tedious because I had just learnt how to do that in another language, was actually extremely beneficial later on because I had a really strong understanding of these fundamental programming constructs.
Something I found out very early on when working with people in the IT industry is that people really like sharing knowledge.
While you can still go out there and find the know-it-all computer genius, generally coders like sharing their knowledge with other people, normally because that's how they learnt in the first place.
What I did find important, however, was knowing when and what questions I should actually ask the people around me.
Most implementation questions, I found, while the person I asked would know how to do resolve my issue, would require a large amount of context into what I was doing while simultaneously destroying their work flow. Sometimes, as a rookie, that is going to be unavoidable otherwise you will sit there for hours staring at your code achieving nothing.
However the first call is to always try and find the answer yourself. This is such a critical step to learning to become a better programmer, because when you start working for a company you are essentially being paid to implement things. You will need to know how to solve those issues when a library doesn't work by trawling through Stack Overflow and Google for answers. When you have scoured all possible sources to your knowledge, that is when you ask someone else 'How the hell do I do this?'.
After a while you will find you stop asking implementation questions like 'How do I do this', instead you will start asking higher level architecture or design questions such as 'Should I do this like this, or like this?'.
I constantly ask high level architecture questions that help me understand when to make certain system design choices. Those questions give me the broader, more general understanding of why it is a good idea to do things in a certain way, then when it comes to implementing them, if I get stuck I always have my old friend Google for advice there.
Here are a few other quick points of advice that I have been given that I feel have been really helpful to keep growing in my current role.
This one certainly sounds high on the wanky side, but what it really means is that you aren't just someone that builds out HTML, CSS and Javascript. Instead, you can learn to solve any problem that's put in front of you. Be it writing an iPhone app in Swift, or writing a command line program in Python, a Software Engineer can figure out how to solve a problem regardless of the technology stack.
The classic programmer wars of which programming language is the best is ultimately frivolous.
Switching languages often, not only helps you reinforce the basic concepts of programming by trying to relearn, how to define a function in Python for example, but also increases your ability to read a larger variety of code as well as improve your versatility within an organisation.
Much like the language wars, the code editing or IDE wars can be just as annoying.
You're using Sublime Text? Why aren't you using Brackets. Oh you're using Atom? Why not use Vim.
The bottom line is that, like programming languages, there are some tools that for specific tasks will make them more efficient then others. Otherwise just use what ever you are most comfortable with.
Sometimes it can be a great help to actually write down the steps of what you are trying to do in plain English.
Programming is a logic and sequence based problem solving game, but in code it can very quickly look confusing.
A nested for loop iterating through a 2D array with a bunch of equality checks inside them won't be very clear if it isn't commented well.
The number of times I have thanked my lucky stars that I have written documentation (on very strong advice from colleagues) about how to run and deploy one of our applications has been un-countable.
Coming back to a project after two months of working on something else where you have improved all the build processes can set you back a day trying to understand how things are wired together. Not to mention if some other poor sucker is trying to read through all your old, rookie code and piece together how everything is connected.
It's amazing how many times I have thought, damn this code is looking so fine, only to return to it a month or two later and say 'What the hell was I thinking?'.
Besides reiterating the above point of always write documentation, you will always think of something new that you want to try the next time you start a new project.
Trying new ways to structure things or more complicated architectures is a great way to teach yourself as you go, just remember that the first time you try it, it will always look messy.
Probably the most important piece of advice at all, you just gotta practice actually writing code.
Coming from a music background, this was something I could highly relate too. I honestly believe that the key to mastering a skill is putting in the hours learning the right techniques, at the right time, preferably in the right order.
If you practised coding for eight hours every day for six months, explored its possibilities, tried new things, failed but tried again, you would be a 'very talented' coder in the eyes of many others.
In the end, making the jump from uni to work presents a few challenges.
You no longer have the urgency of assignments forcing you to study. You no longer really have the motivation of other students, waiting for you to finish that data structure before they can implement their piece of the puzzle.
Once you finish uni and you have decided you are going to head into the programming industry – even if you haven't found that job yet – get out there into the community. Go to meet-ups about everything and anything, contribute to an open source project on Github, come up with a really simple app or idea and try to implement it.
Going to university is really about the existential overview of how the IT industry works, to make the jump, what you will be missing is the experience of actually creating things and using the tools you have learnt.
The best thing is this process can start anytime, so if you get into it before you have even graduated, you will be perfectly positioned to score that perfect job while still wearing your regalia.
Have a unique idea to create your very own project? Get in touch with the great team at SEED to make an enquiry.
