Breaking into Software Development

Alex Potter By Alex Potter 22-11-2018 3 minute read

Breaking into Software Development

At Ghyston we look for people with the potential to become fantastic software developers, even if they have no prior experience. We assess people on their ability to solve problems and communicate their solutions, not on their knowledge of programming languages or computer science concepts. Even if you’ve never written a line of code in your life, you can still apply to Ghyston and be successful.

Having said that, we’re interested in applicants who are interested in coding, and most successful candidates will have written at least a few lines of code before applying, whether that’s through a university module or by tinkering in their own time. If you’re genuinely excited about software development as a career, there’s a good chance you’ll have found a way to do at least a bit of coding at some point in your life. You may feel that this contradicts our claim about prior experience, but it doesn’t—the point is that solving problems by writing code is a great way to exercise the skills we’re looking for, but it’s not a prerequisite for having those skills.

This blog post is primarily aimed at people who are interested in a software development career (whether that’s at Ghyston or elsewhere), but have no idea how to get started. I’ll explain why doing even just a little bit of coding can improve your chances of success, and in part two (coming soon) I will give you a number of recommended resources to get you going.

If prior experience isn’t required, why should I bother writing any code?

More than anything, software development is about being able to think in a certain way. To simplify it massively: it’s about being able to think like a computer. To be a successful software developer you need to be able to take a problem and come up with a set of well-defined steps (i.e. an algorithm) that a computer can perform to solve the problem.
The word “algorithm” can sound scary and technical, but that’s really all it means—a set of instructions, not necessarily written in code, but which it’s possible to translate into code. The fact that algorithms don’t have to be expressed in a formal programming language is the reason we don’t require candidates to have any coding experience—if you’re a talented problem solver, it doesn’t matter that you don’t know C#, or Java, or whatever, because we can teach you. This is what we mean when we say that we hire people for their potential, not their experience.

Now, just because we don’t require you to have coding experience doesn’t mean it’s not useful. The truth is, having written even just a little bit of code in your life is a big help, not because you’ve learned some specific programming language, but because it forces you to practice thinking in a certain way. Let me expand on this with an example: the concept of control flow.

Control flow is essentially about decision-making—an algorithm that accepts a generic input may need to take a slightly different approach depending on what input it’s given. Control flow statements are essentially just checks performed during the algorithm which allow a choice to be made about which path to follow. You’re probably thinking this isn’t interesting, and you’re right—we can all grasp the concept of doing things slightly differently depending on the situation. The point I want to make with this particular example, is that we humans can think on our feet and make decisions on the fly, whereas computers need to be told ahead of time what to do in all possible situations.

The skill here is identifying the different cases your algorithm could possibly run into—including the subtle and/or unlikely cases (often referred to as “edge-cases”) and making sure it copes sensibly with all of them. Similarly, it’s about being able to look at an algorithm you think is complete and come up with situations in which it doesn’t work.
This all sounds pretty simple, but it’s not easy to do. As I’ve mentioned, this sort of thinking isn’t a natural part of our lives, so there’s no real reason for us to be good at it without a bit of practice. The simple truth is: people who’ve spent time (even just a little) solving problems by writing code are more used to this sort of thinking than those who’ve never tried it at all. It’s not about the specific syntax and grammar of the programming language they used, it’s about the way they’ve had to think.

Conclusion

Hopefully you can see what I’m getting at with this example—you may have a natural talent for the sort of thinking required to be a great software developer, but if you’re not used to it you’re probably going to struggle at first. Now that I’ve convinced you that writing code, although not a prerequisite for being a successful applicant, is a really useful thing to have done before applying, how do you get started? Check back for part two - or sign up below to be notified.

Share this article

Subscribe to our monthly newsletter about hot topics in the industry