Should I expect recent grads to be familiar with basic programming concepts?

Question

It seems there's a HUGE discrepancy between what I expect someone who's studied programming for a few years at university, and what one actually knows.

I don't feel like I'm asking overcomplicated questions in interviews. Some of my usual questions are :

• What's the difference between a reference type and a value type?

  If it seems the interviewee doesn't really understand his own answer, or if he doesn't know the terminology I'm using, I get into more details by asking him to explain me what happens when I write int i=0; in a method, what about object o=0, object o = new MyClass(), etc...

  Basically, I do everything I can to trick the interviewee into telling me about the callstack, the heap etc, and I try to stay into language-agnostics concepts. If the interviewee tells me he did a lot of C, or C++, or c#, I dive deeper into the specific language, and possibly into the implementation details.

  If needed, I ask the interviewee what a callstack is, or where arguments passed to a function in the imperative language of his choice are stored.

  most of the interviewees have just no idea about what a callstack is, let alone boxing considerations, etc.

• What's the difference between an abstract class and an interface. In which cases should you use one over the other ?

  Usually, I also ask them to imagine a design of a small library with a use case aiming at using some inheritance and some abstract factories

  Most of the interviewee have just no idea of what inheritance real purpose might be. They usually know some keywords (virtual, override, etc), but don't really know when to use them, let alone explaining what a virtual-table is.

Even-though I screen CVs beforehand, even for people with 5 years of experience in real life projects involving complex architectures, I would say less than 25% of all my interviewees can answer those two questions properly. And when I say properly, I don't mean 'in-depth'... just to have an approximate idea of what the concept is.

Regarding juniors, I'm fine with hiring someone who doesn't know how to organize his time very well, or someone who's not used to industrial build processes for example, but I have the feeling that if one hasn't heard the word "callstack" after a few years of studying Computer Science, he's either stupid, or unmotivated, or chose his university very unwisely.

Do you think I'm too extremist here ? Is it common to learn these basic concepts after you've completed university ? Do you know of people who weren't familiar with these, and became very good software engineers after a few years ? And do you think my company might have an issue in attracting talented people, or do you experience the same kind of issues with in your own hiring process?

---

Edit. regarding the "immediate type" thing, it was just a literal translation from French to English, as we usually do our interviews in French. I've fixed it in my question. But still, I think you all understand perfectly what I meant, which kind of makes my point, doesn't it?

Answer 1

Terminology is a common downfall in an interview situation.

You ask the interviewee a question using terminology that means something to you but the interviewee may know it by a different term, or may just know the generic theory without application to specific languages or environments. Misunderstandings ensue. Neither party is happy.

Actually it turns out the interviewee perfectly understands that some values might be stored directly in a register and others reference a chunk of memory elsewhere, but because you ask the question in a specific domain led way, the point of what you're asking, and what you want the interviewee to tell you about, doesn't really get across.

Maybe you get a lot of situations where the interviewee suddenly clicks and goes 'Oh - that's what you're talking about' - and then explains quite adequately.

It's a tough balance because programmers fresh out of university are not going to have the diverse experience that real world development in a team environment gives them. Meanwhile experienced developers are quite often not going to remember (or even be interested in) all the stuff they learnt at university because it's simply irrelevant for their day to day use.

