Visibility and Obscurity

Several years ago, when I first started at PayPal, the front-end development environment was still fairly young. As a result, tools that might have existed in other environments were missing.

As a veteran coder, I quickly grew tired of repetitive tasks - I wanted to be writing code - and set about writing scripts that developed into a significant tool suite. I shared that tool suite with both front-end and back-end developers (there were no full-stack developers in those days) and the use of those tools spread throughout the company, across the globe.

Out of that activity, there were two different experiences that bear examination. I'll address the later of the two experiences first.

In later years, as the development environment matured, another engineer - one responsible for establishing a standard development environment - took control of the tool suite (totally understandable) and put his name on my work (not understandable). The tools I had birthed and nurtured through numerous changes in the development environment, and continually promoted so they would be visible to all engineers - were adopted and their new foster father promoted himself as their creator when they became visible to upper management.

This is not an unusual situation. It happens all too often - much more frequently to women, of course - that someone other than the individual who has done the work takes credit, especially as the work becomes more visible.

That experience taught me two lessons. First, how you handle it says volumes to those who see the situation. Second, obscurity can be moments away, behind someone else's shadow, even when you think the visibility you've worked to cultivate over years is secure.

The second experience was much more pleasant. On a regular visit to a development office, I was introduced to an engineer who had recently joined the company. The engineer and I exchanged pleasantries - the normal "nice to meet you" bit - and then the engineer who introduced us told her my username (which was explicitly tied to the aforementioned tool suite)...and her expression and demeanor shifted dramatically. As someone who's never been in the "popular" club (yes, I've been a nerd and geek since before secondary school), that reception was quite an ego boost.

I had no real expectation of receiving such a reception - none of my long-time friends who'd seen me develop the tools reacted in the same manner - and it caught me by surprise. That reception also taught me a lesson - there will be some ways in which you're always more visible than you believe you are.

History is eager to write out of the picture those who have struggled to build great things - whether it's a woman who's made a significant contribution to our community (like Nicole Sullivan, the creator of OOCSS) or a man who is more interested in the work than the credit (like Nikola Tesla).

When you find yourself in these situations - situations of visibility and/or obscurity - how you navigate those shoals says volumes about your ambition, your drive, your values - such as integrity and trust, and what you know to be true about yourself. In those situations, may you have fair winds and running seas.

Happy coding.

What Isn't Said

