The Next Big Thing

Over the weekend, I volunteered as a teaching assistant (TA) at an event for kids who wanted to learn how to code. The two day event was organized by The Next Big Thing, a non profit organization in Canada aimed at facilitating and encouraging youth entrepreneurship, with the first day focusing on basic HTML and CSS skills and the second day on Ruby (the days were lecture-follow-along style). I can’t think of a better way to get kids excited about entrepreneurship than by exposing them to the greatest enabler of them all – technology. It’s crazy to live in a world where a team of 50 or so individuals can produce a messaging product called WhatsApp that is so valuable that Facebook pays 19 billion dollars for it. Technology acts as an exponential multiplier and the sooner young people realize that and exploit it, the better.

The event was well attended and there were about 80-100 people on each day with about 500 or so on the waitlist for the two days. It was hosted at Vancouver’s one of Vancouver’s startups that made it big, Hootsuite, which helps companies manage their social media. I decided to help out at the event as a way of giving back some of the fun I’ve enjoyed while learning to code, and also because I was interested in seeing what the current state of affairs is in high schools in Canada.

Here are a couple of things I noticed this weekend:

1) The kids are getting younger

I mean seriously young. The event was advertised as being targeted at grade 10 to 12 students, about 16-18 year olds, and yet there were two or three 11 year olds each day at the event and lots more 12-15 year olds. A couple of kids had parents on hand to support them at the event, others just got on with it. And wow. They were following along just as well as the other, older students.

Do you ever get asked by older relatives how you use technology so easily and efficiently? My theory, backed up by what I saw this weekend, is that exposure is the key. The more you assimilate technology into your life, the easier to becomes to use it and apply it.

Kids these days are growing up with iPhones and tablets and what have you, so much so that there is little to no barrier to them learning how to code. They really just need to be pointed in the right direction and motivated. And that brings me to my next observation…

 

2) Kids know that there are educational resources out there and can use them

Day 1 started off pretty slow to ease people into the ideas behind HTML and CSS, and as always, there were a few kids who were ahead of the class and for which it was all old hat. And so they were going on CodeAcademy to find out more, playing around with those interactive examples and just getting on with getting on.

There were also kids where once they learned something, were quickly googling information to find out more and then going farther than what had been taught in class. Some of these kids had the foundations of the important life-long CS and entrepreneurial skill of being able to just “run with it”. And by that I mean they were able to learn a little bit of information, get pointed in the right direction, and then start learning a bit more and applying it in different ways. Kids these days no longer wait to be told what to do, they are resourceful.

 

3) Kids don’t ask for help

And a corollary of my last point about kids being resourceful, is that they don’t, and are generally unwilling, to ask for help. There were lots of TAs during the event and rather than hassling students every few minutes by asking them if everything was ok, were generally waiting to see a raised hand and then going over to help that person. Well, there weren’t many raised hands. Kids just wanted to google it themselves and try and figure out the problem, and failing that, just gave up.

And that was extremely interesting. I think letting kids try and solve problems on their own is the number one life skill that we should be trying to teach them (if it can be taught, perhaps just facilitated). And yet, there’s a fine line between leaving them to grow and learn on their own, and making sure they don’t just give up and quite altogether. I think the downside of being able to Google everything is that if you can’t find the information on the first page of Google after two or three searches, you give up. So there’s definitely a need, when teaching kids how to code, to be prepared to step in and challenge them and ask, is everything ok, followed by, can you show me your work?

 

4) Some kids just don’t care

There I said it. There were a couple of high school kids who were essentially falling asleep at the event. Not too many but still a couple. Some of the TAs engaged with them and asked them what their experience was and how they heard about the event, and their response was “my mum made me come” or some variation of that. And I think that’s pretty interesting too. Because on one hand you have this waiting list FILLED with tons of kids who want a shot at learning to code, so lots of pent up demand, and also some kids who just aren’t interested.

And I don’t blame that particularly sleepy kid, not at all. I think the fact his mother recognized that technology is an important part of our lives and that learning to code is quickly becoming a life skill is excellent, but we need to recognize that convincing parents alone that learning to code is a good idea is not enough – we still need to get the kids themselves to buy into it, especially while coding is not a part of the mainstream syllabus (i.e. we can’t force it on them – and arguably, a good teacher should be able to avoid this situation in any event).

In fact, what got me thinking about how the event could be improved in the future is by making sure everyone buys in to the point of the event in the first place. We started both days with descriptions of the technologies and syntax, and a humongous slide deck, whereas, what I think would really have helped, is to show the finished product first and then work backwards to build it. In other words, show what the point of it all is, get them excited, and then both of you are on the same page and working towards the same goal.

 

5) Kids do not have a long attention span

Each day of the event lasted 5+ hours including the lunch break. And that’s a long time. Short quick bursts with interspersed breaks are just better for learning. Enough said.

 

6) Rewind please

Kids respond to resources which they can access and engage with at will. There was often a cacophony of noise during the lecture, and that makes it hard for the kids to follow a long and is arguably not the best use of instructor time. Give the kids as much rope as possible to run with on their own, and help them out once they’ve identified stumbling blocks, i.e. take a flipped classroom approach. This is becoming really popular at contemporary universities in North America, and basically leaves the learning up the core, fundamental material up to the students, with the harder material and tricky applications being dealt with in class.

 

