A Reflection on Running a Week of Programming Work Experience

Alex Spedding
Towards Data Science
6 min readAug 8, 2018

--

I co-developed and supervised a week of work experience for two students who were mid-way through their A-Levels (for those not living in the United Kingdom, this means that they were one year from graduating high school). This article will document what I thought went well; and, if I had a time machine, what could have been improved.

I work as a Software Engineer at Ox Mountain. We apply machine learning techniques to automate processes in the equipment reliability sector. We are a small company yet still manage to have software teams on both sides of the Earth — Oxford, UK; and Perth, Australia.

When I was told I would be supervising two students on work experience the only information I had was that: one of the interns was interested in programming and our domain; the other had a slight interest in programming, but more so our domain. The other person who co-developed the work experience with me, is the Technical Director of Ox Mountain, Charlie Dibsdale.

This was not my first experience teaching programming. During the final year of my undergraduate degree (Computer Science) and throughout the first three years of my Ph.D. (also Computer Science), I helped out all three years of undergraduates and Masters students in various courses. I really enjoyed these experiences, and it was great to be able to sit down with people, explain concepts, and see them smile when it clicks and they understand it. Thus managing this work experience would be a great way to continue the teaching I had already done.

I thought back onto the week-long work experience I had ten years ago now. While I was grateful for the opportunity, I did not feel like I learned much and was not involved in anything the company did — it did not feel personalised at all. Each day I would be given eight hours to play around in some random new application with no goals being set, other than that there was no guidance. This was disappointing as I had already been programming for five years at that point so I had the expectation that I would be doing some sort of programming. So using the downsides of my own work experience combined with other experiences I believed would benefit the careers of the two students, I created some aims which I wanted to achieve with the guys I was supervising:

  • Develop a portfolio of work: The work that they did with us would be able to sit on a GitHub repository and be a start to a programming portfolio useful for the job application process.
  • Involvement with the aims of the company: While we cannot have them working on a real system with real data; the work they do should be relevant to the company with engineering data, and not just getting them to follow a random tutorial online which they could take anywhere.
  • Communicate with them beforehand and give them an idea of what they will be doing: This gives them the chance to do any preparation if they wish — personally before I start a job, I try to get as much information about the technology stack as possible to read up on. I find it helps reduce my stress and is a great excuse to buy yet more programming books.

With these aims in mind, we developed the structure for the week. It involved data analysis using Python (with Jupyter Notebooks) of some simulated data relevant to the industries we operate in, and by the end of the week culminating in a fifteen-minute presentation about the work they had done. The full set of tasks along with the data used to accomplish the tasks are available here.

All I will discuss regarding the performance of the interns — both for the sake of anonymity and it is not so relevant to the article— is that they performed excellently and it was great to see them work and present together.

A beautiful photo with a reflection (albeit not a personal reflection).

What Worked Well

  • The course was completed by both students and they each now have a GitHub repository with this work on.
  • A lot was learned: they both learned a lot of programming (one was starting from scratch, the other had some previous knowledge). I also taught them version control (Git and GitHub) and that made me realise that Git is very hard to explain to people who have not used it before. Trying to explain ‘git pull’ and ‘git push’, and telling them just to accept the ‘origin master’ part has to be there (otherwise I would end up falling down the rabbit hole of trying to explain the minutiae of version control).
  • Talking to the guys individually and learning about their life plans — and attempting to give a slight amount of advice with the little amount of life experience I have had.
  • They seemed to enjoy it, well, gave the appearance of enjoying it which is good enough for me!

What Could Have Been Improved

  • The focus was too much on programming. As previously mentioned, one of the guys had more interest in the engineering side of things so it would have been nice to drill more into that area. Though with my Computer Science background (and near zero engineering knowledge), it was natural it would end up biased towards programming. Potentially, it could be useful to interview them beforehand to work out what they want from the work experience — however, interviews for work experience may be a bit over-the-top. Charlie did chat to both the guys about the domain for around an hour, though I did not witness that conversation; but even so, 1 hour versus the rest of the working week still feels like it would have been unbalanced.
  • I never ran through the tasks myself. We generated the data and tasks without actually testing them ourselves. Now, this was only a minor issue with one of the tasks, but it caused a great deal of confusion to the students and was a bit embarrassing for me. One of the tasks involved summarising data in a box-plot, however, the data was a bit lacking and the box-plots did not look like typical box-plots. This led to confusion thinking that the code was wrong when in reality the code was correct. Lesson learned here: test everything first!
  • Time taken to present: Initially the plan was for them to work individually and present individually for fifteen minutes. They ended up doing a joint presentation but we still said fifteen minutes. In hindsight, we should have assigned a longer slot after the presentation for reflection and our feedback as we felt there were more questions and learning points to emphasise about their work.
  • Code review: The tasks used the Pandas library and they provide a rich set of data manipulation functions, many of which the students ended up manually implementing (computation of means, medians etc). One even implemented a bubble sort algorithm for the data. Having some time devoted to providing an overview of these features in Pandas would have been great. Though it would definitely be after they manually developed the algorithms as I am not sure how much would be learned solely loading a data frame and calling the describe function. Throughout the week I tried to demonstrate how they could optimise their code but a dedicated time-slot may have been better.

Concluding Remarks

Overall, I and others in the company believe it was a massive success. I’m dwelling more on the flaws here as if we end up running it again I would like there to be no flaws and it to go completely smoothly (one can dream). And you learn more from your failures than your successes.

As for me, I thoroughly enjoyed doing this and it is a great feeling to be able to teach people about portfolios and get them kick-started with a first one. A potential benefit of designing this course is that it could be a good start to training University-level interns (potentially even new employees regardless of ability level) how to use our codebase — take all those tasks designed for the simulated data and apply them to the far more complex real data in a real system.

It would be great to hear from other people who have run similar work experience schemes and what you have found worked and did not work. Feel free to reach out to me on here or on LinkedIn. Comments and criticism are welcome, especially on my writing.

Opinions expressed are solely my own and do not express the views or opinions of my employer.

--

--