If you're a follower of this blog, you'll notice that my posts tend to fall into three general categories. There are posts about how do something, like put PayPal on your Facebook page, build a slider toggle, or include reference notes, posts that show a different side to things in technology industry news that catch my eye, and posts that are general career advice from someone who has spent a few years in a very turbulent industry. I'm not sure if this post fits in any of those three categories, or if I'm starting a fourth after reading the blogs written by two men I consider to be, at the very least, something more than acquaintances (http://www.thejourneyismydestination.com/ and http://www.codercowboy.com/). I should point out, I suppose, that neither of these has the reputation in the industry of Eric Meyer (http://meyerweb.com/) or Nicholas Zakas (http://www.nczonline.net/), but I suppose that gives them a little more influence in my estimation because they are writing, not because they need to but because they need to, and I see something of myself in that, and besides, their year-end posts were good.

In addition to the inspiration from other bloggers, this time, as I looked back on the past year and looked forward to a new year (as many of us do at the start of a new year) I came across interviewing tips from recruiters and one in particular caught my eye as I read through the post, asking myself the interview questions as part of my year-end self-reflection. The question caught my eye, in part because as someone who has conducted several interviews and 'phone screens', I find it to be a question that I've been asked, but have never asked - it's simply what is your greatest weakness.

This time, perhaps I found insight that has eluded me in previous years or perhaps I have rediscovered a forgotten truth, but I recognize that there are those who see my greatest weakness only as a weakness, while I see my greatest weakness as a strength as well. This difference in perspective likely comes about because we all expect that other people to not only understand our actions - because they're based on beliefs that spring from rational thought - but to share those rationality-generated beliefs our actions are based upon. However, that universally-held, unspoken belief is false - there are those who do not understand our actions and do not share our beliefs, and likely never will - their perception is fixed and the die is cast.

Here's where I offer a bit of advice. When this happens to you, and it's extremely likely it will, at some point although you will not fully realize what is happening you will attempt to cast what others see as your greatest weakness as a strength. This is a Sisyphian task, and no matter how many times you roll that boulder up the hill, scrabbling for every inch of dirt, it will roll back down, and all the while, none of us acknowledge or challenge our perspective unless we trust each other - really trust each other - and remember that we're human, doing the best we can with any given situation.

As the past year closes and a new one is begun, I am also reminded that good leaders know the strengths of those on their team, and beyond that, great leaders see strength where sometimes even team members see only weakness. As we work together, maybe we should take Peter Drucker's words to heart and listen for what's not said - search for those points of weakness - and talk about why we see them as weakness but to then use our trust of each other to move beyond that to see them - really see them - not only as weakness but as a hidden strength, because whether we're the team captain or just one of the players, we can all benefit from the humanity that comes from trusting each other.

What's in a name?

Women face a number of barriers in science-based endeavors, perhaps more so than in other fields1. This matter is not really even open for debate. What is up for debate is whether or not it's justified and whether or not we will actually do anything about it.

Much debate surrounds the causes of the gender disparity evident in many fields. Some argue that girls and women do not pursue STEM2 educational programs and therefore either show a lack of interest in the topics or aren't generally qualified to pursue the programs. This is, almost certainly in part, due to traditional gender roles, but it cannot be limited to that as the limitations based on traditional gender roles have decreased as time has passed and societal norms have adjusted.

Another portion of the lack of pursuit of STEM programs by women is almost certainly self-inflicted doubts. This can be seen in a (1946) conversation between Einstein (yes, that Einstein), and a South African girl named Tyfanny. In corresponding with her, after she revealed her gender, Einstein said,

I do not mind that you are a girl, but the main thing is that you yourself do not mind. There is no reason for it.3

Einstein recognized, in Tyfanny's words, the self-doubt resulting from generations repeating the societal refrain "you're a girl".

These problems are significant, and we must fight tenaciously to overcome them; however, these facts alone are not enough. These are facts of history - facts that society has dealt with for years and yet, one might argue that while female representation is much lower in STEM-related fields, it is significantly imbalanced in many fields4. Why is this? Why are we not convinced that especially science, technology, engineering, and mathematics are about ideas and not something as trivial as gender? Are we really so blinded to not be convinced that women can think as well as men?

I refuse to believe that it is something in our conscious behavior, and I posit that our bias goes much deeper than we originally thought. Even though we have convinced ourselves that even if the larger populace does not subscribe to a meritocracy those of us in STEM-related fields are well into a meritocracy, we have deceived ourselves.

In what should have been a mind-blowing study written more than a decade ago, Rhea E. Steinpreis, Katie A. Anders, and Dawn Ritzke revealed that both men and women demonstrated gender bias in hiring recommendations.5 The subjects for this particular study were all PhD-level psychologists - people who should recognize that science is about ideas and not gender, people who should recognize trivial and non-trivial information for what it is. In a similar study, written just last year, it was demonstrated that even among science faculty at research-intensive universities, gender biases favor male students.6

What these two studies illuminate is that our gender bias is so thoroughly ingrained that even individuals who are trained to deal directly with data, identifying what is trivial and non-trivial on a daily basis, are incapable of suppressing something as trivial and unreliable as name-based gender bias. Before anyone starts with the 'academia vs. real-world' arguments, a cursory search regarding this topic yields some very interesting anecdotal evidence that supports the same hypothesis.7

We are, like the characters in Shakespeare's Romeo and Juliet, using names as a priori judgments. These two studies also speak volumes about our decision quality, our hiring and staffing policies, our integrity and values, our knowledge about our ability to evaluate people and ourselves, and even our ability to manage diversity.

When otherwise qualified candidates are eliminated from the process based upon their name it's easy to see where a significant portion of the disparity originates. We can work to correct gender stereotypes and eliminate gender roles from early education, we can do a number of things to encourage girls to enjoy and pursue STEM education and programs, we can even build gender-based groups that encourage and promote not just gender balance, but women in the work-force on university and work campuses across the country. None of our efforts to increase education, ban words, or anything of the sort will mean anything until we address eliminating the gender bias that is demonstrated to occur at the first step in any selection process.

Of course, one of the worst parts of this situation is that even though this has been a known issue for more than a decade, we've done nothing to change the situation even though it is incredibly easy. How easy? Here are four simple policies that every organization could adopt with little to no impact to their schedules or bureaucracy, which would alter the landscape significantly:

1. Publicize the existence of gender biases in relation to CV's and resumes and what is being done to compensate for it or correct it.
2. Replace names with unique codes on all CV's and/or resumes that are submitted prior to their being screened.
3. Restrict access to names and codes during the selection process
4. Identify discussion of a candidate's name as especially problematic and a punishable offense

As a bonus, when these policies are introduced, other name-based biases will be reduced or eliminated as well - the most notable are race, nationality, and religion, because when Juliet, in Romeo and Juliet, asks...

What's in a name? That which we call a rose by any other name would smell as sweet.

Romeo and Juliet, Act II, Scene II

...as it turns out, there's more than enough information, and if you don't believe me, just ask Romeo.

Notes and references. Links in the notes and references list open in a new window

1. You can find the research regarding the types of barriers women in science face, published by AAUW in "Why So Few? Women in Science, Technology, Engineering, and Mathematics", at http://www.aauw.org/research/why-so-few/
2. Science, Technology, Engineering, and Mathematics
3. This tidbit is revealed in "Dear Professor Einstein: Albert Einstein’s Letters to and from Children" by Alice Calaprice, along with views on gender's relationship to the study of science that were far ahead of his time - i.e. it doesn't matter.
4. One recent edition of philosophers' sound-bites (Philosophy Bites, by David Edmonds & Nigel Warburton) references 44 males and 8 females - a paltry 15%.
5. The study is called "The Impact of Gender on the Review of the Curricula Vitae of Job Applicants and Tenure Candidates: A National Empirical Study" and you can easily find it online and read it in its entirety - which I recommend.
6. The study is called "Science faculty’s subtle gender biases favor male students", by Corinne A. Moss-Racusin, John F. Dovidio, Victoria L. Brescoll, Mark J. Graham, and Jo Handelsmana. You can read it at http://www.pnas.org/content/109/41/16474.full.pdf+html.
7. In the blog post "I understood gender discrimination once I added 'Mr.' to my resume and landed a job", an individual seeking employment in a non-STEM-related field relates how self-identifying as a male on his CV made a positive change in the response rate to his inquiries.

One last note: If you follow this blog, you might have noticed that I've been missing of late. To offer explanation (not justification or apology) I will say that sometimes personal lives get very busy, we have a temporary shortage of creativity (e.g. writer's block), and we need time to work up the courage to say what we need to say how we need to say it rather than just exclaim "WTF!" and be done with it. For me, it's been a mixture of all of these as I've seen my oldest niece married, contemplated my daughter's education, and ruminated regarding how to address gender disparity in hiring for quite some time, even discussing the policies that will correct this with women in technology companies before writing this post.

