Why Digital Talent Doesn’t Want To Work At Your Company | Fast Company

I like this blog post so much that I am re-posting it in it's entirety.


Why Digital Talent Doesn’t Want To Work At Your Company | Fast Company:

Why doesn't digital talent want to work at your company? It’s not because you’re a consumer packaged goods company, rather than Google. It’s not because you’re in Ohio instead of Silicon Valley. It’s not because your salaries are too low, or because you don’t offer free food and laundry services.

It’s because you’re not providing them the right opportunity. The talent you want would be happy to work in an un-air-conditioned garage in New Mexico if it meant the chance to change the world.

This, the opportunity to do great things, to make a real difference, is what drives most digital talent--whether they’re developers, designers, producers, marketers or business folks. 

Most companies don’t offer this, so they skip your company and work somewhere that’s more innovative and exciting. End of story. But the good news is that you can offer them something exciting and great. The promise of changing a giant, behind-the-times organization into an Internet-savvy business is an incredibly exciting challenge and a big way for ambitious people to make an impact.  

But it takes more than lip service to make the sale. Job candidates and new hires with digital chops must truly believe in the company’s dedication to digital transformation and they must see that they are empowered to make this change. Trouble is, many big businesses aren’t structured to deliver on this type of opportunity. The attributes of a soul-crushing, Sisyphean, anti-digital workplace run deep.  

Digital talent won’t want to work at your company if:  

• Every element of their work will be pored over by multiple layers of bureaucracy. Even if that’s how the rest of the company operates, it can’t spill into the digital department. In a technology environment, new products and businesses spring up daily and a new endeavor can go from conception to launch in a matter of months. Reining in the momentum will be read as inaction and a clear signal the company isn’t willing to grasp the new way of the world.  
• Mediocre is good enough. While clocking out at 5 p.m. is attractive to some, it will discourage digital talent. They want to be expected to do something great. They want to be pushed. They care about their work. Their leadership, and those they rely on to get things done, must match their appetite for success.   
• Trial and error is condemned. The freedom to try out new ideas allows employees to take initiative, make decisions, and learn from their mistakes. It also demonstrates an attractive and inspiring entrepreneurial spirit.
• Your company is structured so it takes a lifetime to get to the top, and as such there are no digital experts in company-wide leadership positions.Digital talent--often in their 20s and 30s--need to see a clear path for uninhibited career development that’s based on merit, not years spent, and that’s beyond the confines of the digital department. If they don’t, they won’t see a reason to stay with the company in the long term.  
• Your offices are cold, impersonal and downright stodgy. It may sound like it conflicts with the “you don’t need to be in Silicon Valley point,” but appreciate the nuance. A traditional office layout is designed to communicate power among certain individuals and barriers between departments. This does not support the collaborative ethos which is intrinsic to the web. Companies should do everything possible to provide the digital team friendlier, open office space. A location in a hip, young neighborhood (which surely exists in every mid- to large-sized city) is also a big plus.  

When all of these digital-talent deterring points are addressed, company leadership has effectively and proactively demonstrated the company’s dedication to a digital transformation. It is at this time that their words, a broadly communicated firm stance on the significance of the company’s digital goals, will make the most impact. Without this conspicuous top-down support, politics in the organization or simply one influential disbeliever can hinder the effort, limit the extent of digital integration possible, and discourage valuable employees.  

You need them more than they need you. Demand for their services is so high, they can afford to be finicky. If they don’t like where they’re working, another firm with a more attractive culture and more grand opportunity will quickly swipe them up. That could be your company. But it could just as easily be someone else.

Adapted from Users Not Customers: Who Really Determines the Success of Your Business(Portfolio), by Aaron Shapiro, CEO of HUGE, a digital agency that helps companies including PespiCo, Comcast, Target, HBO, and Unilever reimagine how they interact with their customers and manage their business in the online economy. Visit aaronshapiro.com.

'via Blog this'

Are we dumbing down programming?

