Home > careers, teaching > Preparing CS students for programming interviews from day one

Preparing CS students for programming interviews from day one

Computer Science is an odd discipline when it comes to job interviews for software developers. Specifically, all interviewees are expected to write code on the whiteboard, irrespective of their background and experience. Let’s assume that I get to interview for a job at Google (which will be a very real possibility if I fail to get tenure). Like a fresh college grad, I will be asked to write code on the whiteboard. The fact that I have close to 15 years of combined industrial and academic experience as well as more than 40 peer reviewed, technical publications will not make any difference. I will have to ask questions like: “How would you remove a node from a doubly linked list?” “How can you find all the neighboring links using a heap?” The fact that I have been teaching these skills to undergraduates for more than five years will be ignored completely. Purportedly, some academics who have not written much code in a while claim to hesitate even applying for a job with Google for that reason.

If we are to use a medical analogy, imagine interviewing an experienced (10-15 years on the job) surgeon for a position in a hospital.  Can you imagine asking the surgeon: “What is a scalpel? What kind of scalpels are there?”
“Now, cut this cadaver as if you were to perform an appendectomy. Good. Now imagine that there were some complications–show how you’d cut in that case.” I hope you are having a good laugh, because such a situation is unimaginable.

Nevertheless, this is the way all candidates for software development jobs are interviewed. As an academic, I cannot really change how the computing industry conducts interviews. However, what I can do as a professor is to prepare my students for the realities of a typical programming interview that consists primarily of writing code on the whiteboard. To that end, I am trying something different in my introductory CS class, in which we are talking about software design and data structures.

I have decided to start introducing more and more of the fundamental CS concepts from the position of a programming job interview. To that end, I stopped using PowerPoint slides. Instead, I quickly explain a new concept on the whiteboard and then immediately pose a programming puzzle using this concept to the class. I ask students to work on the problem for 5-10 minutes and then I ask for volunteers to present their solution by writing it on the whiteboard. Then I discuss and correct the presented solutions from the perspective of a potential interviewer.

Last class, we talked about lists implemented as arrays. After I explained the basic operations supported by java.util.ArrayList, I posed the following challenge to the class:

Assume that you have raw data containing the results of a Web-based survey. This survey asked programmers to specify their primary programming language and the years of experience they have in that language. The data is organized into records as follows: {“Java”, 2}, {“C”, 5}, {“C++”, 10}, {“Java”, 4}, {“Ruby”, 1}, {“PHP”, 7}, {“Java”, 4}, {“Cobol”, 20}, {“Python”, 1}. Write a Java class to represent such a record and implement its equals method. Assume that no getter methods are provided. Write a method that prints all the indexes of the records that have “Java” as the language.

As it turns out, implementing the equals method correctly has several caveats. The ability to implement this methods correctly immediately identifies a certain level of proficiency in Java. Then I went over many of the caveats by correcting a proposed solution. Printing the indexes of Java records using the equals method did not prove very difficult.

Then I imposed an additional constraint on the problem: you are not allowed to use method equals directly; you can use only indexOf and subList methods. These constraints complicate the problem significantly, making it very hard to determine how indexes should be incremented to move through the array. I had a hard time trying to find volunteers to present their solutions. And then I explained why this problem was so hard and how my students should go about solving such problems on the whiteboard.

Will I teach all the remaining technical material in the course using this method? Of course not–it would be counterproductive for the educational goals I set out for my course. Nevertheless, I intend to make this “writing code on the whiteboard” component an integral part of my teaching, as I want my students to get used to what will be a reality of their entire professional careers, as long as they want to continue developing software for a living.

