Correct Use of size_t

January 31st, 2009 by Edmond Meinfelder

One misunderstood part of C is size_t. First appearing in ANSI C around 1990, size_t is routinely misused. People either use size_t incorrectly or they don’t don’t use it at all. The idea of its use is simple and I’ll attempt an equally simple explanation. The appropriate use for size_t is to describe the size of objects and not as an alias for unsigned int.

unsigned long min_index=min, max_index=max;
for (size_t i=min_index; i++) data_array[i]++;

The previous code can break. The assumption in the previous code sample is that size_t can store min_index and max_index, but on some platforms, size_t may be smaller than an unsigned long, causing overflow errors. The above code should use unsigned long for the index.

Using size_t as an alias for some type of int on your target architectures may seem functionally sound, but your assumptions are likely wrong and the code is semantically wrong. Since the type of size_t will shift from platform to platform, you shouldn’t rely on size_t to do anything other than describe the size of objects and types.

int obj_size = get_obj_size();
struct very_large_struct *ptr_src_vl=src, *ptr_dest_vl=dest;
ptr_src_vl = malloc(obj_size);
/* sanity checking for ptr_src_vl validity not shown */
memcpy(ptr_src_vl, ptr_dest_vl, obj_size);

The previous code is not using size_t where it should. The C standard states int types must be at least 16 bits. Therefore, the above code has an implicit limit through the size of the int type. Imagine size_t is 16-bits and has a sign (it can happen, but shouldn’t) yielding a maximum value of 32,767. The lesson is: the maximum value for an int type has no bearing on the maximum object size for a platform. However,  size_t will hold the maximum possible object size for your system (assuming your C implementation is correct). If you go with the C standard on this issue, it will help your code portability and maintainability.


Interviewing Programmers

January 25th, 2009 by Edmond Meinfelder

After my former CEO said, “We’re shutting the company down,” I had to interview. Which is not much fun when the interviewers aren’t good at it. Bad interviewers, about half of those whom I met, did one or more of the following mistakes:

  • Assumed candidates are perfect fits, until proven otherwise
  • Relied on random quiz questions to establish technical competence
  • Looked for a grocery list of skills rather than intelligence or ability
  • Forgot the candidate is also interviewing them

Start at 0 and Work Up

In most interviews, I walk in the door as a “100%-fit” in the eyes of the interviewer and lost percentage points for every question I missed. For knowledge-intensive workers, it’s the wrong approach. At one interview, I aced it after correctly answering all their questions. The job wasn’t a good fit for me, but because I had the right answers, I was a fit. However, the job required skills I didn’t have — they just hadn’t found a reason to not hire me. Failing to find reasons to not hire is not the same, or as good as, finding reasons to hire. Find reasons to hire candidates rather than assuming they will work until they miss a question. This removes luck – some can sail through interviews and still not be a match.

Quiz Questions

The technical interview usually unfolds as a quiz of technical questions, that are often obscure. The logic is, if the candidate knows the obscure parts of a technology, they must know the common parts. At one interview, I aced the quiz and managed to get bonus points by answering the question, “How do you share file descriptors between Unix processes?” Coincidentally, the week before, I read the solution in W. Richard Stevens‘s Advanced Programming in the Unix Environment. They over-rated my ability based on trivia questions I happened to get right. Joel Spolsky wrote a significant article for hiring technical workers, The Guerrilla Guide to Interviewing and in it, said the following about interviewers employing quiz questions:

This is the kind of person who thinks that smart means “knows a lot of facts.” [...] There is no possible, imaginable correlation between people that know that particular piece of trivia and people that you want to hire.

He’s right. However, candidates need to enter with a minimum of knowledge. Phone screens are good for determining if the requisite knowledge is present. For C/C++ programmers, I ask basic knowledge-based questions on fundamental aspects of the language. What is the stack and the heap? What is the time complexity for an algorithm that traverses a binary-tree? Explain inheritance and polymorphism. This is not obscure trivia, or a quiz, its a sampling of the basics you need to know to be effective in C++. That and some descriptions of how they contributed in recent projects will fill out phone screens nicely.

Match Ability Before Skills

Looking for specific skills or experiences can exclude great candidates. Sometimes, you can spot a match for another group or, if you have open mind, you can spot abilities that can overcome skill gaps. Imagine your open position requires a C++ network programmer, though the candidate knows networking programming, it’s with Python and Perl. The person demonstrates amazing knowledge of algorithms, fantastic problem-solving skills and a great attitude that would fit in with your team. Moreover, the candidate is self-taught in both Python and Perl, becoming adept in each in weeks. Given a choice between someone with high intelligence and gaps in skill and another with average intelligence and no gaps, with all else being equal, I’ll select the more intelligent candidate.

Forgot the Interview Goes Both Ways

