Is bit twiddling a good test for embedded engineer [closed]

Closed. This question is off-topic. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 11 years ago.

Improve this question

I am questioning candidates for embedded software engineers (in our company we use mostly C, sometimes C++). I usually give to the candidate a bit twiddling question. I do not mention that it can be solved with bit twiddling, when it is not obvious. I also accept solutions without using bit operations, but then I guide the candidate into bits (e.g. by saying: "What if you can't use modulo operator"). The example question could be:

• check if a number is divisible by 2 and not divisible by 4
• round up a number to next power of 2
• count set bits in a word
• find the oldest bit that is set in a word
• etc.

In my opinion such questions should be easily solved within one minute by any decent software engineer (or even fresh graduate), regardless in which software domain he works. However my boss recently complains that these questions are too low-level for someone that is going to work e.g. in GUI. It came to the situation, where my questioning was useless, because my boss hired a candidate that utterly failed in this topic, but he claimed that he was experienced in Qt (I could not check this, as I have never used Qt, and for some reason I was the only one that could in开发者_开发百科terview him at this moment).

So my question is: is bit twiddling a good question for any (embedded) software engineer, or my boss is right and I should give up asking it to all candidates?

---

I think the thing to be careful about is that you aren't asking for knowledge where it's basically random whether the interviewee has it to hand or not. For your examples, I cannot immediately remember what the bit-twiddling hacks are for the most-significant bit questions (finding it, and rounding up to the next power of 2). I know that there are hacks that I could look up, and I know about __builtin_clz on GCC which of course isn't portable.

So, have I failed the interview? And if so, are you sure that I'm not fit to program Qt in your company? You're implementing a filter, and you just have to think about the false positive rate (how many people will know the bit-twiddles but be poor employees) and the false negative rate (how many good employees have forgotten the bit-twiddles).

Of course all interviews have a false negative rate. The cost to your company hiring a bad employee is pretty high, so you have to be certain. For that reason, I think that if this employee turns out to be good, that's probably more by luck than judgement on the part of your company -- you shouldn't hire someone to be a Qt programmer without testing their ability with Qt or something similar. What's the cost of setting up a second interview with each of the three best candidates, taken by one of your Qt people, compared with the value of hiring the best one? What's the cost of your time to interview the candidates, given that this interview has no influence on the hiring decision?

Just remember that different kinds of programmers have different knowledge at their immediate command, and make sure that your questions are strongly correlated with the kind of programmer you want. On this particular subject, what it proves is that the interviewee has spent time bit-twiddling, possibly in the fairly recent past. On the plus side, that's time they spent programming. On the minus side, that's time they didn't spend writing and learning Qt.

I would be concerned if someone didn't know how to check the lsb, and didn't know that for positive values and for 2's complement negative values, the lsb is 1 for odd numbers and 0 for even numbers. That's because I expect programmers to know what a binary representation is. I would also be concerned if someone thought that x & 1 was likely to be better in some way than x % 2, because it means they use a terrible compiler ;-)

I wouldn't be too concerned if someone couldn't remember the bit-twiddle for popcount. Slightly more if they couldn't figure out the code for it after you'd given them a heavy hint of one of the simpler ways to do it: "How could I compute the popcount of a 2 bit integer using bit-twiddling? OK, now write a line to do that in parallel for each of the top and bottom 2 bits of a 4 bit integer. OK, now write a 32-bit popcount".

---

If you are programming in C, I would say yes. Bit twiddling is not something you do everyday, but something which shows that you understand how the computer handles your data.

If you program in a higher level language, I suppose it is less important.

---

for an embedded engineer or a software enigineer that will have to cope with talking to specific hardware etc these questions are good. There's a likely chance they will have to write code that fiddles wih bits then. Not sure if this can be solved within exactly 1 minute though, especially not if the engineer in question wants to do it in a generic way.

---

My opinion is that every electronics and/or software engineer must know these things. These are the basics of digital computing and computer programming.

---

I think this depends on what kinds of embedded systems they'll be working on, and what they'll be doing with them; "embedded" covers a very wide range of hardware. If they'll need to write low-level code or work with small microcontrollers, things like bit twiddling matter more than for higher level code on something bigger like a PC-compatible SBC.

However, even when using a more powerful system and not writing low-level code, it's still important to be somewhat familiar with bitwise operations -- at least enough to handle bit flags and the like (at a minimum).