Advertisements
Categories: careers, teaching
  1. burrowscode
    February 21, 2011 at 1:23 pm

    Do you really think the issue with potential software developers at an interview is that they get thrown off by the whiteboard? As I personally don’t see how the medium effects how well you are able to convey programmatic information (unless you expect the whiteboard to emulate Eclipse).

    As any introductory algorithms or data structures class should adequately prepare you for 99 percent of entry level programming position interviews.

    Poor performance in interviews seems to really be a result of poor information retention and not enough working through stuff on your own time.

    • joh6nn
      February 21, 2011 at 6:18 pm

      i think you’ve missed the point here. the issue is not the whiteboard, it’s the manner in which the material is being taught. the former is a lecture, the latter is a time-limited problem solving exercise. interviews are frequently attempts to get a look at your problem solving abilities, in a short period of time, so his new method of teaching the material more closely matches how the students will be expected to demonstrate their proficiency with it. that’s the important bit, not the whiteboard.

      regardless, i’m inclined to agree with you: if students don’t know the material, no amount of problem-solving practice is going to help.

      • burrowscode
        February 21, 2011 at 7:27 pm

        I don’t think I’ve missed the point at all.
        I’m simply saying that changing you’re teaching style to a platform that is more similar to programming interviews isn’t going to change which students do well and which don’t in interviews.

      • February 21, 2011 at 9:34 pm

        Whiteboarding–and the communication style it entails–is a skill unto itself. I recently went through the interview gamut, and I significantly improved in my interviews from beginning to end, even though my computer science knowledge did not increase correspondingly.

        I think this is a smart move, since the traditional lecture-style is incredibly boring (and hence somewhat useful), and introducing a whiteboarding/socrating style doesn’t change the fundamentals being taught.

    • February 21, 2011 at 9:53 pm

      As a former professional musician, I have internalized the value of practice making it perfect. If you take two students possessing identical CS competency and train one of them to answer programming questions on the whiteboard, that student will have an advantage. Thus, the medium does matter, even though there is no substitute for solid knowledge and understanding.

    • Oscar Boozer
      December 3, 2014 at 7:21 am

      “burrowscode” I disagree with you, the whiteboard or a simple paper approach is just not natural to anyone who has worked only in the IDE and will certainly throw them off. Note that here I’m not talking about design discussions or any other kind of brainstorming and collaboration, I’m talking about pure coding out the solution, including even the pseudo coding. You may say that IDE spoils the programmer with intellisense and other stuff of that nature, but is that a bad thing?
      I mean you are looking for a productive developers who knows how to work with the tools and I really don’t see it as a bad thing if a developer is too dependent on the tool.

      Also I agree with both “adambossy” and “etilevich”, the whiteboard is a separate skill from the coding skill and it requires some practice. The good thing is that I found it does not require much practice. You just need to try out few times to get a hang of it, for example I used some of the coding tests found on a:
      http://testdome.com/
      I would print them out and try to solve them on a piece of paper and these kind of exercises increased my whiteboard skills exponentially, it also showed me how much I took for granted without even realizing it.

      In conclusion I think that introducing a whiteboard in a classroom is really a wise decision.

  2. Mike Fulk
    February 21, 2011 at 6:04 pm

    This is your best post yet. I think the only missing angle is that of the programmer arrogance. Not, the programmer arrogance of the interviewee, but of the interviewer. There is this belief when you are in the position of authority that if you were being interviewed, you would not be nervous. That you would know exactly the correct answer. And, that you as a professional programmer can retain perfectly all information that you’ve encountered in your career – even if that career has spanned decades. Finally, you see everyone else you interview as an idiot because of this worldview.

    It is comforting to consider yourself an elite programmer I suppose. The best people I’ve worked with, however, consider themselves to be perpetual students.

    That surgeon interview analogy is spot on.

    • February 21, 2011 at 9:42 pm

      Mike,
      Thank you for your kind words and for sharing your observations from the real-world perspective. In light of what you are saying, it makes even more sense to start preparing CS students for programming interviews as early as possible. This way, they’ll be ready for any interviewer!

      I am surprised that so many people took issue with my surgeon interview analogy, and I am delighted that you found it accurate.

  3. Jacques Chester
    February 21, 2011 at 6:29 pm

    The Socratic Method rides again!

  4. February 21, 2011 at 7:25 pm

    Eli, I have taught entire introductory courses (fall, no experience required) in this fashion for nearly 20 years now. It is easily possible to cover the entire curriculum in this manner. What you need to do so is write the code for them on the bb/wb on some occasions. Also, consider asking people to work in changing pairs when you pose the problem to people; rotate the classroom.

    — Matthias

    • February 21, 2011 at 9:25 pm

      Matthias, it is great to know that you have been using this method successfully for so long!

      I am still trying to figure out whether it is possible to cover the entire curriculum in this manner. We cover a lot of heterogeneous content in this course, including some theoretical, non-programming topics. Also, we do use pair programming heavily in our labs. For solving problems in class, I usually encourage students to work in pairs but do not insist if someone prefers to work solo.

  5. February 21, 2011 at 9:19 pm
  6. February 21, 2011 at 11:15 pm

    I started requiring pair programming in 1997 at Rice. Nobody should be able to opt out. Getting along is a part of the interview process.

    As for heterogeneous content and Socratic teaching, take a look at the 4th edition of the Little Schemer, born Little Lisper.

  7. Chris D
    February 24, 2011 at 11:16 pm

    I’ve been doing industry software in the Bay Area for 12 years, and I think it’s great that you’re teaching students how to do whiteboard coding.

    I think the surgeon metaphor is misapplied: the primary difference I see is that surgery has objective measurements and oversight. You *know* when surgery goes wrong. You can call and find out a surgeon’s record: if 30% of their patients have died, you’ll know (and in fact, it’s unlikely they’d accumulate that kind of record on routine surgeries and still be allowed to practice).

    By contrast, as Seymour Cray supposedly said, “The trouble with programmers is that you can never tell what a programmer is doing until it’s too late.” The interview is our only chance to assess someone’s ability. References are worthless, because they’re always positive. There are vast numbers of incompetent people who nonetheless can bodge together low-quality-but-mostly-working software. Those incompetent people can always find other incompetent people to say they did a great job and they’re very effective programmers. Managers in particular are usually unable to assess a programmer’s skill.

    PhDs are often *terrible* programmers. And sometimes bad teachers: I’m about to start getting my MSCS because a friend is taking the intro CS course at a local community college, and the professor is so shockingly awful, and I want to teach part-time so I can save people from teachers like him.

    Long story short:
    1) Most programmers are idiots.
    2) It’s difficult to impossible to tell a good programmer from a bad one without making them write code.
    3) No amount of academic experience makes you a good programmer.
    4) Working with a bad programmer is a really, really, horrible, awful experience.

    Yes, making people write code in interviews is very strange. We work in a very strange profession. Whiteboard coding is 100% critical to the interview process. You might do a search for “FizzBuzz” to get a clearer sense of why. =)

  8. Neo
    November 3, 2012 at 5:43 am

    Good article, and you’re a hundred percent on point. The medium, the circumstances and your own nerves can and do make a significant difference. Anyone who can’t see that, does not understand the human mind.

    Also, the person who made a mention of the arrogance one encounters in interviews is also a hundred percent on point. If you doubt it, you can see it on full display here with such colorful descriptions of others as “idiots” and “incompetents”. Not only that, some of these same people apparently feel as if they are a community college’s next Messiah. Nice.

  1. February 21, 2011 at 12:52 pm
  2. February 21, 2011 at 12:59 pm
  3. February 21, 2011 at 4:34 pm
  4. February 26, 2011 at 8:35 am
  5. February 27, 2011 at 8:53 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: