Preparing CS students for programming interviews from day one
etilevich.wordpress.com
etilevich.wordpress.com
> I stopped using PowerPoint slides.
> immediately pose a programming puzzle using this concept to the class
> ask students to work on the problem for 5-10 minutes
> volunteers to present their solution by writing it on the whiteboard.
> discuss and correct the presented solutions from
> the perspective of a potential interviewer
It won't suit everyone, but ...
> Will I teach all the remaining technical material
> in the course using this method? Of course not.
- Students group up for 5-10min to work together, everyone sits there and waits for the one person who knows the solution to solve it
- Prof asks for a group to come up, no groups volunteer so he starts picking at random
- Students that don't know the answers will stop showing up for lecture or will cling to the people that do, so they don't learn the material
Like I said, there are cases when it can work -- and when it does it makes for a really good lecture. But I find it is increasing rare that students are willing to go up to the professor and in front of their classmates and work through their mistakes; you are very exposed and I think the fear of public failure can be overwhelming.
I found it in the bundle.
Anyone can write on their CV that they've got five years programming experience, unless you can demonstrate the skills you've learnt over those five years, then you might as well have spent those five years watching paint dry.
If you've spent the last five years teaching undergrads data structures, then I certainly expect you to be able to answer questions on data structures.
Medicine is a regulated profession so you don't need to ask these questions as someones already asked them and certified the individual.
What's often missed is the fact that software development interviews are an order of magnitude better than those in other non-certified professions. In many industries interviews often come down to the gut instinct of the interviewer, a practice which is known to be highly unreliable.
Programmers are lucky that we're in a profession where it is possible to separate the wheat from the chaff using objective questions.
The real equivalent for a surgeon would be to give him a theoretical case of a patient and then ask him to explain how he would solve it. I'm not a surgeon so I have no clue what their interviews are really like, but asking a question like this would seem like a very reasonable thing to do.
As for the guy in the article who whines about employers stubbornly wanting someone who has written code sometime recently, I'm not quite sure why he'd think otherwise. When you hire someone at a PhD's salary you generally don't expect to have to hold their hand for a few months as they get back into learning how to write code. Not to mention anyone I know who is good at writing code writes code for fun in their free time. Would you hire an artist who has a Fine Art degree but hasn't actually drawn anything for years? I think not.
CS goal could be greater than a factory producing employees for big corporations.
The new Gospel is lot better. "Build something useful" Start it on day one.
This is not likely to ever happen in a big way. Way too easy to show stuff that you built that you either didn't really understand or didn't really contribute to.
I've interviewed people with significant open source contributions who seemed almost incompetent in the interview. I almost suspect that they hired someone to do the checkins as I'd ask why they did X vs Y and it was like they didn't really know what X was, much less Y.
Google is driven by numbers, If they see enough people who are very informed and smart but actually they gamed the system just to get in Google but really do not do much, then companies will be forced to make major changes.
Every idea/process has an expiry time before everyone realizes and try to game the system.
The course he is teaching right now is a sophomore level data structures course. He's still teaching them the basics of computer science and programming. Walk before run and all that.
I don't think this analogy tells us anything (other than that's not how the medical field works). Why is this situation unimaginable? What exactly would be wrong with this approach?
I do a couple tech interviews a week and I regularly see people with very impressive resumes that can't code fizzbuzz. The job largely consists of writing software; I see no problem with requiring candidates to demonstrate that they can, in fact, write software. I don't want to work with people that think they're too good to demonstrate their skills.
Then move onto a different topic or skill. No one is good at everything or experienced in all fields. Plenty of candidates will do poorly on one question and then nail the next.
Not unimaginable at all. In a world where surgery was run like software "engineering" [1], we would interview surgeons this way.
Why don't we interview surgeons this way?
(a) Because surgical training is via apprenticeship. For any given surgeon, you can ask "which group of other surgeons taught you everything you know? Which ones signed sworn statements that you are minimally competent?" Then you can find those senior surgeons and ask them candid questions about the candidate. This is always possible. If a surgeon turns up without such references they don't get as far as an interview. ("I taught myself surgery from blog posts, and I practiced on my cats?" Eeeek. NO HIRE.)
(b) Thanks to the long history of medicine and its very serious life-and-death implications, surgery is a very thoroughly attested event with a very definite chain of responsibility. Look at a hospital's records for a given surgery, and you will get a complete list of everyone in the room. If the surgeon was the only surgeon in the room, you can be fairly confident that they handled the operation themselves. And though I'm not sure there's an actual law that forbids a surgeon from handing the scalpel to a nurse, or an intern, and having them do everything, that would (a) not be something they could do in secret; everyone in the room would know and (b) the surgeon-of-record would still be the responsible party: If something went wrong in surgery guess who would be sued?
What I'm saying is: It is hard to bluff being a surgeon. Which is not to say it doesn't happen: For various all-too-human reasons, doctors and nurses do cover for each other, and scandals occur. But it's not like software, where the level of bluff is really, really large. Software "engineers" are often self-taught by necessity, especially in the tasks they actually do all day; their work has no legally defined standards or practices; there are so many ways to solve a given problem that two engineers with the same job title and official responsibility may have completely different skillsets; they work largely inside their own heads where nobody can see what is going on; they can very easily copy others' work, or sit in the corner while the rest of the team does the heavy lifting and then claim full credit.
---
[1] For this post, I'm going to use these scare quotes to distinguish "software engineers" like myself from actual Professional Engineers, who are like surgeons and are not, in fact, asked to build little bridges out of Lego bricks during their job interviews.
I think it's a good thing. We still have regular programmers, and the word "engineer" actually means something.
Still, the level of competence is far from that of surgeons. It's possible to do a bachelor's with fairly little programming: at least where I studied, most courses include a large portion of teamwork, and I'm sure quite a few teammates passed their course thanks to me (or other people) doing all the work. When they graduate or enter internships, they just do the less technical work, like evaluating software packages, testing, or reading bids. I don't think you could find surgeons who can't operate like you can find engineers who have trouble with fizzbuzz.
Thanks for the confirmation.
Plus, it's always possible that you got your CS degree and aren't actually all that smart. I'm not a genius, but when I'd been programming for maybe a year, my ex-Googler friend asked me a Google interview question and said I did better than a PhD in CS that he'd recently interviewed.
So education and credentials don't always prove that you can solve problems or do everyday work in this field. Which is why I'm GLAD when an interviewer wants me to solve real problems in the interview. If I don't have to, chances are my coworkers didn't have to, either...
If my own background is anything to go by, CS is almost a textbook university subject: it presents a lot of theory and academic analysis, much of which certainly does underpin practical software development, but the emphasis is not on teaching specific applications, nor on teaching the supporting practical skills required to implement those applications. These things are experienced to some extent via examples that accompany the theory, and to a greater extent via reading around the subject and experimentation where the course has provided enough context to direct the student's personal study.
IMHO, one of the major differences between good and bad courses is that those that are taught well will also encourage the student to explore useful applications for what they are learning in this way, and thus to experience not only the practical implications of what they are learning but also the surrounding tools, processes and techniques that go with them in the real world.
Someone with a broad foundation in the theory and experience of varied practical applications should have no difficult adapting to other applications the same theory, nor to newer theories that have evolved through industrial R&D and not yet made it back into academia. Whether a recruitment process is any good at recognising this important ability to adapt and learn independently is an entirely different question, but any remotely useful process should be able to weed out the people who managed to spend 3-4 years studying theory without experimenting practically and reading around their subject, and avoiding hiring those is one of the most important basic goals of any software developer recruitment exercise IME.
My only concern is that for introductory courses, programming must be a "fun-only" affair -- let students explore, crash and burn the computer rather than worry about small details.
We also had a lecture this year involving role playing of a RISC-1 processor pipeline, felt stupid at the time, but don't think I'll ever forget the purpose of an out 1 internal register.
I call for a new structure to sit down and listen lectures.
Edit for clarity: I'm not sure interviews are the ideal test-case for programming performance and thus I'm not sure it makes sense to prepare students for that.
Along the same lines I wouldn't agree with professors preparing their students for the GRE because that has little real-world relevance.
Balls. The medical profession killed more people than it cured until some time between the 1930s and 1950s with the discovery of antibiotics. Walmart's supply chain management software alone has bdone more good than the entirety of the medical profession up to 19##.
This is what we call cherry-picking an example. Someone who wanted to argue with you might select Windows autorun and its role in the world of illicit botnets and keyboard logging.
Practically any commercial software package ever sold probably had a greater positive effect on the world than pre 19## medicine. This will hold more strongly for shrinkwrap software that stays around long enough for the company producing it to build a rep.
[1]Or total world utility/happiness, if we could measure that
Alas, a lot in modern medicine is not really much better than putting leeches, hence the articles "X is good for your health" and then two weeks later "or maybe not".
You can compare medics to a bunch of programmers which have to maintain billions copies of self-replicating and self-modifying program with billions year old legacy code. No source code is available, only obsfucated fragments without clear understanding which bits are significant and which just junk. Disassembly is hard, and no debug is possible, so the only way to figure out how the system works is try to modify a bit and look how the output changes.
Some defects manifest quite often and there are few bugfixes ready, but how they work and what side-effects they have is not always clear.
Systems are very fragile and must be treated very carefully in order to avoid fatal crash. Hence the "maturity" of the field — one has to be very careful when dealing with the staff not fully understood.
Most fields (including software engineering) are pretty good at solving problems that have previously been solved. Generally speaking civil engineers are pretty good at building bridges that stay up for example (with occasional exceptions of course!). Similarly, software engineers are pretty decent at building accounting systems etc.
When any field attempts to do something new, software engineering is pretty much as good as any other field. Even fields as mature as mechanical engineering make mistakes.
For example, the space shuttle Challenger disaster was caused by defective O-ring seals, and delusional engineering management who systematically ignored warnings.
Richard Feynman (who knew something about building systems at the edge of what was possible) said the following, when comparing the software engineering process with other processes inside NASA:
The software is checked very carefully in a bottom-up fashion. First, each new line of code is checked, then sections of code or modules with special functions are verified. The scope is increased step by step until the new changes are incorporated into a complete system and checked. This complete output is considered the final product, newly released. But completely independently there is an independent verification group, that takes an adversary attitude to the software development group, and tests and verifies the software as if it were a customer of the delivered product. There is additional verification in using the new programs in simulators, etc. A discovery of an error during verification testing is considered very serious, and its origin studied very carefully to avoid such mistakes in the future. Such unexpected errors have been found only about six times in all the programming and program changing (for new or altered payloads) that has been done. The principle that is followed is that all the verification is not an aspect of program safety, it is merely a test of that safety, in a non-catastrophic verification. Flight safety is to be judged solely on how well the programs do in the verification tests. A failure here generates considerable concern.
To summarize then, the computer software checking system and attitude is of the highest quality. There appears to be no process of gradually fooling oneself while degrading standards so characteristic of the Solid Rocket Booster or Space Shuttle Main Engine safety systems. To be sure, there have been recent suggestions by management to curtail such elaborate and expensive tests as being unnecessary at this late date in Shuttle history. This must be resisted for it does not appreciate the mutual subtle influences, and sources of error generated by even small changes of one part of a program on another. There are perpetual requests for changes as new payloads and new demands and modifications are suggested by the users. Changes are expensive because they require extensive testing. The proper way to save money is to curtail the number of requested changes, not the quality of testing for each.
http://history.nasa.gov/rogersrep/v2appf.htm
Edit, TL;DR: To summarize then, the computer software checking system and attitude is of the highest quality. There appears to be no process of gradually fooling oneself while degrading standards so characteristic of the Solid Rocket Booster or Space Shuttle Main Engine safety systems.