In one interview, I was made to wait 30 minutes as the hiring manager “had an important meeting.” It’s hard not to read into the manager’s priorities. Worse, when my prospective manager showed up, it was clear he had not read my resume. When he became bored with my answers, he would interrupt to start with the next question. An interview is like a first date where everyone is on their best behavior. If the prospective employer is rude during the interview, it’s hard for candidates to imagine the workplace values workers and their contributions. Maybe the manager had a legitimate emergency and was “off their game.” The best thing to do would have been to apologize and re-schedule the interview. Though that’s also poor, it is better than overwhelming potential employees with unprofessional behavior. Even if the interviewees are poor fits, it’s best to treat them with the same respect as everyone else because it’s the right thing to do.


  1. Screen the prospect, ensure they have the minimum knowledge, skill set and experience.
  2. Figure out what the candidate can do.
  3. Avoid quiz questions, focus on relevant problem-solving.
  4. Don’t just match positions with skills, look at the candidate’s abilities.
  5. Remember, the candidate in interviewing you, too.

Favorite Technology Trap

January 24th, 2009 by Edmond Meinfelder

Many programmers have a favorite language — usually the one they know best. To me, it’s a fault if the developer sees the language as a hammer and every problem a nail. If hiring a plumber I’d ask, “What is your favorite tool?” The winning answer would be, “Whichever tool suits best suits the problem in front of me.” Experience with a technology should have no bearing on a technical solution, but it often does.

One likable thing about interviewing is meeting others passionate about technology. Recently, after my last company closed, I interviewed. Small, early-stage startups seem to be the most chaotic in technology choices. At early stages, it’s a small group of developers with only one goal: prove the idea works. When I see a baffling choice, like a high-level scripting language, doing CPU-intensive tasks, I ask, “Why?” The more defensive the answer, the more frightened I gets.

Favorite technologies create selective vision for the afflicted. Problems in other technologies are immediately obvious while the favored tool remains The Chosen Answer. Everyone who disagrees is a heretic. Additionally, when you have a favorite technology, and that technology hits its limit, it is somehow acceptable to change the problem.

“Why did you use Java to stream multi-gigabyte files to create SHA-1 hashes?”

“Java has excellent support for databases and creating hash keys.”

“The SHA-1 key generation could not keep up with the stream, missed bytes, and produced the wrong hash key.”

“You’re right – we need to figure out another way to create the hash keys.”

That’s the problem with a favorite tool, you rationalize your way into using it, even when it’s not appropriate. Why would smart people do this?

Their favorite technology is where many invest significant time. Most people want to be in, not out, of their comfort zone. Sticking with a well-known tool is a way to stay comfortable. This is a huge issue with change management. Getting people to learn new skills often meets huge resistance as they fear devaluation while they come up to speed with the new technology.

A way to avoid this trap is to hire engineers who like what they can do with technologies more than any one technology. Ask open-ended questions in interviews, e.g. what languages or platforms they like or don’t like or what kinds of problems they like to solve. Don’t lead the candidate or broadcast your intent, just listen. If you take some time to get to know the candidate rather than asking obscure technology quiz questions, you may be able to figure out if they are already in the favorite technology trap.


Fear of Failure and Quality

January 19th, 2009 by Edmond Meinfelder

Lydia wrote a great article titled “The Process Trap,” that asks weather company processes help or hinder quality of service. The trap results from a company’s inability to acknowledge and learn from problems. About half of my past workplaces fell into the trap Lydia describes. For individuals, it’s dispiriting to feel “stuck,” and for companies, these are lost opportunities for improvement.

Everyone with whom I’ve worked wanted to provide the best service possible. However, when the penalty for failure is significant, people become fearful. With fear, people’s motivations change — they become less concerned with quality and improvement and more concerned with avoiding failure. Fear of failure is a such a huge detriment to quality that one of Dr. Deming‘s fourteen points for management effectiveness is, “Drive out fear.” Deming wrote that in 1986 for Out of Crisis, so the idea is not new, but not everyone reads Deming.

When customers won’t receive acceptable service, what will employees do when fearful of deviating from standard operating procedures? They will ensure customers receive lousy service. No process will fix that, because it’s an issue of leadership. Somewhere between the person answering the phones and the board of directors, someone has to stop being scared and enable the people under them to do the best work they can. When you’re under a lot of pressure, and most managers are under pressure, it’s hard to be fearless, but not impossible. Absence of fear is necessary because it takes people to improve and adapt processes and people will avoid changing anything when scared.


Hardline Management at Yahoo

January 18th, 2009 by Edmond Meinfelder

On ValleyWag, Yahoo CEO Carol Bartz reportedly told staff she would “dropkick to fucking Mars” anyone whose gossip about Yahoo ended up on the blogs. The quote itself was on ValleyWag shortly after. Aside from the obvious fact that treating people with disrespect is wrong and potentially illegal, managers who only care about profits should still avoid this behavior. The key asset of a technology company is not the technology, but the people. Not matter how good your technology is, in a few short years today’s intellectual property will be tomorrow’s commodity.

Threatening employees is demeaning. Your best employees, the ones you want to keep, will have other employment options and, after being repeatedly abused, they will leave. Meanwhile, the people whom you’d better off without, will stay. Demeaning people pushes staff talent the wrong way (down).  In a technology company, this throttles the competitive advantage.

While the threat is strong, this is not strong leadership; it’s not in the company’s interest. Over time, this management style will discourage, demotivate and drain talent, which is especially dangerous for technology companies.