I was reading a blog post by a college professor the other day (Preparing CS students for programming interviews from day one) that starts off talking about how interviews for programming jobs are run. Typically one is asked to write some code on a white board to do something like add or remove items from a linked list. Or perhaps use heaps or some other data structure. Actually this is pretty basic stuff and many students get this in high school during APCS if not before. So one is tempted to ask why would you ask such simple stuff in an interview for a high paying job? I?m not sure of all the reasons as it has been a while since I interviewed for (or to hire someone for) one of these jobs. But I hear that a lot of people looking for development jobs have trouble with these problems. That is scary and so I can see how one would be tempted to use them in an early round.
Now honestly linked lists are not something I saw a lot of during much of my software development career. Well not while I was writing normal applications. When I was doing operating system work the words FLINK (forward link) and BLINK (backward link) were very much part of my daily vocabulary. Stacks and trees were also regular places to explore and not always in higher level languages. But I am not completely sure how many people write these from scratch anymore when there are library objects with easy to use methods to deal with data structures. But all that aside walking through a data structure is a good way to see how someone thinks, how they visualize things, and perhaps more importantly how they explain things to others. Explaining things is a key task in software development these days.
The professor in the article above goes on to explain how he is teaching some concepts in an interview like format. Not for everything but for some things. It is an interesting idea but a little time consuming I think. Besides helping students to learn, which it seems to do, it is also helping students learn to express the concepts and code to others. That is a good idea. I have opined several times on the value of reading code but perhaps we also need to think about having students explain code more often. Some of that can be done in a code review. I suspect that doing pair programming involves a lot more on going explanation as well. All good things to try in the classroom.
During my career I learned a lot from code reviews and even just explaining my own code helped me understand what I was doing. What is that saying ?the unexamined life is not worth living?? Is the unexamined code worth writing?
No comments:
Post a Comment