Think You Know C? Find Out

I’ve had the fortune or misfortune of interviewing a lot of job candidates over the years. It amazes me how often someone will claim to know something, sound reasonable, but then if you quiz them on it, it becomes really obvious that they don’t know much. To flush this out, we had a three-question test that would tell you a lot. People who got the right answer were ahead of the game, of course, but even looking at how people approached the answer (right or wrong) would tell you a lot, too.

I remember one case where the answer involved casting a value. A candidate had impressed me until faced with the question to which he said (more or less): “Well, there’s this function. I think it is called ‘cast’…” I think the look on my face told him that I actually knew the answer (not surprising, since I was giving the test) and that wasn’t it.

[Oleksandr Kaleniuk] has a C quiz of only five simple questions. They reminded me of at least one of my old company’s three-question quiz. I don’t want to say too much about the character of the test because I don’t want to give away the answers, but if you think you are a C wizard, go check it out. Then come back in the comments and tell us how you did. Just try to avoid posting spoilers (although you should probably avoid the comment section until you come back).

Maybe you can stage a game night at your next hackerspace meeting. There’s plenty of designs for quiz buttons. Some of them are even shocking.

134 thoughts on “Think You Know C? Find Out

  1. Saw that. I’m only a hobby level C programmer but most of my answers were ‘I don’t know’ as I didn’t know what CPU it was being compiled for, so I didn’t know what a lot of the sizeof() functions returned. But it’s a good set of edge cases.
    (I knew about the last one after wondering why there were the two styles and asking why one would use one over the other)

    1. Many engineering disciplines will have this: both beginners and experts might not know the answer, but the reason for that is vastly different. In between is the hellscape of engineering errors caused by overconfidence.

    2. Yep, seen some curly platforms in my time too … weirdest being a TI DSP that had a 16-bit char type (the TMS320LF2406A). int was 16-bits too if I remember rightly. So (sizeof(int) == sizeof(char)) && (sizeof(char) == 1) evaluates to true on that platform.

      I’m basically allergic to using int, unless it’s just a small loop counter and I really don’t care much, I’ll be using one of the stdint.h types.

    3. “It was a research project in nuclear power plant automation, where absolutely no underspecification was tolerable. ”

      HA! so wait, the compiler is guaranteed to be to spec! HA!

      okokok, the question was about C, not what a compiler thinks C is… i know i know..

  2. ha ha….
    1) i >=i …. will always evaluate to false (or 0 zero)
    2) shifting zero by 16 bits whether left or right will still be zero
    3) i <=i (see #!)
    return value: 0 zero (false)

    1. Not really:
      1) i >= i is always true, so 1 in C
      2) shifting 16 left will give you 65536
      3) right shifting an signed integer is implementation specific so either logic or arithmetic shift. In this case the value is positive so both so in either case the answer is 1
      4) 1 <= i is true, therefore the answer is 1

        1. It doesn’t matter what sizeof(int) is. You have (1 < 2). Then you rightshift by 16. That is either 1 (sizeof(int) > 2), 0 (sizeof(int) <= 2), or -1 (sizeof(int)=17 bits). All of those (1, 0, -1) are less than 16, so the final comparison is always true.

          1. Aw hell, the shift operators didn’t come through correctly. But the point is, the first inequality gives you 1. Shift that up 16 bits. That either overflows (giving zero), or doesn’t overflow (giving 0x10000). Then you shift back down 16 bits, which gives you 0 (if it overflowed), 1 (if it didn’t overflow), or -1 (on some weird 17-bit machine where 0x10000 is the maximum negative number). All three of those are less than 16.

          2. The article author’s point was that what happens if you “overshift” isn’t defined by standard – I take on his word that to be the case (but that said I can’t imagine anything other than issuing a warning or error, if it compiled any compiler would surely end up with the same zero result), but if indeed it is defined by standard, then yes you are right (and the article was poorly written and should have had the return == 1 instead to illustrate the more likely result of a poor type size assumption).

          1. nope, because overshift isn’t defined by the spec. There is no set value that you’ll get. You might end up with a 12-bit int, and that 0b1 gets barrel shifted around to 0x8. Or, 10-bit ints, barrel shifted around to 0x20, which is most certainly not less than 16. Then there is the possibility that overshifting returns a completely undefined value or some other definite (but unknown) value.

          2. Overshift might not be defined by the standard, but I would be absolutely flabbergasted if any sort of barrel shifting was allowed to occur with either left shift or right shift. Remember, even if the high-order bits of an integer are zero, they are still being shifted off the top of the word and cannot be recovered. The same is true for “one” bits being shifted off the top. Just because you can’t get the bits back doesn’t mean that shifting them off is undefined behavior.

          3. @Quin please find me a C which barrel shifts? Especially as the standard says “The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are filled with zeros. " (this is available in every draft of ISO/IEC 9899 , which defines C ).
            So the answers here are correct – depending on int size 0b1 <> n, it will give 0, 1 or -1 (in some weird case where n is sizeof(int) – 1 ).

          4. My previous post got cut due to larger than and smaller than treated as HTML code :D

            So 0b1 shifted right by n is either 0 (if overflow occurs), 2^n (if sizeof(int) is somewhat bigger than n), or the smallest possible negative number (if (n + 1) == sizeof(int) ).
            Shift that back by n bits and you got 0 (if overflowed), 1 (sizeof(int) > n+1) , -1 (sizeof(int) == n + 1)

            No barrel shifting. In C. By the standard.

        2. i = 16
          ? i >= i // true, i is still 16
          true <> 16 // returns 1, in any other case it would return 0
          ? 1 or 0 < 16 // true for ether case
          end result – returns TRUE

          I don't do C, by the way. But that is what I would expect.

      1. If int is 16 bits wide, the expression 1 << 16 is undefined. From the standard: "If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined."

        After undefined behaviour has been invoked, there are no correct answers, and the compiler may simply remove all that code as invalid (or make demons fly out your nose).

      1. The standard says that if a boolean expression is evaluated as an integer false shall be zero and true shall be 1. Whatever the internal representation of a boolean is, is unspecified. But (x<y) + 1 is valid C.

          1. Nope. Some compilers will have those defines as an implementation detail, but the standard does not prescribe how a boolean should be implemented. It does prescribe however what a boolean converted (implicitly or explicitly) to an int should should be.

          2. FALSE is defined as 0
            TRUE is defined as “not false”, which could be any non-zero number. At least, it is on the impls I use. Hence using a function return as an if condition doesn’t have a “!= 0″ added to everything, as in

            if (!tryToDoThing())
            {
            fprintf(stderr,”Failed to Do the Thing.\n”);
            }

            works great if tryToDoThing returns 1, -1, 42, etc

    2. ooops…. I forgot that there was a boolean equal operator

      i >= i (16 <= 16) (16 is always to 16)
      #1 will evaluate to true (1)
      2) 1 <> 16 produces 1
      3) 1 <= i ( 1 <= 16) returns true 1 is less than 16

      return value: 1 (true)

      1. I wish we could edit posts:

        ooops…. I forgot that there was a boolean equal operator

        i >= i (16 <= 16) (16 is always equal to 16)
        #1 will evaluate to true (1)
        2) 1 <> 16 produces 1
        3) 1 <= i ( 1 <= 16) returns true (1) (1 is less than 16)

        return value: 1 (true)

          1. So editor eats shift operators..

            Tried to say 1 shift-left 16 equals 65536, unless int is 16 bits, then it equals 0.
            That again shift right 16 then is either 1 or 0.

            Unless it is doing SIGNED shift, in which case who knows…..

    1. Same here although I learned C in the 80’s and used it regularly since then. I had some questionning about compiler implementation detail for int size but discarded those question assuming th most frequent 32 bits integers. But in practice I always check the basic data types size and limits in the compiler documentation.

  3. Nice.

    Oleksandr takes a provocatively dim view of C. Things gets a little brighter when you include a few lines of code checking your (otherwise tacit) assumptions explicitly. #error is you friend here.

  4. I think in general my C rating would be “mostly harmless” but …. I seem to ave got them all “right” though I must admit my reasoning was rather hazy… like “I don’t think you can do that” etc…

    1. Heh, though skimming the other replies now, I’m sorta thinking that never having learned one implementation well, and having “done battle” on half a dozen different architectures, which has left me somewhat confused and paranoid, was actually a minor advantage.

    1. I have to agree… border cases, implementation or machine specific stuff, compiler dependent stuff and undefined C behaviour. It’s all meaningless crap, you won’t find or write any code like that.

      1. “you won’t write any code like that.” i thought the real test of how good someone is a writing code is it shouldn’t be difficult to understand.
        is it odd that so many programmers seem to have a personality disorder where they have to compete to see who can go out of their way to create the most pointless exploitations of quirks in order to brag about how great they must be?
        The closest thing I can think of in other professions is a machinists cube but that really is an example of skills that they would actually use.
        I can’t imagine for example I don’t know if you went to apply for a job being an accountant and the interviewer asks you to do the tax returns for an anteater that lives in a different country and who’s last job was on the moon and then saying no you forgot to account for the pension contributions they get from each of the ants they ate for some reason.
        literally who cares if you can just google it and read a mind numbing explanation of some corner case quirk on stackoverflow.
        no that it matters anyway c is dead right? don’t we write everything in Haskell? or scratch or some javascript framework babby hand holding safespace abortion?
        a long time ago when I did a software interview the hardest question I got was write a function to remove duplicates from an array, I assumed the point was to use pointer and so that’s what I did, and the guy was basically sucking me off and I remember thinking wow is this a joke do people really apply for writing software and they can’t do stuff like this? if someone put this to me in an interview I would think what the actual fuck are these guys trying to do what is the point?
        I was only able to really enjoy writing software when I didn’t have to endure the tedium of other programmers and this kind of bombasity.

        1. Well as someone who has hired a LOT of programmers over the years, I think you are looking at the test the wrong way. I don’t expect anyone to write code like this. But how you approach figuring out code like this tells me a lot about your thought process. It also tells me if you understand that C doesn’t mean C on Linux, or Windows, or a PIC…. that there are differences between platforms. It also tells me how well you understand the standard and how forthright you are with what you don’t know.

          Sure, I could say, “Write a for loop to count to 100” and that would weed out the absolute dregs. But it doesn’t help me differentiate between a superstar and the merely competent.

          1. I would have posed a question based on something useful that they would actually have to do and then I wouldn’t end up with the only kind of unbearable people who bang on about this kind of thing.

  5. 5/5, but I will admit to being hesitant on the last one, but it was clear where things were headed.

    Anybody who has ever written C for both a “normal” environment and an embedded environment should have found the answers fairly obvious.

    1. Got 4/5. Missed the last one, b/c I thought it was a trick question. But the trick is that C is trickier than I though.

      But yeah. If you’ve written for 8-bitters, you’re not fooled by a 16-position bitshift. Well, not any more, anyway. Twenty-seven times bitten, twice shy…

      I really hate the Arduino style of using “int” instead of “uint16_t” or whatever, just exactly because it sweeps these kinds of problems under the rug. Writing explicitly what you mean never hurts.

      And i++ > 15 is the devil. Use i > 15 ; i++; and nobody gets hurt. They turn into the same machine code with any decent compiler, but you can read the code without thinking hard.

      1. IMO, you shouldn’t hardcode variable widths unless you explicitly need to (eg. for accessing hardware registers). If you’re aware of C’s type system, it’s entirely possible to write portable code without the stdint types. For example, it’s a PC programmer brain damage to assume that “int” can hold a 32-bit value. In Unix-style code, anything that needs to hold a 32-bit value will use “long”, because that’s what C guarantees.

          1. If you only ever program for one chip using one compiler, and never use anyone else’s code, you can probably ignore portability. For everyone else, writing robust code is the way to go.

  6. I enjoyed the test. On the system I normally program using C, I got answers I expected, and proved with a simple test program. But his answers prove that my knowledge is based on the behavior of my system. We do have coding standards that address these issues which avoid portability issues, and it good to know why the standards are in place.

  7. I was always tempted to say “I don’t work for free” when someone laid out a design problem in an interview.

    A buddy of mine worked in the compiler group at SUN and wrote a book to clearly explain all these boundary conditions. Do you know the difference between pointers to access array elements and using array indexing A[i][j]? I highly recommend “Deep C Secrets” by Peter Van Der Linden. It includes a really nice de-obfuscation algorithm and maybe my recipe for cake-pie-pudding, or how to count in binary on your hands, or easy truth tables. I don’t recall which.

    1. Well, if they drop the corollary on you, “Or for me!” and end the interview, everybody wins!

      I short circuit the whole process; if they need to see a resume, I assume I don’t want to jump through their hoops. If they know they want my help, they won’t even ask for interviews, they’ll make an offer. Saves everybody a bunch of wasted time.

      Judging from the comments, these are really awesome interview questions that weed out large swaths of educated idiots.

      That said, I’m more likely to pay people for 2 hours of work and see if they sink or swim than to give coding questions in the interview.

  8. Every year we hire several people, and simply follow the 30 day rule:
    In 30 days, you will be fired if you can’t learn to stop making trivial errors, and commit functional code that doesn’t break the build. A team code-audit will be done with other team members watching, and your days are numbered if your security practices continue to be shit other people have to clean up.

    Testing whether someone can interpret compiler specific syntax quirks or proprietary macro abuse is silly, and usually indicates a workplace run by arrogant individuals dangerously ignorant of their own limitations.

    Long term production coders know that a team revolves around readable coding standards, efficient API re-use, and human coordination. i.e. you may be smart and have skills… but if you’re an inconsiderate ass you will need to adapt quickly or find another job. Accordingly, I tend to give people who can’t hold a position longer than 10 months extra scrutiny, as other companies likely weeded them out already.

    With modern code-motion optimizing compilers, it is difficult to debug runtime errors where the conditional logic has been unrolled in an ambiguous way. Thus, it is bad practice to obfuscate what you intended your code to perform by mixing operators in the conditional logic, and rely on the compiler to fix your inefficient assumptions. Note, compiled languages are not just for computers, but for communicating structured ideas with other people.

    We usually initially ask just 3 questions (not in any particular order):

    i. one super easy-one that tests if you can follow instructions in English, and actually program in any language

    ii. one skill test, that tests how long it takes to finish a task (i.e. it’ll be done in about 20 seconds if you know the APIs well)

    iii. one virtually impossible question with an ambiguous answer, that is so obscure no one should be able to solve it under regular test conditions. As this shows how you handle a real world problem that Google can’t answer, and also functions as an honesty test if an answer actually matches the internal reference — given likely internal collusion with friends to try and socially engineer your way into a position of trust. Scams occur more often these days, but you will be warned ahead of time so you won’t stress out too much.

    Our policies may seem odd, but the interview will only last about 5 minutes — as we don’t want to put people through hours of high stress abuse like Facebook or Google.

    1. During interviews at our company we don’t do tests. Candidates are told to bring some code they wrote to show to one of our enginees (usually me) after my boss has finished asking questions. I let them explain what it does and try to ask at some points why they chose to implement it like that. The code tells my if they are beyond the “Hello World!” stage and know what beautiful code is. Bonus points if they use complex libraries.

        1. I remember only one case where the candidate brought code he wrote at his previous employer and he didn’t get the job. It was in fact hard to tell which part of the code was written by him and which part by his colleague.

          Maybe I’m a little biased because I started learning C at the age of 12, but I think people who never did any coding in their spare time have less of what it takes to be a good programmer (experience, enthusiasm, ability to find solutions on their own).

      1. I’m definately with you. Thirty years in software development and still going, for me. Programming is hard, and good code takes a while unless you’re a rock star. Excellent code takes even more time and brain sweat.
        Bringing along readable code, and a design doc with good formatting, ER diagrams and the like shows what you’re capable of. The interviewee’s enthusiasm explaining their work,the tools they used and the problems they surmounted should be evidence whether they have the skills and aptitude for you.
        LOL’s shop sounds like the place I would not like to be at – ‘Answer this in 20 seconds’ demands and stupid ‘virtually impossible’ Kobayashi Maru questions, wonder if they ask ‘where do you see yourself in ten years time?’ too.

        1. In general, they will not be asked anything not on their resume already.

          Hint, we don’t give interviews to people who don’t care about technology… like self-entitled kids with delusions of grandeur looking for a quick buck, or people who already retired 20 years early. Our business is not psychiatric care. ;-p

          If you have 30 years of production experience, than we would focus on your last project. I personally don’t care if you have a history prior to that key information… given it does not tell me if you are a burn-out, as there are always a few people with a similar tone foolishly advising corporate how to run their business.
          Out of 437 applicants we processed last month: only 12 were actually employable at the company.

          @evad
          We take NDA seriously, and have sometimes excluded people who have been legally tainted by certain companies.

  9. A friend of mine recently was asked, “If you have a structure and x is an element in the struct, how can you determine the offset of x in the struct without allocating memory for it (the struct that is).”

      1. You don’t think I do what? Know the answer? Well the only way I know how to do is it to create a pointer to the struct and set it to 0; The offset will be the address of x like the following

        struct blah {
        int a;
        int b;
        char c[4];
        int x;
        };

        int main()
        {
        struct blah *p = 0;
        int offset = (int)&(p->x);
        return 0;
        }

      1. That’s not the point of the question, but to gauge the candidate’s in-depth knowledge of C. Also sometimes the answer to the question is irrelevant, and what the interviewer is really interested is in how the problem is approached. That’s why all those “how would you measure the volume of Mount Kilimanjaro with a teaspoon” type questions exist.

  10. Can somebody explain to me question #5:

    int i = 0;
    return i++ + ++i;

    Let’s assume the case where the everything is done left to right:
    i++ will increment I to 1, but return the pre-incremented value, so it returns “0”
    ++i will first increment I to 2, and then return “2.”
    “+” adds 0 and 2 to get 2.

    Now, let’s assume that the compiler did the right-hand operand first.
    ++i will first increment I from 0 to 1 and then return “1.”
    i++ will then increment I from 1 to 2, but first it will return the pre-incremented “1.”
    “+” will add 1 + 1 and give you 2.

    So, in either case, the answer is 2, which is the same whether you get it by “0+2” or “1+1.” What am I missing here?

    1. From what I understand there it could be done in any order at all. From what I understood of the reason it coins return 1 from it loading the value of 0 and adding the left i to the right which could be 0+1. But ai haven’t read the spec so I could be entirely wrong.

    2. The C standard says that situations like this have undefined behavior. The compiler may produce an error and halt, or it may generate 2, or it may generate a different value, or it may generate code to delete your home directory. All are equally compliant with the standard.

      Here is an alternate interpretation of the meaning of “i++ + ++i;” that is less outrageous. The compiler can generate “i + (i+1)” as the return value, then increment i by 2.

      Although you can assign a meaning, as you have, for this very special case, in most cases auto-incrementing/decrementing the same value multiple times can’t be reasoned out as you have, so the standard just say none of them are defined.

    3. As I understand it, you are making assumptions about the timings regarding ++. If you wrapped i++ and ++i into functions and called the functions it would behave as you describe, but they aren’t functions.

      i++ is not saying “run the function i++ and return a value”, its saying something like “do something with i, and then increment it afterwards”. The problem is the something you are doing with “i” is adding it to another value, and that value happens to be “i”, which you want incremented before it is added to “i”.

  11. I thought the questions where fine. I was pleased with the anwsers. All the questions I was like to give an awnser I would have to make a platform specfic assumption. Not good code if you want portability.

  12. I remember a problem that I had in some graphics code. It painted characters in a framebuffer. In my PC it worked flawlessly, but in the embedded device where I wanted to run it, it misprinted one character.

    After hours of tests, I found that, in x86 architecture, “char” is signed, but in ARM is unsigned.

  13. I dont believe in any of these hiring process. Instead of asking the candidate questions to see if he knows what you know, why not just give him the mic and aell himself so he can show you what HE knows.

    Ask the question: tell me all you know about what happens the moment you type a query in google to the moment you get the reply.

    Will he talk about keyboard interupts, fifos and int-ack? Or about socket implementation, tcpip stack and layer2 stuff? Or about what happens in routers and switches?

    See, this simple question will help you see what HE knows. Then you can determine if he’s a good fit.

    1. First the Google elves at level 0 translate your query into High Lactrain which is the language of the ancient snake people. Then they transmit the signal using an encoding that uses smells and color to a pit that contains both a blind orc and dog with no nose (how does he smell? terrible!). Each of them gets half of the message and using a series of barks and grunts they reconstruct the message and the orc types it on a piece of rice paper in an Underwood typewriter.

      The paper is placed in a pouch under a carrier pigeon specially trained to find a data center that is not overloaded….

      At this point, I usually get the job.

    2. …and then the USB D+ line goes high, while the USB D- line goes low. Then the USB D+ line goes low again…

      Literally millions of things happen for a Google query, between my brain and the underwater-shipping-container Google servers and back again. The question is too broad. Are you asking about keyboard interrupts, Internet datagrams, search algorithms and gigantic network load sharing, or what? Chances are most jobs only require one of those areas. The guy who babbles on about keyboard matrixes isn’t going to be much help writing AI expert systems.

      Just ask him questions relevant to the fucking job! No trick questions, no “explain the history of the Universe up to this moment”. Just something that’s relevant to what he’ll actually be doing, so you know he can do the job. This is the way interviews generally go, and it’s the right way. There are no “hacks” to be applied here.

      The point of the web page that this article refers to, is “C is a bit of a tricky fucker”. Which if you know much C at all, you already are well aware of. Fortunately most people stay in the reasonably sane, well-explored areas of the swamp, and generally code compiles to do what you intend it to. In real life those 5 questions would be *terrible* for a job interview. Unless you needed to hire pedants.

  14. OK, I tried it and the test sucks. I got them all wrong because there is no answer that says “unknown”. Just “I don’t know”. I knew that there was not enough info in the question to answer each one, so I knew what was wrong, and there being no “unknown” or “unknowable” I chose one that was most likely – like the ASCII for a space character times 13 is in the answers.

    I assume the author of the test means for the “I don’t know” answer to mean “unknown”. Sheldon Cooper would tear him down brick by brick and I would (luckily I bet) never be hired.

    1. I sort of agree in the sense that no person being interviewed for a job would feel inclined to answer “I don’t know” for every question in a test. “I don’t know” sounds like “I give up” or “I have no clue”.

      If I were giving this test, I would remove the multiple choices and simply ask the candidate to explain to me how he solves each question.

    2. Your last sentence is the gist of it: if you fail the test, you are lucky because you won’t ever have to work with that asshole.

      Basing a hiring decision on trick questions – and all of these are trick questions – is the height of assholiness.

      Also, I’m pretty sure all of the examples would fail MISRA standards. =)

    3. Yeah; in an interview, “I don’t know” would probably not be the “best” answer; what you should do is ask the questions that permit a better answer: “are structures packed?” “What is the sizeof(int) here?” “on what CPU, with what compiler?” “who the hell would write code like that?” And for better or worse, some of those questions are “very likely” to yield predictable results. Because while overshifting or integer overflow might be “undefined”, I think they tend to behave pretty predictably and similarly on most modern CPUs, with most modern compilers.
      Sorta like asking “what does ‘#pragma pack’ do?” – you hope for an answer that is better than “it’s not specified by the standard.”

    1. +1 assumptions is the biggest source of bugs and security holes, and conflicts and misunderstandings for that matter. I like strongly typed languages better. But it’s our human nature to assume, as knowing for a fact takes up too much memory, we can’t function. A pc must assume its supply of power is clean, how many cpu cycles must be spent checking it? At 100% you’re more certain than at 99%, but never 100% certain, it is impossible. So we abstract our world and make assumptions that work most of the time, we build in some redundancies and hope for the best. Pc and other machines work much the same way, non deterministic, more like statistic.

    1. Yeah, I use C every day but I didn’t know these answers because I don’t even *try* to code like that in the first place!

      I used to use Perl, and I knew lots of language minutia and used it frequently.

      Then I used Ruby, and knew a much smaller amount of language minutia, and yet still barely used it because there was usually a simpler way.

      Now I’m using C and I don’t even want to know what the standard says. In Perl or Ruby I’m feeding an interpreter, and that interpreter is very credulous; it does what I tell it and I can fiddle what I told it to get slightly different semantics. In C that doesn’t make sense; the compiler is going to actually do something totally different than what I ask for, and there is no benefit at all to trying to shove a bunch of logic into a weird order or whatever. And using less specific types like int doesn’t really have a use case. In higher level dynamic languages, a more general type will often give advantages. In C it is just that the programmer doesn’t know what the type is, but it is actually still a very specific and non-general type.

      If I was using some library and needed to know what the implementation looked like, and I saw the stuff on the test, I would just switch to a different library. True story. Very few people need to know those answers. Do one thing at a time, because the compiler is going to remix it anyways. You just can’t win that game in C like you can in Perl. All C should be baby C, outside of the compilers themselves.

  15. This is embedded C?

    Firstly, what is int?

    you mean uint8_t? uint16_t?

    Secondly, this is the type of question you ask on a job interview? What the hell? Is the code you are presenting something that would actually be encountered in the job?

    What does the .lst file show after the compiler’s optimizer reduces that code out?

    I’ve got a test for you:

    (1) What information do you need to begin a new design project?

    (2) Walk me though your software development process.

    (3) When you don’t know the answer to the problem, walk me through the steps you use to solve it.

    The answer to the above 3 will tell me what to expect and what your years of experience really mean, and how much coaching you will need to be productive.

    1. A lot of really horrible “interview questions” get used in the hope that they will quickly lead to a “this candidate doesn’t know anything” answer. Your suggestion require that the interviewer actually listen and judge.
      (And this particular set of questions isn’t a good example of “screening” questions, either, IMO. If only because an idiot could answer “I don’t know” to everything, and you’d think they were doing great!”)

  16. Has anyone actually enter this into a IDE to see what it would do I did and I still have no idea.

    Microsoft Visual studio.
    #include “stdafx.h”
    #include
    using namespace std;

    int main()
    {
    cout <= i) <> i) <= i));
    cout << "And the anser is\n";
    cout << i;

    system("pause");
    return 0;
    }

    'ConsoleApplication1.exe' (Win32): Loaded 'C:\Program Files (x86)\Norton Security Suite\NortonData\22.5.2.15\Definitions\BASHDefs\20161102.001\UMEngx86.dll'. Cannot find or open the PDB file.
    'ConsoleApplication1.exe' (Win32): Loaded 'C:\Windows\SysWOW64\msvcp120d.dll'. Cannot find or open the PDB file.
    'ConsoleApplication1.exe' (Win32): Loaded 'C:\Windows\SysWOW64\msvcr120d.dll'. Cannot find or open the PDB file.
    The thread 0xb14 has exited with code 1 (0x1).
    The thread 0xa20 has exited with code 1 (0x1).
    The thread 0x208c has exited with code 1 (0x1).
    The thread 0x278c has exited with code 1 (0x1).
    The program '[5540] ConsoleApplication1.exe' has exited with code 1 (0x1).

  17. Sheesh… That test was easy!! I got them all right, and I don’t even know any C! XD

    Joking aside, it was kind of obvious what was going on, because the author emphatically stated that there was one and only one right answer in the multiple choice. If “I don’t know” is an option, then it logically has to be the right answer, because anyone who didn’t have a clue would otherwise contradict the “one and only one” clause. I hate trick questions; it’s one reason I refused to go into academia.

    1. “I don’t know” logically means “the C standard for this behaviour is undefined”. Not knowing because you don’t know C, or can’t read English, or are a cat sat staring at the computer, isn’t the intended meaning!

      I was surprised at the answers all being that. I only did the first couple of questions then got impatient. I got the first one right. Problem with a lot of it, is I think it depends on the hardware you’re compiling for. That’s why sizeof() exists. Otherwise everybody would just use “4” for ints instead of checking.

  18. It won’t compile because main is undefined.

    most embedded systems will expect at least int main()

    Of course in an embedded system it generally won’t matter what your return from main.

  19. The horror of that site, is that the guy was programming vital controller stuff for a nuclear reactor, in C! BASIC would’ve been safer. Or ladder logic, or whatever. I’d hope there are standards, somewhere, that prohibit C code in stuff like that. After all that’s one reason the American DOD invented ADA.

  20. For more examples like this, see the Frequently Questioned Answers http://yosefk.com/c++fqa/ I’m particularly fond of the “const correctness” section.

    Never forget that in C++ it was *discovered* that the template language is Truing complete. Many people on the *design* *committee* didn’t believe it until someone rubbed their noses in it by causing the compiler to emit the sequence of prime numbers during (infinite) compilation! That’s from https://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP with my emphasis added. The original is at http://www.erwin-unruh.de/primorig.html Note: not designed, but discovered – and that’s exactly what happened.

    Personally I prefer my languages to be designed, not discovered!

  21. Interesting test. I only got the first one right

    I mainly use C at the hobby level for microcontrollers or small commandline things. I allowed myself 15 min, and had a couple of books handy.

    I’m not about to cut my throat or switch to pottery as a career… I don’t as a habit write or use code blocks that I don’t understand… but it was a touch humbling and a reminder that there’s lots yet to learn.

    My current job just used some basic screening for code competence in their hiring process, and probed for experience in their problem space. If I’m lucky, this is my last fulltime job and I will never have to endure another stupid job code test.

    1. I’ve seen two different approaches at high tech companies in the same space… One emphasises hiring strong scientists, figuring anybody can figure out how to get the math into code, but they gotta know the math and science ass backwards…. the other emphasises hiring strong coders, figuring anybody can crib the formulas from papers, but they gotta know the code ass backwards…

      The result, one produces stuff with clunky interfaces, slim features, but it’s all rock solid dead on, though sometimes you have to reset the software on a daily schedule. The other, slick interfaces, feature rich, lots of BS for management, but it represents the “science package” inaccurately at times and doesn’t sanity check the data or constrain data error factors.

  22. Around the third question I was beginning to doubt myself because I thought every single one was “implementation defined”. Good to know all the head desks from programming very different micros in C weren’t in vain.

  23. Mostly interview questions should be about having the candidate demonstrate their knowledge on a given subject; often by having them discuss a relevant project they’ve worked on, and asking probing questions.

    Instead we see questions that are more like riddles, that only test if “you’ve heard this one before” and allow the interviewer to free some sort of misplaced smug superiority.

Leave a Reply to asdfCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.