What kind of engineer, indeed.

Several of my friends and colleagues have tweeted and otherwise commented about a post on the extremely knowledgeable Nick Zakas' blog.

I have a lot of respect for Mr. Zakas, and often enjoy his blog posts, learning something each time I visit, and this post was no exception. Unfortunately, there is also a point with which I don't agree...but it's not really Mr. Zakas' point. He says,

If you stop and think about it, writing code is something that a lot of people do. You can hire someone cheaply out of college to write code and it may not be as good as an experienced software engineer, but if it’s close enough, that’s usually all you need. So if your programming acumen is the only thing that you focus on, you aren't improving your position in the company. What matters far more are the soft skills that you have along the way. Do people enjoy working with you? Do you add something over and above your coding skill?

First, to Mr. Zakas' point, there are a lot of people who can code...but there is a potentially significant difference between "close enough" and "correct". With "close enough" your revenue most likely will not be zero, but it will also likely not be as much as it would with "correct"...and in some situations, "close enough" may be nowhere near close enough. If we're talking about a web page that responds in 8 seconds instead of 4 or 6, that may be one thing (though you might want to see my earlier post about speed in websites, Faster, faster, faster) but if we're talking about real-time or life-critical software, is "good enough" really good enough.

Still, Mr. Zakas is correct in that our reputation is important...but therein lies my problem, and it's demonstrated to a degree by those Peter Hinssen refers to in Will the real CIO please stand up - individuals who associate responses to the phrase 'IT departments' which are "wonderfully colorful comments such as 'arrogant', 'out of touch with reality', 'language of their own' and - increasingly often - 'hopelessly out of date'."

