From Academia to The Real World™

My CV – This only gets you the interview, you have to do the rest

It feels like yesterday, but it has now been 50 weeks since I graduated from The University of Hull. I know this because its my Birthday in 2 weeks — and theres the small matter of Charlotte graduating (Well done!). The ever-accelerating passage of time has meant that in recent months I have turned my attentions to planning out what I intend to do once my MSc is over.

This blog is primarily written for me to look back on in a few years and hopefully say “look how far I’ve come” or quite possibly ask where it all went wrong from here. However, it may include some useful tidbits of information for future graduates looking for jobs.

My job hunt started when a company well known for their search engine approached me offering me an interview for a Graduate Software Engineering position in either Mountain View or London. This was exciting. I was invited for a final interview having completed a telephone interview with an software engineer/team leader. At this point I had to decide if I wanted to work in either London or Moutain View — opting to work in Moutain View meant that my interview had to take place within a week due to certain visa requirements — in retrospect I should have waited and gone for the London job with more time to prepare, however the draw of a Californian life-style was too much! I can’t actually write about what I was asked in the interview, however I can say that it was a fantastic learning experience. Anyone who gets a chance to interview at a large tech firm certainly should, even if its only for the chance to better their skills.

In the end I wasn’t offered the job. I was dissapointed but the lady from HR told me I was close to getting it and should reapply in a year or two once I had more experience under my belt. This was both reassuring and something nice to work towards.

Around the same time as that interview I was engadged in a process alongside Dr. Dan Franks to apply for funding for a PhD program, in which I would work on an Evolutionary Computation project dealing with issues of crowd behaviour in evolved systems and comparisons to the real-world. This was an awesome project and I appreciate the work Dr. Franks put into my application with me. I also appreciate his honesty when it came to discussing whether doing a PhD was right for me at this time in my life — in the end I came to the decision it wasn’t. Whilst I love research and doing new and exciting things I was more interested in getting my teeth into some real-world software engineering projects and improving my skills in that area. I hope that a PhD is something that I come back to at some point later in life. I was offered the PhD on a full stipend and fees paid, but turned it down after a lot of reflection.

A few months passed as I knuckled down on the last few modules of the taught portion of my course but now, as I wrote previously, I am in the research semester of my Masters Degree — whilst this is in some ways no less busy than the taught portion of the course it does have the advantange of being a period of time in which I don’t have to be physically located in York for anything other than a weekly supervisor meeting — this has given me the oppertunity to go job seeking again.

Without enumerating over each interview process I’ve gone through over the last 3 weeks, because there been rather a few, I want to make the following observations:

  • You will probably recieve a few emails thanking you for your time but informing you that the company doesn’t wish to move ahead with your application. A few rejections in a row can get you a bit down, but…
  • There are many reasons for not being offered a job. As many, if not more, than there are to be offered one. It could be something as simple as not being as enthusiastic about their technical platform as you are about say, Node.js. So don’t take anything personally and behave professionally, don’t take it to heart.
  • Doing interviews will undoutedly make you a better Software Engineer. After a few weeks of Data Structure, Algorithm and Software Architecture questions coming at you in a high pressure environment you’ll notice how much your thought processes have changed and how much you’ve improved.
  • Attending interviews is a great way to discover if you think you could handle commuting every day. In the past 2 weeks I’ve travlled over 3,000 miles doing interviews (York to London return is 431 and a half miles). I came to the conclusion I could, quite happily, travel a (shorter) distance each day
  • You will know if you would work for a company within an hour of being there. I remember one interview in particular where I knew very quickly there was no way I would want to work there (the best thing to do in this situation is continue as normal and be professional). Other times you’ll experience what you percieve to be your dream work environment. Remember, you’re interviewing the company just as much as they’re interviewing you. You’ll be spending 8 hours a day there, 5 days a week for the foresable future. There are plenty of CS jobs avaliable so make sure you get one which is good for you. If you like a job that also means you’ll work better for them, so its good for them too if you turn down a job you wouldn’t love.
  • Every company interviews in a slightly different way. I personally found a mixture of programming on a PC as well as ‘whiteboarding’ data structure and algorithms gave me the best environment in which I could show what I percieve to be my skills. Some companies only do one, or the other, which is a shame.
  • You should read “Code Complete” and “Programming Interviews Exposed” and brush up on your Data Structures and Algorithms before going to any interviews (I wish I’d done this before going to that search engine company), you’ll thank yourself for it.
  • Companies love enthusiasm. Proving you’re enthusiastic about Computer Science is quite easy, especially if you have a blog like this one, however as quite a stoic person I found it hard at times to show enthusiasm for a companies product — especially if that product was not public facing and therefore I’d never had a chance to use it. I’m not really sure what to say or do to help these situations.
  • You will be asked about anything, no matter how minor it is, that is on your CV. Fortunately everything on my CV is true so it wasn’t too bad, I can only imagine how hard it is if it isn’t.
  • There are some questions you will be asked by every company. You should work on refining your answers over time. The two I got asked everywhere were “Why don’t you have an A-Level in Maths?” and “Why did you decide to do a masters degree at York?”.

Just yesterday I formally accepted one of the 4 job offers I had received in this process at a fantastic company, for whom I’m very excited to be working for. I’ll write more about that in my next blog post!


Programming Software Engineering University

Fun with Formal Language

It’s been a while since I’ve updated you all on my progress regarding my final year project, in which I’m building an integrated development environment for the PHP scripting language.

At this stage I’m researching different methodologies and algorithms for what I want to achieve in my first prototype, as well as different methodologies for the actual software engineering experience in, and of, itself.

