Computer Science Blogs

Final year Computer Science student Clíodhna Connolly describes the benefits of her internship with Deloitte…

Going into Computer Science in UCD I knew I wanted, at some stage during my degree, to do an internship. I knew I’d have to allot time over one of my summers to try get my hands on one.

The summer of third year was when my efforts of applying finally came to fruition. Applying for internships and even graduate positions can be a lot more time-consuming than most would imagine. It’s not just your academic prowess that companies want to examine but what motivates you, what inspires you, what kind of people do you admire and also why do you want to work for their company. So early into February I applied to Deloitte, a company, at the time, I didn’t really know too much about, nor their technical positions. Shortly after applying I was invited to an hour-long interview in Deloitte HQ where I was interviewed by a department representative about the competencies I had spoken briefly about in my application, (a time when I showed leadership etc.). I was quite happy with how the interview went and a day later I got a phone-call from Deloitte saying I had got the role.  I now had a role as a Technology Consultant Intern lined up for the summer and although I still didn’t know much about what this entailed I was thrilled.

Summer finally rolled around and I found out more about what my internship involved. We had a two-day induction period which helped me a lot to know more about the company I was working for, the work that they do and the work that I’d be doing. My internship was a bit different from what some of the internships my other friends from college were doing. In Deloitte, it’s a very structured internship. At the beginning of June over 140 interns began either 6-week or 12-week placements. I was doing a 12-week placement and after the first 2-days of induction I saw on average only 2 other interns each day.

I quickly learnt that technology consulting means that you will spend almost all your time on client-site. After two days in HQ I was moved to Kilmainham where I worked in a Department of Social Protection office for the remainder of my internship. The aim out here was to help the department get more of their services online and they had thus hired consultants to help them achieve this task.

I worked on 2 different teams during my time out in Kilmainham. The first team was working on what was already a very established entity and so my work revolved mostly around testing as the development that was happening was a bit too in depth for me to take up in such a short time frame. After this team, I was moved onto another team where I really got to see much more software development. This team was working on a product that was still actively having major features added to it and so it was possible to give me a lot more development work.

When I originally went to Deloitte I had no web development experience and most of the technologies they were using to develop were entirely new to me. I had never used C# before, which was the primary language used for development, but after a little while spent reading through a beginner’s guide book and reading through the existing code base I had got my head around the majority of it. One thing everyone had told me about internships, although I never really believed them, was that the primary aim was for you to learn. This couldn’t be more true from the experience I had in Deloitte. I was given all the time I needed to familiarise myself with the systems and code they used and members of staff were always more than happy to help explain something if I needed it.

One of the perks of being involved in such a large company and such a large internship program was that there were an awful lot of interesting activities for us to take part in. Almost every Friday afternoon I would be invited back to HQ to be given a talk the other departments in Deloitte, what they do and what kind of people they might be looking for. Beyond this we also had a lot of days focussing on our personal development and to help us plan our careers.  We also had an Impact Day in which the aim is to give back to the community. On this day, myself and a few other interns went and painted apartments of some people with disabilities. Not only was it good to be helping people out but it was also nice to be out of the office for a while and doing something different.

A major asset of my internship at Deloitte was taking part in the Intern Innovation Challenge. At the beginning of our internship all the interns were divided into 44 teams of 4 or 5 and given a title to inspire us to come up with an innovative idea. My team and I were given the title “How to use Technology on Deloitte Engagements” and after listening to the struggles of a tax intern on our team we saw an opportunity for robot process automation to be implemented on the engagements our colleague was working through in order to free up his time for more productive and beneficial work. Somehow, despite our concept being a bit more serious and more difficult to understand than our competitors’ presentations, our group won first place. We had been shortlisted into a list of 8 groups and from there we all had to present to a group of esteemed Deloitte employees consisting of several partners and heads of departments. We were delighted we had won, not only to justify the work we had put in but also because 1^st place had a top prize of €1000!

Overall, my time in Deloitte really highlighted for me how to apply the skills I had already learnt from my degree in UCD but also the skills I should focus some more on during my final year. The problem solving and software development skills I had learnt really stood by me well especially when I was adapting my existing knowledge to working with an entirely new language. The teamwork I had learnt in UCD, especially from my Project Management module, also stood by me as there was not one thing done in Deloitte alone. Unlike in college you are always a part of a group working on a project and it’s important that you already have some skills developed in this area. During one of the Friday afternoon talks I was told more about computer forensics and I found this area to be very interesting and because of this I have tried to incorporate this interest into my module choices in my final semester.

I would highly recommend an internship to anyone considering one. I know it can be difficult as it often clashes with J1s and interrailing etc. but there are real benefits that come from doing one. Both your college life and employment prospects can improve from the skills that you learn and who knows maybe even your internship might roll itself into a full-time graduate position like mine did!

Further information about careers at Deloitte including the Summer Internship programme is available at www.deloitte.ie/students

Final year Computer Science student Clíodhna Connolly describes her experiences in a Software Engineering Project module…

Battle of the Scrabble Bots