Are there engineers who are reasonably considered "arrogant" or "out of touch"? Certainly, and, I suppose if Mr. Zakas' post were geared toward those engineers alone, we might not have anything to discuss. Note, however, that Mr. Hinssen's post discusses the prevailing attitude. If we see "arrogance" and "hopelessly out of date" as the status quo, then I would posit that Mr. Zakas' advice to adjust our attitude addresses a symptom of the underlying problem without addressing any of the underlying issues.

In part, the prevailing attitude - that we are arrogant and out of touch - is our fault as software engineers. Whether we write software for the World Wide Web, smartphones, or desktops - we have, to some degree, failed to convey our value to the organization. Often we do speak a language of our own, and life would be much easier (from the perspective of those who see us as arrogant and out of touch) if we would just communicate more/better/the right way - if we would stop being so out of touch - if we would stop seeing ourselves as so valuable to the organization - after all, the contribution of an engineer is not that significant because "writing code is something that a lot of people do" (emphasis mine).

As a User Interface Engineer (or web developer, if you'd like), I often hear comments similar to this - comments about how someone's teenage relative can build a good web page. While there are, of course, prodigies, the amount of engineering that is required to create the best web page is significantly greater than the skill level held by general practitioners, as is the amount of engineering required to create the best software for other media. I would posit, therefore, that our challenge is not as much improving our soft skills (though every engineer I've met would benefit from such development), but rather conveying our value to the organization in a meaningful way. To that end, as a counterpoint to Mr. Zakas, I would commend a quote that Baskin-Robbins used to hang in their stores: "there is hardly anything in the world that someone can't make a little worse and sell a little cheaper - and people who consider price alone are this man's lawful prey."¹ 

There are a number of issues that might be discussed when an organization perpetuates a culture similar to Mr. Zakas' comment above (that people who code are a commodity) or similar to those Mr. Hinssen references; however, one of the most significant is that organizations which learn to accept "close enough" when it's less expensive incur technical debt that becomes deadly. Further, the effect such an attitude has on morale within the IT department can be equally as deadly as mounting technical debt.

There is, in my estimation, another side to this story. In the face of significant potential issues, such as creating code that's "good enough" under one estimation and not another, mounting technical debt without having resources to address it, and demotivating personnel, there is also the thought that perhaps the perception of engineers as weak in soft skills, arrogant, and out of touch, is mistaken. Perhaps, just perhaps, those engineers are instead are significantly different than other employees.

Perhaps these engineers are not arrogant and out of touch. Perhaps there are weaknesses related to their soft skills, but if we, instead of operating from the assumption that what these engineers do is something that a lot of people can do, operate from the assumption that what these engineers do is something that few people can do, and that they are therefore in a different realm than others, might we see their "arrogance" as an indication they have a different understanding of their capabilities and the situation? Might the perception that they are "out of touch" be due to the manner in which they, in their different world, relate to those outside  of their area of expertise.

Let us consider then, the possibility that their "arrogance" and being "out of touch" are, at worst, simple weaknesses in their soft skills. What is the best advice? Certainly Mr. Zakas' advice is good, and traditional - work on your weaknesses. However, is that really the best way in which these engineers can contribute? In this consideration, I would offer the following advice that Dr. Donald Clifton gave his son: "your weaknesses will never develop while your strengths will develop infinitely."²

Let me be clear - the best advice the creator of the Clifton StrengthsFinder, Gallup's own online psychological assessment, could offer his son, was to build his life and work around his strengths rather than try to fix his weaknesses. For Dr. Clifton's son, and many engineers, Mr. Zakas' words, and in fact the words of those who brand us as "arrogant" and "out of touch" would have them "fix their weaknesses".

In this, I would posit that rather than engineers spending time fixing their weaknesses, that they spend time using and developing their strengths, and that management (at all levels) spend time seeing and celebrating diversity and the value it brings. I understand this is unconventional wisdom, but perhaps, just perhaps, this is a new age - an age in which each of us can contribute to our fullest.

What kind of engineer do I want to be? One that develops my strengths infinitely.

1. This quote is attributed to John Ruskin, though there is some debate about whether or not that attribution is valid.
2. Reported in a post by his son.

Know when to say "that'd be worth a whoopin'" (Robert's Rule #22)

In my family history, the tale is told of one particularly mischievous child who, after considering the possible consequences of a specific action would say "I believe that'd be worth a whoopin'" (a "whoopin", for those uninformed in southern American slang, is similar to a whipping but is given with anything close at hand - a belt, a switch, kitchen utensils, et cetera).

We are faced with decisions every day.  As technologists, the decisions that we face often have consequences which reach much further than those of other decisions. As leaders, one of the most cowardly things you can do, and one of the things that will destroy the morale of your team, is to try to deflect the consequences of your decisions, a technique commonly referred to as "throwing someone under the bus".

Make no mistake, there will be times in your career when your work, and life, will laud you for visionary thinking and there will be times when work, and life will punch you in the face, hard. Whether lauded or castigated, of one thing you can be sure, there will always be consequences.

While I know that most civilized people have moved beyond corporal punishment, my ancestor's concept still holds some validity, even when the 'whoopin' is metaphorical. Consider your options and make your decision. Just know when to say "that'd be worth a whoopin'" (Robert's Rule #22).

Trust everyone at the table, but cut the cards anyway (Robert's Rule #18)

[Tweeted 2011-06-06]

Living in an area where there are multiple casinos within a short drive or a long walk, I've learned to see some things using gaming metaphors. One of these metaphors is trust everyone at the table, but cut the cards anyway (Robert's Rule #18), and if you are an empiricist like Hume, then this rule will automatically make sense.

How does it apply to work? First, if you are not able to trust your colleagues, work (and probably life) will be miserable. Of course the reverse is also true; trusting your colleagues will go a long way in making work not be the worst part of your life. In fact, I've had some jobs I should have hated because they were such a poor fit and yet I didn't because of my colleagues.

Second, not only will the inability to trust your colleagues make life miserable, it will be very difficult to accomplish what you need to accomplish as well. The amount of time you spend countering the machinations of office politics in a hostile environment will outweigh whatever other successes you have. In addition, those times in which you don't succeed your discomfort will be worse because of the negative self-talk that comes out of the lack of trust and your assumptions about yourself.

Of course, this doesn't mean that you should just blindly trust. After all, your trust can be pretty easily misplaced, and this is your livelihood we're talking about here. You can't just go about willy-nilly assuming that everything your colleagues do and say is true, and even a series of lucky guesses ends sometime, which is a very good reason to confirm what you believe to be true.

Of course all of this is to say trust everyone at the table, but cut the cards anyway.

The convenience of electronic communication shouldn't enable you to treat another's time as if it's unimportant (Robert's Rule #13)

[Tweeted 2011-05-15]

If you're like me, you get bombarded with electronic communication, often to the point that it becomes difficult to disconnect. If I'm out of the office for a day, I can easily have nearly 300 emails in my work email inbox. If I add that to the 4 personal email accounts, Twitter feed, Facebook posts, Skype messages, SMS messages, phone calls, et cetera, it quickly becomes overwhelming. It becomes such a factor, that there are times that I do not respond to attempts to communicate.

If I choose to take myself offline for a period, people sometimes react with annoyance and I remind them that I maintain my email accounts and pay my cell phone bill because I intend for those things to make my life more convenient. However, all of that is from my perspective, and others that I have talked to say the same thing (aside from the snarky bit about it being for their convenience...that's all me).

So, we all feeling the pressure, but we're doing it to each other. I don't want to feel overwhelmed by my 300 emails (plus everything else) every day, but I can't stop sending out emails, or Tweeting, or sending that SMS to someone.

So I can see that we have a volume issue to deal with, but maybe it's not just the volume. After all, reading 300 work emails feels different than 100 tweets, 100 status updates, and 10 Skype conversations. Why? Because they're important and urgent. Whatever the problem is, it (at least in the mind of the email author) needs to be addressed as soon as possible. Therein lies the larger problem. Volume is still an issue, but the other kind of volume...the volume with which the message is conveyed is also an issue, because the meta-communication is what you think is important is not as important as what I think is important, in other words, your time is not as important as mine.

Of course that's not true; everyone's time is valuable. Coming to this realization led me to another rule: the convenience of electronic communication shouldn't enable you to treat another's time as if it's unimportant (Robert's Rule #13). Think of it as a variant of what, in American culture, is called the Golden Rule and maybe, just maybe, people will enjoy talking to you a little more.

You are not your job, you are a person (Robert's Rule #8)

[Tweeted 2011-05-04]

Like many people, I get asked "what do you do" quite often. At times it's been rather difficult to explain to people who "don't get" computers. In fact, one person went so far as to say I didn't really work because I didn't "make" anything. It took me a while to determine that, in his mind, unless you contribute to the production of a physical item in a meaningful way, you aren't really working and you shouldn't get paid. Thankfully, there have never been very many in my circles who have held the same belief.

Another problem I've had in responding to the question is until recently "what do you do" has been a little vague, or imprecise, rather because I've always done several things simultaneously. When I started out in the industry, I was an "Installer". As an Installer, I traveled a region and installed payment systems, trained the users, performed any troubleshooting required, made sure the customers had the supplies they needed, wrote customer service utility software, et cetera, et cetera. After I moved on from that job to client/server development and became a "Systems Programmer". However, 'programmer' jobs were usually more analysis and design than actual development, and then added to that were DBA duties, managerial duties, et cetera, et cetera. When I moved from the client/server environment to the web and became a "ColdFusion Developer" or a "Web Developer", it generally didn't reduce the scope of work much as there were design duties, development duties, network/server administration duties, DBA duties, et cetera, et cetera. Basically, there generally has been more 'et cetera' than distinct role duties.

All of this poses a problem more for existentialists than essentialists, I suppose, so perhaps it's only a problem because of my perspective, but perhaps not

I guess you might say at certain points in my past I've been an Installer-Trainer-CS Representative-Field Engineer-Programmer or Systems Programmer-Data Analyst-DBA-User Interface Designer-Technical Writer-Manager or System Administrator-Web Server Administrator-Programmer-DBA-Web Developer-Web Designer. All of that sounds really complicated and imprecise simultaneously. Besides, I noticed that any time I've been 'between jobs' I've never stopped 'being', so a change in perspective was required and I came to the startling revelation that you are not your job, you are a person (Robert's Rule #8).

As a result, when people ask "what do you do" I no longer respond "I'm a [insert title here]", I generally clarify whether they inquiring in what capacity I'm employed or if they mean something else. If they're inquiring about my work, I say "the majority of my work is as a [insert title here]"; if they mean something else, then I answer their real question to the best of my ability.

There are a few side-effects that I've noticed when verbally recognizing this small truth. First, people generally take a moment to consider what they're asking, which tends to move the conversation quickly out of the in-one-ear-out-the-other chat (that drives me mad) into a realm of real conversation. The second side-effect that I've noticed is that I feel more free to balance work and non-work life. For example, the majority of my "outside-the-home work" may be as a system administrator and that may entail thwarting network attacks, but the majority of my "inside-the-home work" is as a husband and father and in both inside and outside the home I am a person. That means, for example, that there are some meetings I don't take (such as those scheduled during my daughter's bedtime when I'm supposed to be reading her a story or singing a lullaby) and some job opportunities I will never pursue (because they would require me to sacrifice some portion of my humanity).

As far as I can tell, we all have only one life to live. At the end of mine I hope that my wife and daughter say "he was a good man"...anything else just won't do.

Ethical conflicts are like the TARDIS (Robert's Rule #7)

[Tweeted 2011-05-03]

One of the things that system theory gives us is a self-reinforcing loop. Granted, systems theory isn't the only thing that contains this concept; however, its centrality to systems theory is significant.


One of the fables that I have enjoyed over the years goes a little something like this.... Once upon a time a thief was being pursued by the authorities. In his haste to evade capture, he dashed into a temple and donned the robes of a holy man. The authorities entered the temple to find a man in the robes of a holy man and asked if he had seen the thief they were pursuing. He assured them he had not. However, in order to continue to evade capture he had to continue to play the role of the holy man. After many years, a severe drought fell upon the land and the ancient scriptures said only the sacrifice of a holy man could end the drought. In his final act in the role of the holy man, the thief sacrificed himself. As he lay dying, rain began to fall.


We all know examples of little actions that grow into larger, more important actions. The most common example of this is deception. To maintain deception ever larger deceptions are required; they are the ultimate pyramid scheme. This is why most advisers caution against something even as small as padding your resume.


Once, while interviewing candidates for my employer, I was given the task of assessing technical abilities in web languages. All candidates had been pre-screened by telephone and resumes had been reviewed, so by the time the candidates arrived, we were confident in presenting several problems so that we could observe and assess their abilities. I should say that I find this task pretty meaningless in many cases. With the advent of online resources and the tendency of the development community to share resources and experiences, a few minutes of searching can answer most questions. Because of this, I also tend to be very lenient in my assessments and somewhat laid-back in approach.


However, in one instance, I presented the problem (in written form) and the candidate immediately handed the problem back to me saying "I can't do this". After 10 minutes of me encouraging him to attempt an answer, even if he was not confident of the result, he continued to refuse.


I have to add here that one thing we don't tell candidates is that if we believe that they are not qualified for the position they are seeking they may still be qualified for other positions in the company, and we may adjust the interview to determine if they are a fit for a different position.


The candidate I was interviewing was likely qualified for a different position; however, it was plain to see that he had been deceptive with his resume and during the pre-screen. It was a small thing, really, to say "yes, I can do that" when really he couldn't. The problem was that saying "yes, I can do that" when he clearly knew that he couldn't, blocked him from progressing further with that employer. Completely.


Simple, but difficult, especially when there's so much on the line. Now he's just one more example that helps me keep in mind Robert's Rule #7 -- the first ethical conflict is usually so small it appears minor and so large it becomes a major career factor, and the candidate will continue to work for small start-ups, never really progressing to the next level.