Monday, March 24, 2014

The ideal graduate

The School of Computing has a stakeholder panel, made up of representatives from companies and other organisations that we work with. Its job is to give the school strategic advice on its teaching, research, enterprise and public-facing activities in general. In a recent meeting we discussed what it is that panel members look for in the interns, placement year students and graduates that they recruit.

One of the distinguishing features of computer science at Kent is that about eighty percent of students - over 100 this year - take a year's industrial placement between their second and final years. It's therefore not a hollow promise to say that their degree overall is a single package, delivered jointly by the school and its industrial partners. We teach what it makes sense to learn in the classroom, while our partners are able to give students the experience that can only come from working on real projects for real customers.

So, what is it that this selection of our graduate employers look for?

  • First, it goes without saying that strong technical skills are required: in particular, our students need to be able to program. Not all CS graduates are competent programmers (!) - and many employers will test applicants' programming competence. Theory and maths were discussed too. But what other attributes do they need?
  • Curiosity and the drive to learn. It's clear that all our graduates will be working in a quickly changing environment, and so will have to keep up with new technologies and applications. When presented with a situation, the best graduates will ask "why?", and try to find out the answer. They will likely have an agenda of what it is they want to learn, and what skills they want to develop. As a school, we therefore need to make sure that we help our students to be independent learners, both individually and together in groups.
  • Approach. It's not enough to roll up your sleeves and start coding … nor is a system finished when it compiles without errors and passes a handful of tests. Those who are able to plan their work using pencil and paper before getting into the details of the work are likely to perform much better. Similarly, systems need to be unit tested, but also whole applications need to be exposed to potential users, and tested to destruction. This leads on to …
  • Empathy. Testing is just one aspect of this. There are end users who'll need to interact with what a developer does, and having some sense of their needs, and how they will use the system: listening skills, and understanding the context of work - what does drive this: money? user engagement? - isn't an optional extra. Others may well work with challenging groups, for example clients of social care, with a particular approach and needs. 
  • The flip-side of this is being able to tell a story, or have a "value proposition". We can all suffer from this - I certainly have colleagues who can write research applications that are all about a great solution, but the problem is it's not clear what problem it is solving, if anything. So, begin able to appreciate context, and explain an idea from a different point of view, is key.
  • More traditionally, I guess, are project skills: team working, appreciating the lifecycle - there's testing again, agile processes (our students, and students in general, seem to cling to waterfall models), and general infrastructure skills. A nice angle on testing was "what will be the impact of this software on the system when I integrate it, in terms of functionality, performance and scalability?" - it's not just a matter of meeting those few unit tests.
  • Many employers saw students come in wanting to be developers, while an employer will be looking for wider ambition, ultimately. Employers are also looking for diversity in their recruits, not just in terms of gender, but all dimensions of difference.
Looking at this list it's easy to see that some of these are skills which students will acquire through their placement year, or in the Kent IT Consultancy, but there's a clear challenge there for academic departments in how they develop students as independent learners, curious about the world in general and tech in particular. Experiencing failure - in a "safe" environment - would also really help, and immersion in a topic can really help: a one week intensive MSc project some years ago was one of the most positive teaching experiences I have had … that also reminds me of teaching Open University summer schools - a year's worth of university experience in a week!

1 comment:

  1. An interesting selection of points, which I mostly agree with (having been involved in quite a few interviews this year, for both grads and experienced hires).

    We look for all those points, but we would probably actually put your final two bullet points as very near the top. The technical skills are the base line, and we expect grads to have that (and most do, it's rarely a differentiating factor - those that don't, generally don't make it past either CV sifting, or first-round telephone interviews). What makes grads stand out, and we we look for beyond the technical skills, is "How well will this person fit into our team? How well will they fit into the company?" So we're looking for people that will work well in a team (conflict resolution, empathy, etc), that will have a flexibility of thinking. Most projects really are team work, there's no "star developers" despite the folklore and hero stories, there's always grunt work that needs to be shared - and we need people that understand that.

    Your point on "ambition" is also very important, and something we do look for very carefully. It's not a crime to have ambition, it's a benefit. It's much easier to manage someone who has some aspirations (which you can than help them to achieve within the company) rather than someone who has no real idea, and will end up getting bored, drifting through work, and then moving on.

    A thought provoking read though :-) Sounds like Kent is improving its preparation since I was there, anyway :-)

    ReplyDelete