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?

closed as primarily opinion-based by Ixrec, user40980, durron597, Kilian Foth, gnat Jun 24 '15 at 9:54

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 4
    Just a minor remark but I would not know what you mean with an immediate type, value type on the other hand I could explain to you. However I feel that everyone who graduated with any CS degree should be able to answer those two questions. To improve your question maybe you could give an example of how exhaustive the answers you expect should be. – sebastiangeiger Aug 1 '11 at 9:03
  • Studying a language for 2+ years at university, contesting with other subjects leaves students with only the bare minimum after their tests are over. The only thing you can be sure of is that they can learn that information, or they once knew it. Only practical experience can give them knowledge permanence. Joel Spolsky gives a great example of how and why students lack many abilities that we should expect programmers to have in his blog article here - http://www.joelonsoftware.com/items/2009/10/26.html – Justin Shield Aug 1 '11 at 9:40
  • @sebastiangeiger ; you're right updated! – Brann Aug 1 '11 at 10:01
  • 2
    He must knows that he knows almost nothing. This is the key point to get better over time. – deadalnix Aug 1 '11 at 10:41
  • Brann, interestingly, all people who answered this question mention the "immediate type" (translation error), and tell you they don't know what it is. Are your interviewers saying: "I haven't studied these matters in-depth?" or are they claiming to be experts on, for instance, runtime specifics and deep understanding of compilers? – Pindatjuh Aug 1 '11 at 19:31

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.

  • @Brann - immediate type -> value type. noted – Roger Attrill Aug 1 '11 at 10:19
  • Well, maybe it isn't clear enough from the wording of my question, but I really do a lot to make sure there's no terminology issue. I ask the interviewee what happens in specific situations in the language of his choice, I ask him if he knows what a callstack is, I ask him if there are different "kind" of memories, I ask him where arguments passed to a function are stored in the imperative language of his choice. Really, I don't feel it's a terminology issue. Sometimes, the interviewee has just NO IDEA about what happens behind the scene when a class is instantiated. – Brann Aug 1 '11 at 10:24
  • regarding the "move on" thing, that's what I usually do. But in my experience, when an interviewee doesn't know what a value type is, he doesn't know about thread synchronization either, nor about what generics are for, etc. So after a few questions, when it becomes clear the candidate isn't fit for the job, I usually give him some advice about what to learn to perform better in technical interviews and... move on with the next candidate:) – Brann Aug 1 '11 at 10:34

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.

  • I've updated to "value type". But the thing is that if the interviewee doesn't understand the question, I usually explain it in more details, and try many things to trick the interviewee into telling me about the callstack, the heap, etc... (yes, I KNOW those are implementation details, but still, those are general concepts that are not really language-specific IMO) – Brann Aug 1 '11 at 10:03
  • I think the "callstack" concept is one of those general concepts you're talking about. Even after re-wording the question in ten different ways to make sure the interviewee knows I'm expecting him to tell me about memory allocation, callstack, value types, etc, I still, more often than not, get blank stares ... – Brann Aug 1 '11 at 10:28
  • If I understand you correctly, you want to know if the developer knows pointers and know what they do and how to use them? – user1249 Aug 1 '11 at 10:33
  • No I don't. I want to make sure the developer has at least a rough idea on what happens behind the scene when he uses feature x or y of his language of choice. Asking him about pointers is just a way to make him talk about what he knows regarding memory allocation. – Brann Aug 1 '11 at 10:43
  • 3
    @Brann, all the detailed stuff about call stack, heap etc, is essentially just pointers applied. – user1249 Aug 1 '11 at 10:46

"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."

  • Well, in France (and I suspect it's the same in most places), every CS curriculum includes some mandatory coding in C (or similar languages) when one learns about memory allocation among other things), and some mandatory coding in C++/java/.net (where one learns about OOP). On top of this, you also do a lot of things that can cover a lot of fields, but if ones graduates without knowing what a virtual method is, it means he didn't take his studies very seriously... I certainly knew what it was when I graduated ... What would you think about a Math student who doesn't know what a series is? – Brann Aug 1 '11 at 14:19
  • @Brann - According to my (quick) research on what Computer Science is (as well as my previous understanding of it), CS isn't a programming major. Yes, it has programming in it, but it's not necessarily the main focus of it. For that matter, "Computer Science" is so broad and rather vague, that it can vary from school to school. Stanford is among the top CS schools in the US, and for its Fall and Winter course selection lists (www-cs.stanford.edu/courses), it has less than half a dozen courses that appear to focus on actual programming (not just program theory), out of about 50 classes. – Shauna Aug 1 '11 at 18:37
  • This means that a student is likely to use any given language for a semester or two, then not touch it for the rest of his student career. On top of that, he's also learning about robotics and genetic programming, which are vastly different from standard desktop/embedded systems/firmware programming. – Shauna Aug 1 '11 at 18:39
  • What would you think about a Math student who doesn't know what a series is? - That depends on what type of Math the student specialized in and what he's actually be working on. Again, it's entirely possible that the student has learned it (and therefore, technically does know what it is), but has simply forgotten it, because he never uses it in his everyday work with cryptography or discrete math. Math and programming are generally considered use-it-or-lose-it topics. – Shauna Aug 1 '11 at 18:42

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.


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!

  • 2
    Some people can spend so long tinkering with their vehicle to get it to top speed, that the slow ones have finished before they even get started. – user1249 Aug 1 '11 at 10:36
  • fair enough :-) – Jalayn Aug 1 '11 at 10:39
  • I totally agree regarding people coming from other fields than CS. but for someone who actually owns a CS degree, not knowing what a value type is seems a bit worrying to say the least ... – Brann Aug 1 '11 at 10:41
  • @brann, they may not know the term, but still be aware that the physical placement of the data held by the variable is placed in the data segment and not in the heap or the stack. Which language do you use as this appears to be important? – user1249 Aug 1 '11 at 10:47
  • I'm using c#. And I agree that knowing this kind of implementation details is probably not that important in that context (although in some specific situations, it might be). The thing is that I'm not trying to find a c# expert. I'm trying to find someone clever enough and motivated enough to become really good at coding in c#. If one didn't care to learn/understand what a value type, I tend (maybe wrongly) to think he misses one of thoses two qualities, at least – Brann Aug 1 '11 at 21:37

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.

 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.


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).


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.

  • This is the best way to find somebody who claims he knows something actually does know it well enough to use it. Asking what a term means, something that outside of a classroom, is hardly ever used is sort of pointless. I mean in the last 18 months I have not once had a discussion about reference types might have complained about something that involved pointers though. – Ramhound Oct 17 '11 at 12:39

Not the answer you're looking for? Browse other questions tagged or ask your own question.