Importance of bitwise thinking

Question

I take interview for my company. During interview I've faced many candidates having 1 to 3 years of experience in their field. Typically, they had experience in C#, Java, J2ME, iOS and similar platform. Few had working experience in C and/or C++. I'm a C++ programmer but typically I don't ask very C/C++ specific questions during interview. I test their ability to write and understand programs.

I did observe that many candidates have basic knowledge about programming. They understand and can write easy programs in their chosen language. They can solve most of the problems I ask. To my surprise, most candidates fail in specific type of question: bitwise thinking. They fail to write a code that swaps MSB with LSB of a 16 bit integer (like, given 0xABCD, make it 0xCDAB). They fail to write code that toggles a bit in an integer. Etc. If I show them the code involving bitwise operation and ask them to write what the code does, they fail to answer, given that I tell them to ask me if they've any question about syntax.

I found that they fail to understand that inside computer memory every number can be thought as decimal, hexadecimal, binary, or in any other base. Some of them got scared if I show an example in binary.

There is no doubt that when we'll hire these candidates, they won't be working with bits - at least directly. They don't need to solve any bitwise problems while working in our company. And their performance is promising at what they do. But I can't think about a programmer who can't think bitwise.

Should I discard these candidates? Or give them a chance?

Answer 1

You've mentioned that solving bitwise operations is not a skill that people at your company will need to do their jobs. You should therefore not even be asking about it.

Answer 2

Software development is a huge and diverse field now. For some jobs, not knowing bitwise operations would be completely disqualifying. For others it is close to irrelevant. My personal mantra is that you must understand at least one level of abstraction beneath the level you usually work at. I write bioinformatics code in C and C++, so you can bet that I know about bit level operations. However, if your line of work is writing web front ends for databases, then the bits and bytes may be less relevant, but you'd better understand HTTP and the relational db model. This is particularly true for folks who have only been working for a few years.

One of the best programmers I ever worked with was a SQL guy who'd gone to a trade school. Once day in conversation, I was stunned to learn that he had no idea how floating point numbers were represented on computers. You probably don't want him writing your financial modeling software, but then you probably don't want me designing your databases.

When you are hiring junior people (and 1-3 years is still pretty junior in my book), don't just try to clone yourself. Try to come to an honest appraisal of whether they can do the job or not.

Answer 3

For me, it's like someone applying to be a baker who can only make cake from a mix. Maybe that's all you need for the job, and maybe you're very good at it, but you've intentionally neglected some foundational aspects of your profession, which says something about your devotion and aptitude.

I also presume you ask your developers to occasionally learn something completely new related to their job. Learning from your colleagues is a critical part of our job description. Therefore, even if they have not used bitwise operators before, I would expect someone to be able to learn them in an intelligent manner with some coaching. Our software doesn't use exceptions at the moment, but that doesn't mean we will never use exceptions in the future, and I'd expect an applicant to be able to muddle through in an interview with some coaching. If you don't have a rudimentary understanding of a concept, how will you know to brush up on it if it ever turns out to be the best tool for a task?

I'm not just one of those people being harsh who has never been in a position like this. I interviewed for a C++ job once with very rusty knowledge of the syntax for specifying classes and their relationships. I was asked some very tough questions along those lines, which I didn't know the answers to, but I got the job because I demonstrated I could figure it out with some coaching. It's not too much to ask.

Answer 4

The candidate who can answer this could be given extra edge, but the candidate who can not answer that should not be neglected altogether.

If there is a candidate who do not know bitwise operator but knows the time complexity of heap and hash, i will consider the candidate. This is what he/she will be doing on daily basis, and I expect him/her to be proficient in that. I may ask bitwise operator questions just to see the thinking pattern. But will give less weight to it.

It may be useful if you have two very similar candidates, and have to choose only one. Both answered all the questions properly. In this case may be this can be helpful.

Answer 5

I don't think you should discard applicants just because they are not well versed in bitwise operations, but you might want to pay more attention to why they aren't well versed in particular skills you may take for granted. A fifteen minute talk with them about their programming experiences and training (possibly including college courses, but only if relevant) may explain more about why they know what they know, which in turn could lead you to better understand exactly what they know and whether they could be relevant to your project than asking arbitrary questions that you would expect "a typical programmer" to know.

It is not surprising if a person has been an industrial Java and .NET programmer all their life (possibly a music major in college, missing out on system architecture, and OS theory), and didn't know how to swap variables in place using bitwise operations. It could be OK, and possibly even better, depending on your needs.