Her resume looked great. She was coming to us as a high end (price) developer. But as I listened to her describe an abstract class in response to my asking her about abstraction, I had to wonder; have we made it too easy to be a programmer?

It's true that abstraction is the most intangible concept of OOP. During my phone screens of candidates, though, I find myself wishing I had tipped them off. I will be asking about OOP. Go look up "object oriented programming" on wikipedia.

I generally blame our universities for this failure. OOP is largely conceptual, and should be introduced and reinforced by any Computer Science department worth their accreditation. Once in the workplace, software engineers rarely get the proper mentoring on solid coding habits.

We really can't lay blame entirely on universities and trade schools. No, much of the problem lies with the technologies we use to build applications. High on the list of offenders are Visual Basic, Visual Studio, Java, and .Net. Throw in HTML, XHTML, XML, and all the mark-up language derivatives. Then add in any of the web development tools like Cold Fusion and Flash. Of course the scripting languages, JavaScript, VBScript, and Perl virtually prevent solid coding practices.

My obsession with OOP stems from a very specific business need. I have to support ten software products with a very modest staff. The most basic way to accomplish this is by reducing the amount of code. An obvious way to reduce code is reusing code. Unfortunately I inherited a situation based on copy-and-paste code. After three years of fighting copy-and-paste habits, we still support multiple versions of code that perform the same task.

Many developers confuse using objects with OOP. Dropping a control onto a form does not constitute object oriented programming. In fact, there will be nothing reusable in the result. In addition, the automatically generated code written by the action of dropping the control is almost certainly unreadable. But then, many developers today don't even realize code is being generated.

So our tools have dumbed down programming skills. Especially for those developers who rely on the designers and tools built into their development environments (IDE). For me, I'd like to find an engineer or two who would love to create the next Visual Studio, instead of dragging controls from a toolbar like some pre-programmed automaton.

What happened to OOP?

When recruiting engineers I always start with a discussion on object oriented programming. I try not to completely surprise the candidate, so I always list the four topics: abstraction, encapsulation, polymorphism, and inheritance. Then I ask the candidate to define each term, and tell me how (and why) it is used in real world situations.

I have to admit that I am amazed at the percentage of developers who do not know the fundamentals of OOP. Even developers coming right out of school struggle with this conversation. This despite the fact that most of our entry level developers are coming out of Masters of Computer Science programs.

It has caused me to wonder if OOP is coming out of favor. If this is the case, then what is replacing it? Gang of four patterns? Something else?

You can say I am an old school developer. I learned to code when the style was structured programming. There was no concept of OOP when I earned my Computer Science degree. I was introduced to OOP several years later, when building my first applications for Windows. I immediately saw the maintain beauty of maintaining a single piece of reusable code, this was a logical extension of function libraries.

OOP was a natural evolution of structured programming, and yet I was amazed at the number of my colleagues that did not make the switch. And those who didn't were relegated to mainframe jobs and maintenance of legacy system. The best engineering opportunities were given to those who were evangelists of object oriented programming.

But as Internet development took off during the first dot com boom, a couple of trends started. One was the adoption of Visual Basic, and the other was design patterns from the gang of four (Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides).

In my mind, Visual Basic is and was a horrible trend in the practice of software development. The language, especially in its' early versions, encourage poor programming practices. And Microsoft's CASE style designer tools only exacerbated the problem. Departmental developers from corporations picked up the easy to learn language, and churned out applications that were impossible to maintain. Although recent versions of the Basic language implement OOP constructs, traditional VB developers generally do not use them.

Design patterns should have been an advancement in OOP development. In practical use, however, programmers often use patterns without practicing OOP themselves. Much the same way that procedural developers use Java or .Net and still fail to implement OOP.

The problem for me, as a manager and leader of engineering teams, is finding people who write code that is easy to maintain. To a degree, I equate maintainability with re-usability because code that is reused is not rewritten. And code that is reused is tested frequently. Coders that do not understand or practice disciplined OOP will fall into the copy-and-paste trap. When this happens, many versions of similar code appear throughout the source code, creating a maintenance nightmare.