These two types of people (yep - that's the interviewee and the interviewer) need to learn how to communicate with each other before you can learn about each other. The onus is on the person with the greater experience (the interviewer) to ensure this happens.

Not to mention the fact that some people get complete memory failure in interviews. Myself included. I remember being asked to write a program in C and I could not for the life of me remember the symbol used to access a member from a pointer (->) and had to ask someone. It wasn't even for my first job. Boy has that moment plagued me for the last 15 years :-)

Far more useful in my opinion is the ability to communicate, be able to solve problems efficiently and fully; pick things up quickly; show positive keen attitude; interact well with other people, and other core values.

Don't give up on interviewees because they don't know what an immediate type is. Move on.

Answer 2

You are asking for language-specific knowledge, and the terms you use are not used 100% the same in all languages. I - for one - have no idea what an "immediate type" is.

Also, consider that the things taught at a university is not how to crank out standard code in X, but to have learned a lot of underlying concepts and seen various programming paradigms. In other words, it is much like a drivers license - even though you know the basic theory, you still need a lot of actual practice.

Answer 3

You have quite a number of narrow views and you do assume them implicitly.

• It seems there's a HUGE discrepancy between what I expect someone who's studied programming for a few years at university, and what one actually knows.

  To my knowledge there's no university, where people study programming for a few years. Universities offer courses in computer science, whereof programming is one aspect.

• What's the difference between a reference type and a value type?

  Rule of thumb: If Lisp can do without the distinction, it's only clutter ;)

• Basically, I do everything I can to trick the interviewee into telling me about the callstack, the heap etc, and I try to stay into language-agnostics concepts.

  Talking about language-agnostic concepts is a good idea. Neither the heap nor the stack are language-agnostic though.

• If the interviewee tells me he did a lot of C, or C++, or C#, I dive deeper into the specific language, and possibly into the implementation details.

  All these languages have specifications. Implementation is undefined by the language. C and C++ can be cross-compiled using LLVM to run on the Flash Player or any JavaScript runtime. This makes your assumptions about heap and stack allocation void.
  With C#, it's much the same. C# is JITed before execution with a lot of optimization, that can be done. Local variables, that are captured by closures will ultimately wind up on the heap, instead of the stack, while escape analysis allows to store scope-local objects (that should normally go to the heap) to be stored in the stack. Proper register allocation will also greatly reduce the need for stack allocation.

• If needed, I ask the interviewee what a callstack is, or where arguments passed to a function in the imperative language of his choice are stored.

  What would you ask someone who's only extensive programming experience is with Haskell? :P

• Most of the interviewees have just no idea about what a callstack is, let alone boxing considerations, etc.

  The basic idea behind autoboxing is, that primitives can also be treated as objects (or at least values who's type can be discovered at runtime). In regard to that abstraction, there's three types of languages:

  1. those where it doesn't exist. I suppose Objective-C is the cannonical example.
  2. those where it truly holds
  3. those where it exists but doesn't hold. I guess Java is the best example (I'd assume it has been fixed by now).

  I don't see why people shouldn't be using languages of category 1 (actually it's a good idea). I don't see why people who use languages of category 2 should really bother. And I think everybody who uses a language of category 3, i.e. one where a core semantic feature is simply broken, is using the wrong language.

• What's the difference between an abstract class and an interface. In which cases should you use one over the other?

  Now that is highly subjective and really depends on the language. C++ doesn't have interfaces. Objective-C doesn't have abstract classes. I would argue that any language that has both is in grave need of redesign. Many modern languages use traits, mixins, categories, roles and similar constructs to provide far cleaner solutions for code reuse than inheritance of partial implementations. Prototype based languages don't have classes altogether anyway.

  Ultimately this is a difficult and contested subject. An interview is hardly the right place to solve this question and I wouldn't really nail anyone applying for a junior position on not giving me a good answer.

• Most of the interviewee have just no idea of what inheritance real purpose might be. They usually know some keywords (virtual, override, etc), but don't really know when to use them, let alone explaining what a virtual-table is.

  There's a number of object oriented languages, that don't use inheritance or classic vtables.

My advise:

• Be very careful to assume that anything you know about programming is really a basic programming concept. You can assume that every good programmer has the curiosity to find out the answers to such question. However you cannot assume that anyone who knows them is good. I tend towards believing that those giving too much importance to such details are actually likely not to see the forest for the trees.
• Worry less about implementation details. Programming languages are meant to create abstractions. You need to think in terms of those abstractions and in terms of them only. Good code is not written against implementation details of a language. It is written to best embed the semantics of your solution into the language features. If you succeed in doing that, your code will not only become robust, but well readable for anyone familiar with the language, and easier to optimize for a compiler.
• Knowing the answers you expect is not so important. Understanding them is. If somebody just knew them, because they read them in a text book or his professor told them, then it's of little value. Actually you can explain all those things to yourself with a matter of hours.
  What is important is you understanding of how these simple and isolated facts can be applied to engineering flexible and maintainable solutions to complex problems.

To get to the real question:

And do you think my company might have an issue in attracting talented people, or do you experience the same kind of issues with in your own hiring process?

All companies have issues attracting skillful people, except maybe the big players. That's because there's few of them. And because of the assumption, that university renders people skillful. It doesn't. It renders them knowledgeable (supposing both the student and the university hold up to their part of the bargain). Experience is what makes people skillful.

There are a few who have collected experience prior to entering university and who carry on doing so during their studies. Because they like programming and because when they pick up some new idea during a course, they will try to see how they can put it to use, the first thing they get back home. This is the kind of people you would love to hire. But there's few of them.
It is the passion for programming and self-improvement and its pursuit that make programmers good. In time.

I think, what you must realize is, that sadly most people will enter and leave university without sufficient programming experience.
At the same time, our industry is in bad need of experienced programmers. Therefore, I believe it's our industry's mission to actually try to step in. And interviewing candidates for junior positions, what you're realistically looking for is people willing to learn and to improve. And you should choose carefully, because you will need to invest a lot of energy and you don't want that to go to waste.

Think of it as hiring a fresh blood to become a driver for your racing team: A good driver has a sufficient understanding of mechanics to make best use of his car, but this knowledge alone is of no use (it's not even much of a head start). What you're looking for is someone willing to work hard on their own improvement and well with your team.

Answer 4

"I hear and I forget. I see and I remember. I do and I understand." (And, in my opinion, understanding leads to better memory retention.)

Simply put, a recent graduate doesn't have much experience, so as someone else noted, they're not going to have much more than the bare minimum of knowledge, no matter what their "chosen" language is.

I went to a college that was designed specifically to streamline learning about one's chosen major (so, for example, you wouldn't have Historical Literature if you were a CS major; the closest you might get to Historical Literature is Science Fiction), and straight out of college, I wouldn't have been able to tell you what an interface was let alone its difference to an abstract class, though we did learn about abstraction (and interfaces abound in .Net, the technology I learned). We might have touched on interfaces, but it got lost in all the other stuff we needed to know to pass the class. It wasn't until my first job out of college that I learned about interfaces, particularly in any meaningful way.

You mentioned doing interviews in French, which makes it obvious we're in different countries, so your mileage may vary, but here in the US, colleges are notoriously behind the times when it comes to technology. Therefore, unless you're dealing with the mature languages (C/C++, COBOL, etc), it's also quite likely that what you've been using even for years may not be available in the version the students have learned on. For example, .Net 3.0 introduced Entity Framework, WPF, WCF, and a host of other cool things, but even my school was still stuck on .Net 1.1 and 2.0 (which meant being stuck with ADO.NET and not even learning about Object-Relational Mapping). A school that uses PHP may be stuck on (non-OOP) PHP 4.

Keep in mind, too, that a student has to take in a ton of information that is often only used for a short amount of time. "Advanced" concepts, like abstraction, are often taught toward the end of the class, where the student may only have a week or so to play with it, while contending with the other classes s/he has to take, and possibly, on top of a part-time or full-time job. Combine all those together and it's a wonder the person can remember anything, much less keep it all straight.

In the US, at least, a recent grad is often assumed to know nothing beyond the generic basics (the difference between passing by value and passing by reference, maybe), because it's understood that generic theory and problem-solving is the main part of school, not learning the ins and outs of a given language.

I recommend using the questions you've had more as a gauge of what you'll need to teach/re-teach them (remember, it's entirely possible they just didn't learn the term that you're trying to use, even if you think it's ubiquitous), as opposed to whether or not the interviewee is "worthless." Combine that with gauging how willing they are to learn and what their general problem-solving skills are like (seriously, give them a riddle to solve and see how they go about doing so), and you can very well have a future rockstar that you may have passed up because they didn't know what you meant by "callstack."

Answer 5

 or chose his university very unwisely.

That's very unfair. When you're a student, all you can do is pick the highest ranked university your grades will get you into, or maybe that one that advertises letting you play with football-playing robotic dogs. Nothing more. You can only evaluate a university course after having done it, then gone away and worked in industry for a few years and built some non-trivial projects.

Even if you flashed up a huge neon sign on every such course saying "WE DON'T TEACH THE CALL STACK", then what are you expecting the students to do about it? Spend months researching it so that they can actually understand what that means and how much they'd need one that does teach it? For every course with every combination of signs?

People don't get to choose their education, realistically.

Answer 6

Regardless of the "immediate type" term of which I don't have a clue (value type? OK, I wasn't sure, thanks for updating), I think you're right about your questions and totally not extremist. These are answerable questions if one is coming right out of school. Still, I will not dismiss the candidates immediately, there are still some that may have potential because they want to learn.

To continue with the driver license analogy: some people don't care what happens when they insert the key (or push the "start" button). They just do it and drive. This does not mean they are worthless either, just that it will take time for them to reach stardom ;-)

Just a personal remark on the degree/diploma: I am currently working with people with biochemistry and industrial background that have a few years of experience in the IT field and also some "experienced" guys with CS background, and guess who are the most knowledgeable on how the vehicle engine works? Yup, it's not the guys who have studied CS ! So I'm just experiencing the fact that the diploma does not always matter!

Answer 7

I generally don't ask specific questions about terminology or definitions during interviews. As other answers have noted, people have different terms for different concepts and while they may conceptually understand the subject, they may not be able to convey that to you.

With Juniors I am intensely focused on their internships or school projects. I ask questions upon questions about them, let them articulate answers and then I start diving deeper into their actual inolvement in the project, what they learned, what they felt.

Generally if the person was deadweight in the project then they can't generally give satisfying answers to me, so it is usually pretty easy to tell. Just be careful not to mistake nervous and introverted for disinterested and uninvolved.

Being able to determine the good candidate who is shy and introverted is a little hard, but then the culture where I work wouldn't be good for an introverted and shy developer so if they can't hold a productive detailed conversation with me then they are not a good fit.

Answer 8

As a Director who designed the interview process I can fill you in on what our company expects out of new grads: I expect people who can read documentation and apply knowledge. Thus, we have a few very hands on tasks that we ask them to perform. These are simple coding tasks, not much harder than your average college class exercise (experienced "good" developers can knock it out in about 15 minutes). The candidate is given a workstation with internet access, a compiler (in our case visual studio), and help files.

If they can't write code under these conditions, they don't get consideration for hire. Simple as that. The whole "well I don't know the language" excuse never really jived with me because every candidate who comes to interview here knows there will be a test, they know the languages and tools we use up front. You can download visual studio express at home and do some basics before coming in and pass the entry level test, those who don't bother... well that's what I call a red flag.

Answer 9

When interviewing new graduates I stick to the topics listed on their CV. If they used Java, I will ask them about Java. If they used Blub, then I spend half an hour reading about Blub, and ask them about that. But I always ask using the language keywords. If it's Java, then I will ask about "extends" and "implements" but not "subclass" and "inherits". I expect new graduates to be able to talk about some code they have written, to be able to solve a simple programming problem, and to have a grasp of the basic data structures (hash tables and trees).