7) Kids need to learn how to code and think like a coder

The first day covered HTML and CSS, and was much better attended than the second day involving Ruby, and I suspect that’s because kids are put off by the idea of learning “hardcore” coding whereas HTML and CSS if you can even call that coding, is much more palatable.

There were lots of kids who were familiar with HTML and CSS but significantly fewer who knew what an if/else conditional structure was.

And so TAing the second, Ruby focused day was much more taxing than the first. And that’s a good thing. I got the feeling I was really helping kids learn how to think in a new way – how to approach problems in a systematic and logical way. It definitely takes a little getting used to before you’re cracking out the FizzBuzz exercise without a sweat.

So it’s kind of funny because the second day when we were teaching the fundamental ideas behind programming and coding, was really when we wanted a full house. HTML and CSS is mostly memorization and syntax and is easy enough to pick up on your own, but coding is something that we really want to be removing the barriers to entry to. There is just no exposure whatsoever to it in most schools.

I think there’s a strong need to emphasize in future events that you do not need to be a hardcore coder or even know anything about programming to attend events like these, and that such events should be focused on actual coding rather than syntactical and markup languages like HTML which students may have encountered before, e.g. in an IT or computer studies class.

 

In short,

the event was a great learning experience. I learned a lot about how to organize an educational coding event in the future – I’d definitely like to run one soon – what to do and not to do, and most importantly, that the current state of affairs in high school technology education is poor to say the least. We need to start addressing it head on by bringing coding and more so learning to code into the public eye. These articles about dropouts founding billion dollar tech companies, while inspiring from an entrepreneurial perspective, leave the “how” of they got there through coding as something ethereal and unknown. Coding isn’t any harder than math, and people/parents/kids/educators need to know it.

3 Things You Need to Know Before Applying for a Software Internship

1) Being an A+ student is not enough

Crazy, right? All your life you’ve been lectured on the importance of getting good grades so that you can get a good job and have a successful life. But it’s hard to read the news these days without coming across a story of some young college dropout founding a multi-billion dollar company, and that probably raises all sorts of questions in your mind – like is university and the debt associated with it worth it? Do I need to be a straight A student to be successful in life? Heck, do I even need to go to school at all?

Last year, Laszlo Bock – senior vice president of people operations at Google – when being interviewed about the importance of grades and GPA, said that there is “no correlation at all except for brand-new college grads, where there’s a slight correlation”.

So what’s going on? Well, computer science jobs are precisely about challenging the status quo. They are  highly biased towards problem solving ability – which means it is about applying fundamental concepts to solve novel problems – and they are highly meritocratic. There is a significantly smaller degree of subjectivity when measuring success and performance in jobs likes software engineering when compared to fields like consulting or accounting. In those fields, the easiest thing to do when measuring success is to place more emphasis on traditional traits and characteristics like years of experience, seniority and the name of the college you attended. With software engineering, you’ve either built a product that scales to handle 10,000 requests per second, or you haven’t. Simple as.

You want to get a job at Google? Well, show them that you have the skills to do the job (hint: getting an A+ is never listed on any of Google’s software engineering job specs). That brings me to my next point….

 

2) Build build build

Employers want to see evidence of your ability to create real world value. Most computer science classes are focused on theory and hypotheses and less on the practical. Unless you’re working on research, being able to produce real world software is a must for landing a software internship.

You don’t need to have built the next Facebook on your spare time, even just a slight modification on a tutorial based project shows passion and interest (of course, publishing something on an app store is even better).  Also, learning how to use industry tools like Git will also beef up your resume, even getting familiar with IDEs (e.g. Eclipse) used in your company of choice helps.

Show companies that you’re prepared to do more than the norm. The tools and tutorials available these days make getting a side project started a cinch and working on them shows companies that you love what you do, and that a career in CS is not going to just be a paycheck.

 

3) Know how to talk to people

This extends to both your cover letter and interview. Above all, you want to take the opportunity to convey your passion and interest in the company and its products.

I remember one internship I applied for a month or two ago where their main product was in computer networking. I got an interview and part of my own prep since I hadn’t done a networking class yet, was to blitz through a networking textbook so that I would be able to explain the basic theory of how their product works. Companies want to see that kind of determination and keenness. Working in CS doesn’t mean that you know everything there is to know about technology X, it just means that you are the kind of person who can seek out the necessary knowledge and apply it quickly and correctly.

And don’t just stop at the formal recruitment process when trying to engage with a company. There doesn’t need to be a limit to your interaction with a company. One of the questions that interviewers ask themselves when trying to find the right candidate for a job is, would I want to work with this person? The recruitment process should ideally be a dialogue between two interested and like-minded parties, not an interrogation.

As an example, a few companies I applied to didn’t have any information available online about their interview process but I’d gone to campus and recruitment events earlier on during the year and was able to capitalize on that information during the informal Q&A sessions after. Anything else I wanted to know I picked up by just searching for connections on LinkedIn. People in the tech world are generally extremely helpful. And when it comes to recruitment, everyone is always keen to help their company seek out new, talented engineers since they’re a rare commodity!