One nice thing about Computer Science is that mixed in with all the theory is a heavy emphasis on the practical. It means that while you’re completing your degree, you’re consistently working on projects and assignments that show you how the theory relates to real life. Every year, excluding final, CS students complete a Software Engineering Project module. The assignments are typically more interesting than normal programming assignments, but nothing beat my excitement of when we were assigned Scrabble.

The ultimate aim of our module was that we’d build a scrabble-bot. We had around 10-weeks to build ourselves up to that point and at the culmination of the module we’d have a battle of the bots to compete for first place! As it turns out there was a lot of people who never had played Scrabble, so a lecture or two was dedicated to how to play the game and taught us new words like “Quizzify”, which inspired a few team names.

Week to Week

If the technical aspect appeals to you; we were programming entirely in Java and our user interface (the visual bit you see) was just the console (the black thing people fake-type in movies). Every two weeks we were given a new assignment description, our end goal was to complete an entire Scrabble game but the lecturer laid it out so that we built it up gradually, in small manageable steps.

For instance, the first assignment involved setting up the playing board, the player profile and the pool of tiles. We were free to split these tasks among our groups as we saw fit but most people split it so that each person took one area. The tasks started off easy enough just setting about the basics of what we’d need, as in for Player we need somewhere to store their name, their score and their frame (the thing that holds their tiles).

After the assignment was due the lecturer would release his solution to that week’s tasks. This what I found to be the most useful part of the class. Being able to compare your code to an actual experienced coder was great to see. You could tell if what you were doing was right or wrong and where you could improve. The other thing about this was that if the week before had gone terrible and none of what you submitted worked, you could take the previous solutions code and work off that for the following week so you were never at a disadvantage if you’d had a particularly bad submission.

BUILDING OUR BOTS

For the last assignment we were tasked with building our bot. We were to base our bot off of code that the lecturer provided, so that when we’d compete with others the bots would play nicely. The rules were that we had a three-second limit per turn but our bot would have access to a dictionary. The time-limit was what really made things interesting. Without it you could have a bot sit there for hours before it’d make a turn, going through every possible permutation the board and dictionary would allow. Because of this we had to start making decisions about what we thought would be the most time-efficient and highest-scoring methods.

We started simple, our plan was to identify a position on the board where we could place one tile to make a two letter word with what was already on the board. Even this simple plan had a lot of checks we had to do:
• Check all the surrounding tiles were also empty or else you’d end up making an unintentional word
• Check the dictionary for two letter words using the tile already placed and what we had in our frame
• Check which orientation of placing the tile was best, before or after placed tile
• Check was there position we could place a better 2 letter word

CHAOS, CHAOS EVERYWHERE

After a while we got our simple plan working. We even got up to four letter words being able to be placed before and after a placed tile. Behind the scenes I had been working on what I referred to as BetterBot; Bot was our submission, he was clean, he was simple, he worked, BetterBot was an abomination. However, BetterBot could play well, it could extend words and it never ever passed. It always found a word to play and it was typically good. The problem with BetterBot, apart from being hideous code, was that it entirely ignored the time limit; sometimes it would take 2 seconds sometimes 10. Because of this inconsistency we thought we could never use it and it’s why I kept it on the back-burner as more of just my entertainment as opposed to anything we could submit.

The bots were due to be submitted at the end of a 2-hour practical on a Friday. Really, entering that class we all knew that we wouldn’t get much done because the deadline was so close. We imagined that we’d just be cleaning up our submissions but then it was announced that they were doing away with the time-limit. This is when the chaos hit. I wish someone had filmed us because it was probably the liveliest practical we’d ever had.

People were testing their bots against others in the class. Bots were crashing out left and right. Some like our group were taking their secret bots out of the background and trying to get them to work well enough that they could be submitted. Our BetterBot became BestBot and we desperately tried to clear all our errors in the hopes we could submit him. The competition mark counted towards our grade and the competitiveness in the class was palpable.

THE AFTERMATH

The following Friday we received an email with the competition results. As Dr Chris Bleakley, the lecturer, explains the competition was played in 3 rounds.
“In the first round, each Bot played all of the other Bots. Each pair of Bots played each other twice (home and away, if you like). In the second round, I played the top 4 Bots against each other. Each pair played 20 times. In the third round, I played the top 2 Bots from the previous round against each other 60 times. Games were recorded as incomplete for both Bots if one of the Bots crashed or hung or if the game lasted more than 10 minutes. The purpose of the second and third rounds was to remove any confusion due to incomplete games and to average out the random element over more games.”

The first round took a whopping 30 hours so it’s no surprise he took a week to come back to us with results. My team placed 6th which we were more than happy with. We ended up winning 20 games and 8040 points and as we put it, we came second fastest out of the top six by a mile.

This module was probably one of the most useful modules I did in Computer Science. I still talk about it in job interviews because so many skills were tested in it and we learnt so much. Having a somewhat useful application built at the end of the day was also an added plus. I still haven’t beaten my Scrabble bot but that’s probably more to do with my attention span being incompatible with Scrabble than anything else!