If Carpenters Were Hired Like Programmers

Standard

Programmers often experience a high degree of frustration during the interview process. The thing I’ve always found funny about job interviews is that they’re always “looking for candidates who can hit the ground running,” so they’ll reject anyone missing one out of the ten required buzzwords.

I recently stumbled on two articles with an identical theme; “If Carpenters Were Hired Like Programmers” and “What If Cars Were Rented Like We Hire Programmers”.  The tl;dr of these posts is essentially that programmers being interviewed are asked incredibly esoteric questions or are grilled about experience with irrelevant topics (wood color for carpenters, car wiring for car renters).  The comments sections on Reddit (link below)  and Hacker News(links below) are a mix of agreement, criticism, and various anecdotes about interviews that reflected the articles’ theme.  No analogy is perfect.

Programming is a business, technical and specialist skill, it’s perfectly normal to expect senior roles to have previous specialist experience in a particular framework or tool. And it’s important for us as a tech community to recognize that, and understand how that will affect our projects and our businesses.

It’s generally true that a good developer’s main skill is problem-solving, and a good developer will generally be able to pick up a new framework or language fairly easily. But a good developer in framework X will probably not be able to join a project and hit the ground running in framework Y. They will usually need support, co-workers who are more knowledgeable in that framework, and time. How much time? Six months to a year isn’t an unreasonably short time, even for an otherwise expert developer.

There are naturally exceptions. If a company is recruiting for a junior role, specialist knowledge probably matters a lot less. If a company is recruiting for a long-term permanent position, they can often afford the time for a great developer to learn a new specialty. So for some roles, it’s unimportant, but it’s not an unreasonable point to discuss. And technical development is neither carpentry, nor hiring a car, nor any of the other many flawed analogies.

Related links:

 

Advertisements

History of OpenText

Standard

The OpenText ECM Suite integrates multiple technologies for document management, records management, web content management, digital asset management, email management and information lifecycle management. Other components include electronic discovery, document capture, document imaging and digital faxing solutions. The suite provides functions for team collaboration, forums, blogs, wikis, and real-time instant messaging and collaboration. These functions are connected through business process management tools to each other and to other business applications and processes.

OpenText originated in 1991 as a small three-person consulting operation. The company was a spin-off of a University of Waterloo project that developed technology used to index the Oxford English Dictionary. In partnership with colleagues from Oxford University, participants in the project included two professors of Computer Science, Dr. Frank Tompa and Dr. Gaston Gonnet, along with their Faculty of Arts colleague, John Stubbs. Later founders of the business application of the technology developed during the course of this project include Tom Jenkins, who joined the company as COO in 1994 and Tim Bray. Tom Jenkins later became President and Chief Executive Officer. Today, John Shackleton serves as CEO of OpenText, and Tom Jenkins as Executive Chairman and Chief Strategy Officer.

Visit the following link to read the complete history of OpenText.