Finding a Research Job, and Teaching CS in High School

http://bit.ly/1p2ep9F
July 15, 2014

The last several years have seen phenomenal growth in machine learning, such that this earlier post from 2007 (http://bit.ly/1o7lY1f) is understated. Machine learning jobs are growing everywhere. The core dynamic is a digitizing world, which makes people who know how to use data effectively a very hot commodity. Anyone reasonably familiar with machine learning tools and a master’s level of education can get a good job at many companies, while Ph.D. students coming out sometimes have bidding wars and many professors have created startups.

Despite this, hiring in good research positions can be challenging. A good research position is one where you can:

• Spend the majority of your time working on research questions that interest you.
• Work with other like-minded people.
• For several years.

I see these as critical. Research is hard enough that you cannot expect to succeed without devoting the majority of your time. You cannot hope to succeed without personal interest. Other like-minded people are typically necessary in finding the solutions of the hardest problems. Typically you must work for several years before seeing significant success. There are exceptions to everything, but these criteria are the working norm of successful research I see.

The set of good research positions is expanding, but at a much slower pace than applied scientist types of positions. This makes sense, as the pool of people able to do interesting research grows slowly, and anyone funding this should think hard before making the necessary expensive commitment for success.

What makes a good candidate for a research position? People have many diverse preferences, so I can only speak for myself with any authority. There are several things I do and do not look for:

1. Something new. Any good candidate should have something worth teaching. For a Ph.D. candidate, the subject of your research is deeply dependent on your advisor. It is not necessary that you do something different from your advisor’s research direction, but it is necessary that you own (and can speak authoritatively about) a significant advance.
2. Something other than papers. It is quite possible to persist indefinitely in academia while only writing papers, but it does not show a real interest in what you are doing beyond survival. Why are you doing it? What is the purpose? Some people code. Some people solve particular applications. There are other things as well, but these make the difference.
3. A difficult long-term goal. A goal suggests interest, but more importantly it makes research accumulate. Some people do research without a goal, solving whatever problems happen to pass by that they can solve. Very smart people can do well in research careers with a random walk amongst research problems, but people with a goal can have their research accumulate in a much stronger fashion. I am not an extremist here—solving off-goal problems is fine and desirable, but having a long-term goal makes a long-term difference.
4. A portfolio of coauthors. This shows you are able to and interested in working with other people, as is often necessary for success. This can be particularly difficult for Ph.D. candidates whose advisors expect them to work exclusively with (or for) them. Summer internships are both a strong tradition and a great opportunity here.
5. I rarely trust recommendations because I find them difficult to interpret.

When the candidate selects the writers, the most interesting bit is who the writers are. Letters default positive, but the degree of default varies from writer to writer. Occasionally, a recommendation says something surprising, but do you trust the recommender’s judgment? In some cases yes, but in many cases you do not know the writer.

Meeting the above criteria within the context of a Ph.D. is extraordinarily difficult. The good news is that you can "fail" with a job that is better in just about every way.

Any time criteria are discussed, it is worth asking: should you optimize for them? In another context, lines of code (http://bit.ly/1sny5sc) is a terrible metric to optimize when judging programmer productivity. Here, I believe optimizing for (1), (2), (3), and (4) are all beneficial and worthwhile for Ph.D. students.

Back to Top

Mark Guzdial What It Takes to be a Successful High School Computer Science Teacher

http://bit.ly/UNV9Dx
May 14, 2014

Around the world, education systems are moving computing into primary and secondary schools. Whole nations (such as England and Denmark) and individual U.S. states are trying to figure out how to teach computing to students in K–12 (http://bit.ly/1pU93wh). A recent Economist editorial (http://econ.st/1snyye4) highlights the biggest challenge to getting computing into schools: How do we get enough well-prepared computer science teachers?

The first part of answering that question is: "Who are we starting with?" In Israel, the Technion is preparing high school computer science teachers from graduates with degrees in STEM (http://bit.ly/1qNf67z). The Computing at School effort in England is working to prepare existing Information and Communications Technologies (ICT) teachers to teach computer science (http://bit.ly/1o7quwM). Here in the U.S., we are mostly preparing business teachers to teach computer science (http://bit.ly/1oC5puh), because computer science is classified as Career and Technical Education (CATE) in most states (http://bit.ly/1pznE2F), and CATE teachers have business teaching certifications.

A related question is: "What do we need to prepare the teachers to do?" Sure, teachers who have an undergraduate degree have the content knowledge. ICT teachers may know something about computing, but may not know CS. Existing teachers know a lot about running classes, but may not have the CS background. The best possible world is to have teachers who know CS content, teaching practices, and how to teach CS, but the reality is that we will have to prioritize. What does it take to be a successful high school computer science teacher?

When we were working on teacher professional development in the early days of our "Georgia Computes!" project (http://bit.ly/1mg860a), our external evaluator interviewed high school teachers of Advanced Placement Computer Science classes. He grouped the teachers in terms of more-successful teachers (able to recruit more students into the AP CS course, had a high pass rate of students on the AP CS exam, were confident and satisfied with being an AP CS teacher) and less-successful teachers. The interviews give us some insight into what we want high school CS teachers to be able to do.

The quotes below were in response to a question about how the teacher prepared students for the AP CS exam.

Everything in that class is more or less an assessment. They are supposed to read certain sections in the book, and then they have quizzes over the reading. After they do the reading assignments, they have Gridworld case study quizzes and also Gridworld case study segments of code that they will go in and manipulate to change to get the things in the Gridworld case study to react different ways. Those are pretty much graded as labs or programs or quizzes.

The teacher in the above quote is describing is what you would expect any high school teacher to do when teaching pretty much anything. There is a heavy emphasis on assessment and reading. This is one of our less-successful teachers.

If I read these [student quizzes], I can see any misconceptions or gaps in what I have done. I get a picture in my mind of where the current class is. Making them do the explaining is new this year. I am seeing them do a lot better there. I will do little code (assignments) that they will write once a week. They have to write it by hand away from the computer, and I will read that and write comments on what they are doing and help them grade it with a rubric, and also pass them back after I have read them for them to grade, too, and have them look at what was catching it or where it did not quite get to it.

This is a response from a more-successful teacher. We see a lot of CS-specific teaching techniques: students explaining their code, writing code by hand away from the computer (as well as at the computer), and self-grading of code by rubric.

Particularly interesting to me is what the teacher is doing in each of these quotes. The first teacher makes assignments. The second teacher talks about creating assignments and rubrics, but she also reads student quizzes, and reads and comments on student code. None of our successful teachers ever talked about writing programs.

That is a big difference from what we teach CS majors. The latest ACM/IEEE computer science curriculum standards (http://bit.ly/1omiR0K) highlight that we expect graduates to be professional software developers who use good engineering practices. A teacher with software development knowledge and skills certainly would know how to read and comment on student code, but that is a small part of what we teach people to do as software developers.

Studies like these give me hope we can provide professional learning opportunities to existing teachers without trying to turn them into software developers. We mostly need to teach CS teachers to read code. Raymond Lister (http://bit.ly/1pznSa4) has done a lot of research exploring the developmental path from being able to read and trace code into being able to write code, and his results suggest reading and tracing precedes code-writing skills. It should be easier to teach reading than to teach software development.

Can we teach teachers to read and comment on code without teaching them to be software developers? Can we teach reading code more efficiently to a broad range of teachers than we could teach software development skills to those same teachers? These are important questions to answer to be able to prepare enough high school computer science teachers worldwide.

Back to Top