Skip to main content

Reverse Interview Code Testing

I've often said that live code tests are bullshit that tell nothing about coding ability and stand by that assessment, today I was thinking about a way that one can mount a challenge to a company that has formalized a "live coding exercise" as part of its process.

It goes like this, if you are told that a company you are interviewing with wants you to take a live coding test then you should tell them "I don't take live coding tests but if you wish to divine if my engineering skill is on the level of those in your team, I can give you a sample of code I've written and if you can't tell the engineering context and use for that code by inspecting it, I will have achieved necessary credits to be invalidated from taking the live coding exercise."

The reason this reverse test is valid is the premise of what is really being interviewed for when hiring software developers. It is not knowledge in real time of any given programming data structures or algorithms it is more about eventual ability to wield such structures to solves difficult application problems. That is what engineering is all about, completion time is only important on long scales not down to the minute scales for such solutions.

So if the context of those larger problems can be inferred from the code it usually indicates a very atomic solution (one that runs on a single machine or doesn't span a complex and dynamic execution environment that is networked) this is really the EASY type of crap that is often tested for in live coding exercises but tells nothing about *engineering* which tends to invisibly span across different bits of code and brings to life the efficiency of a distributed solution.

So I'd challenge my interlocutor to decipher the engineering purpose of a bit of my code...at method level show a class implementation and ask what it does globally? Or a bit easier depending on your POV show them an entire class and let them infer how the larger system uses it simply from that class code alone. If they can do that from the code in one of my projects then they have demonstrated exceeding me in the engineering ability that THEY should be looking for without needing to do any further testing and I'd acquiesce and remove my candidacy for their position.

If they continue to harp that the "live coding test" is mandatory and can't be substituted then they've demonstrated that they are not looking for engineers properly and likely have a set of unskilled programmers that I would not find it very fun to work with in the first place and thus remove my interest on those grounds...win, win.

I haven't used this tactic yet on an interview but I am thinking of doing it the next time I am asked to participate in a live coding exercise.

Comments

Unknown said…
Yes, coding tests can be a little boring. But the interviewee providing out-of-context code that can't be understood, as a mark of being better? Not sure about that one :)
Unknown said…
How will the company know you wrote it, not someone else?
Anonymous said…
I would never want to hire people who write obfuscated code. If anything, I would only hire someone whose code is easily readable. When working in a large team, this is one of the most important qualities for an engineer.
Anonymous said…
It would be a valid exercise if your code is readable, and a dialog ensues. Otherwise, any developer worth his salt should be able to decipher your code...it's how APIs are used...only a piece is exposed.

Popular posts from this blog

the attributes of web 3.0...

As the US economy continues to suffer the doldrums of stagnant investment in many industries, belt tightening budgets in many of the largest cities and continuous rounds of lay offs at some of the oldest of corporations, it is little comfort to those suffering through economic problems that what is happening now, has happened before. True, the severity of the downturn might have been different but the common factors of people and businesses being forced to do more with less is the theme of the times. Like environmental shocks to an ecosystem, stresses to the economic system lead to people hunkering down to last the storm, but it is instructive to realize that during the storm, all that idle time in the shelter affords people the ability to solve previous or existing problems. Likewise, economic downturns enable enterprising individuals and corporations the ability to make bold decisions with regard to marketing , sales or product focus that can lead to incredible gains as the economic

How many cofactors for inducing expression of every cell type?

Another revolution in iPSC technology announced: "Also known as iPS cells, these cells can become virtually any cell type in the human body -- just like embryonic stem cells. Then last year, Gladstone Senior Investigator Sheng Ding, PhD, announced that he had used a combination of small molecules and genetic factors to transform skin cells directly into neural stem cells. Today, Dr. Huang takes a new tack by using one genetic factor -- Sox2 -- to directly reprogram one cell type into another without reverting to the pluripotent state." -- So the method invented by Yamanaka is now refined to rely only 1 cofactor and b) directly generate the target cell type from the source cell type (skin to neuron) without the stem like intermediate stage.  It also mentions that oncogenic triggering was eliminated in their testing. Now comparative methods can be used to discover other types...the question is..is Sox2 critical for all types? It may be that skin to neuron relies on Sox2

AgilEntity Architecture: Action Oriented Workflow

Permissions, fine grained versus management headache The usual method for determining which users can perform a given function on a given object in a managed system, employs providing those Users with specific access rights via the use of permissions. Often these permissions are also able to be granted to collections called Groups, to which Users are added. The combination of Permissions and Groups provides the ability to provide as atomic a dissemination of rights across the User space as possible. However, this granularity comes at the price of reduced efficiency for managing the created permissions and more importantly the Groups that collect Users designated to perform sets of actions. Essentially the Groups serve as access control lists in many systems, which for the variable and often changing environment of business applications means a need to constantly update the ACL’s (groups) in order to add or remove individuals based on their ability to perform cert