Whilst doing this I’ve found that writing code for the algorithms I’ve been researching has been super useful in determining the ease of implementation, and actually understanding the ideas involved themselves. In the above screenshot you can see an example of one algorithm I’ve implemented to tokenize my code.

Tokenization is the process of identifying the name and value of each token in a piece of code. A token is just a set of symbols, such as a $variableName or a keyword such as true — or even a simple code delimiter such as ; or { or }.

The above screenshot shows the code as highlighted by Visual Studio and as highlighted by my program, some of the formatting is a tad different than you would expect, but this is a very early version of the program and won’t be used as part of my final product — it’s just to help me visualize how an algorithm works.



Software Engineering and Human Computer Interaction – Algorithm Coursework Result – 96%

Today I got my result for my Algorithm Analysis Coursework for the Software Engineering and Human Computer Interaction module.

The coursework assignment was to build three C# programs from pseudo-code — an explanation in English of what the algorithm should do — and then analyse them using techniques we had learnt in the module. We then had to come up with a conclusion on the efficiency of each algorithm, and finally we had to say which “Big O” notation an algorithm was, Big O is just a measurement of algorithm efficiency.

I felt I did quite well and it seems I was right because I got a mark of 96% which is pretty good! This means there is less pressure on me for the Software Engineering exam which is in a few weeks time. Wish me luck. 🙂


Programming Tutorials

Sorting a List of Classes

Today whilst writing my Highscores library, which I’m currently using for Sweepy Cleaner but intend to also use for future XNA games such as those I’ll make at 3 Thing Game, I discovered an awesome feature of lists in C#.

This List.Sort() method, documented here, allows you to sort a list of classes and, because it uses the recursive QuickSort algorithm, its really quick! By default the Sort() method can sort any primitive types, such as strings, ints, float and doubles, without any parameters, which is pretty good but doesn’t allow you to fully utilize the method. This is where the IComparer interface comes in.

An interface, for those who don’t know, is like a rulebook. It says “if you claim to be a comparer, you must include methods with these names, that return these types, otherwise I wont let you claim to be a comparer by stopping you from compiling”.

An example person interface might be like the following

interface Person
string returnName();
int returnAge();
void Eat(string foodType);

This basically says “To be a person you must have a method which returns a string called returnString, a method which returns an int called returnAge and a void method called Eat which accepts a string parameter”. If you miss one of those methods off from your class, which then claims to be a person or you have a returnAge method but it returns a double rather than an int or an eat method which doesn’t accept a string parameter your code won’t compile, so you can see that Interfaces are pretty useful for making sure your classes adhere to a certain rule set. 🙂

The IComparer interface comes in useful, it dictates to you how to make a class which tells the Sort() method how to sort your list of classes.

A class which implements the IComparer interface must have a public int Compare method which accepts two objects in its signature. So if we’re sorting people by age we might have an IComparer like the following.

public class PeopleComparer : IComparer
public int Compare(People person1, People person2)
int returnValue = 1;
if (person1 != null && person2 != null)
returnValue = person2.Age.CompareTo(person1.Age);
return returnValue;

As you can see, our PeopleComparer claims to be an IComparer using the ":" syntax. We then have a method inside the class which returns an integer, with a signature which accepts two People objects. This returns a number based on the CompareTo method which can compare integers, such as our age variable. You could compare height by changing only two words. e.g: returnValue = person2.Height.CompareTo(person1.Height);

(By the way, don’t worry about return value initially being set to 1, this is just to stop the “use of undefined variable” compilation error.)

We can now sort our classes by doing something like

List peopleWhoReadDannyComputerScientist = new List { };
//Imagine this list is filled with 1000 people.
peopleWhoReadDannyComputerScientist.Sort(new PeopleComparer());

The peopleWhoReadDannyComputerScientist list would now be ordered by age, allowing you to do all sorts of cool things, like binary chop search. 🙂

Its as simple as that,


Algorithms & Logarithms

(A flow diagram showing the process of working out a problem, making an algorithm to solve said problem and then programming it so a computer can do it for you)

The feature image for this post describes a lot of my day. It shows what we learnt about what an algorithm is in our 2nd Programming lecture of the week and it also shows how I have typed up all my notes and made them a lot more professional and graphical. The aforementioned lecture took place at 4:15 so I had the entire day to myself until 3:30 at which point I would have to catch the bus.

The day started at some time between 6:55 and 7:10 (I don’t know exactly when, either way it was far too early) however because of the “early morning fire test”. This involved me jumping out of bed, putting some jeans on (I tend to sleep in a shirt anyway) and slipping into some boots and then walking calmly (read: Running) out of the door of the block. All of Lambert was out of their halls in 2 minutes and 36 seconds, a healthy 24 seconds before the buildings would have burnt down. 😛 This was particularly impressive seen as we have a deaf boy in our block.

After a few hours sleep to recover from such an early morning I woke up and texted Jess for a while before tidying my room, emptying my bins and making myself a lunch of Bacon Toasties. By the time I had collected a package (full of basically a weeks worth of clothes! Excellent!) and packed my bag for the day and checked the previous days lecture notes it was time to go!

The lecture consisted of learning about what algorithms actually are (essentially methodologies for doing certain tasks) and looking at some example problems which could be resolved. When I got back to the lawns it was more than time for dinner! This consisted of Gammon and chips and a chocolate donut —  it was lovely!

Soon after this me and Jess got our maths vibe on and she taught me Logarithms. According to wikiedia:

 logarithm reverses exponentiation

Essentially this means it lets you figure out what power would have been used to get that number. It took me a long time but eventually I understood Logarithm with a custom base in addition to common Logarithm (where the base is always 10).

Thats all for today, thanks for reading!