The irony here is that descriptions of object oriented programming are very common. Wikipedia, for instance has an entry for OOP that a developer could review and understand in a couple of minutes. I hope too, that Computer Science programs strive to instill these basic concepts to their students. In the meantime I continue my search for solid OOP engineers who will help evolve our products.

Recruiting headaches; how not to get hired

I spend much of my time recruiting people for my technology teams. Currently we have openings for software engineers, QA Analysts, and a DBA. Thankfully I have corporate resources to post ads and review resumes. After candidates successfully navigate through HR, I do a short phone screen to gauge the candidate's ability to carry a conversation, and to match their knowledge with their experience (as it appears on paper).

I believe the best developers and testers have a strong academic knowledge of their profession. From this knowledge, good coding habits or solid testing methodology is learned. So my phone conversations always start with a discussion of fundamentals.

For software engineers, the conversation begins with a discussion of object oriented programming. Because I often catch candidate by surprise with this line of questioning, I always list the specific terms we will discuss. Abstraction, Encapsulation, Inheritance, and Polymorphism. I have been applying these concepts for nearly twenty years and expect every competent developer understands how they work in real world applications.

Of course some candidates can not describe OOP concepts. I usually give a lot of latitude on abstraction and encapsulation. These tend to be more conceptual than inheritance and polymorphism, which are implemented with specific language constructs. Imagine my surprise, though, when a candidate recently told me he did not know any of the terms.

When a candidate struggles with my OOP discussion, I try to give him some relief by asking him to define inheritance. Inheritance, after all, is fundamental to all modern programming and is easy to describe; simply define the word. But I was shocked when the candidate admitted that he did not know of inheritance.

This story should end right here, for at this point I politely ended my line of questioning and suggested that we did not have an appropriate "fit". The candidate, however, wasn't quite finished. He assured me that given proper requirements he could finish any project. Then he claimed that academic concepts weren't that important and if necessary he could easily look up the information he needed.

Of course he was wrong. A developer can not possibly build a class library or reusable object without understanding inheritance. In fact you can not write a meaningful Java, c++, or .Net application without inheriting an object. And you can not possibly know when to use an interface without understanding polymorphism. You can not implement objects without understanding encapsulation, and your objects will be a mess if you do not apply abstraction. Most of all, you can not hope to get hired into a position if downplay knowledge an interviewer deems important.
My quality assurance conversions cover testing methods in a similar manner as the OOP concepts. For QA, I have twelve types of tests that I expect a candidate to discuss. In the course of the discussion, I ask that the candidate describe how he applied each type of test in his experience.

I am guilty of acquiring my definitions of the tests from the web. I can't even remember where they came from, but we have a list of a few dozen QA terms. From this list I have flagged twelve to drill candidates. I always start by asking the candidate to describe Black Box Testing.

It was surprising when a recent candidate quoted the exact phrase "not based on any knowledge of internal design or code." Surprising because that phrase is an exact match of the definition on my sheet. I assumed this was a coincidence and continued.

But the next item was quoted exactly too. And the third, Unit Test was again quoted exactly, using the phrase "the most 'micro' scale of testing." Nobody talks like that. She could have at least used the word "smallest".

At this point I stopped her and asked what she was reading from. She denied reading the responses. I mentioned that I was reading my terms from a sheet that we had acquired long ago, and asked where she had gotten her material. I do not believe it is possible for anyone to have memorized those specific terms using such precise language. Again, she denied using reference material.

Generally speaking, I would not fault a person for using notes or reference material during a phone screen. But I expect they can show how an academic concept makes sense in real situations. I would also expect a person to acknowledge using reference material when it has become obvious to the interviewer. She had the opportunity to look resourceful, but instead looked like a cheat.

In both these cases, the candidate's resume looked great but they weren't a good fit for our team. These candidates simply didn't apply common sense to our conversation. Want to know how not to get hired? Simple, be unprepared, lie, or ridicule the interviewer's questions; it's guaranteed to keep you out of the position.