The source of this post in my brain started when I stumbled upon an article tonight entitled “Front-end Job Interview Questions“. The absurdly long list of questions in the article is exactly the kind of questions that you should NOT ask. Ever.

All these questions do is scream, “I’m an egomaniac who has spent vast amounts of time Googling this nearly useless knowledge, but will ask you to regurgitate it to me without the aid of a search engine, and then judge you on how much it makes you sweat.”

Look, I get it. We’re geeks, and without some basic training and/or experience, we think that everyone should have an encyclopedic knowledge of our most treasured technologies and tools. However, even if a candidate does somehow have this knowledge miraculously stored in their memory, it doesn’t mean squat.

Think about the best group of people you’ve ever worked with. Then think about the biggest jerks, assholes, social misfits, and douchebags that you’ve had to endure over the years. Did their level of technical knowledge ever matter when you determined their value as a team member? Of course not.

Some of the most technically talented people I’ve ever worked with just so happened to be colossal jackasses that I could have invited over for dinner, fed them their own brains, and then gone to sleep with a smile on my face. Conversely, I’ve worked with people who were adequate with technology, but also managed to be great, passionate people and invaluable teammates that I would work with again in a heartbeat.

I was fortunate enough to work with a fantastic group of people when I was at DaVita. As it is with most IT shops, there were many layers of innate technical talent on the team. Some people had to put in that extra couple of hours to achieve the same results as someone else who had it come naturally.

We had a contractor once whose brain thought in Oracle. He could tweak performance and results out of queries and other aspects of the database that I couldn’t achieve in a lifetime of study. He also had an incredibly helpful and passionate way of dealing with others, and when he left the company we all felt that we had lost not only a great asset, but a friend.

When I joined the company, and then we started hiring other front-end developers to join me, I had a two pronged approach to interviewing. First, a five question technical quiz that filtered out the inexperienced. It doesn’t take 50 questions to determine if someone has the chops or not.

If they performed adequately at that, there was a face-to-face interview at which I had three additional scripted questions. They are meant to start a conversation, not test a candidate on how much they’ve crammed into their short-term memory from Google in the past week preparing for your onslaught.

1. Why do you want to work for us?
2. What is the one trait that you have that you believe will benefit your teammates here?
3. What is your passion in life?

If someone proves that they have the bare minimum of technical prowess, then all that’s left is determining if the candidate is (a) a smart and critical thinker, (b) passionate about anything, and (c) bringing anything of value to the team.

The dirty little secret that I don’t mind saying is that software development isn’t hard. There’s lots of handbooks, manuals, blog entries and Stack Overflow Q&A pages out there that very clearly describe how to work with any development language or tool. Follow it step by step and you are a software developer. However, keep in mind that it is also very easy to hold a paintbrush in your hand, and swirl oil based paint on a canvas. Unfortunately, Rembrandts and Degas only come around every once in a while. The mechanics of software development are easy to learn, but incredibly difficult to master.

The real issue is that hardly anyone has the disposition to be a software developer. The mind numbing attention to detail. The absurd amount of time it takes to debug the simplest of issues. The complete and utter need for total concentration for hours upon end in order to complete the basic tasks of the trade. In short, the passion for developing software.

Not many people are wired this way. The ones that aren’t, but are in the field anyway, are very easy to pick out. All it takes is a 20 minute conversation about anything but technical minutiae.

Update – This silly article I wrote at 1 a.m. last night before I fell asleep has certainly touched a nerve (either positive or negative) with a lot of people. Let me clarify one thing that many readers seem to have misinterpreted. The point of my three seemingly non-technical questions asked in a face-to-face are meant to lead to a discussion about technical issues. Yes, some people will throw bullshit at you, and if you can’t detect the bullshitters, then you shouldn’t be interviewing people.

It’s really that simple. Google can only collect information about me that I share. If they somehow glean the fact that I like expensive wrist watches because I visit a website about expensive wrist watches at least once a week, or I exchanged 10 emails from a friend titled “EXPENSIVE WRIST WATCHES, YO!”… um, I’m ok with that.

Perhaps people operate under the “out of sight, out of mind” policy when signing up for commercial products and services, even if they are “free”. Google has always collected information about their users, have always been up front about the fact that they collect information about their users. I’ve never had a problem with that. Perhaps Google coming out with this new, cleaner, more easily understood policy simply brings that fact to the forefront of people’s minds, and then all of a sudden they are offended by the fact that Google collects information about their users.

That’s weird.

Recent reading:
Windows 8’s Metro UI Isn’t Very Good Without Touch, But That Doesn’t Really Matter

Windows 8 Metro: Now with mouse support

Further reading: Ars Technica | Adobe Acquires Nitobi

Flash is back to being just Flash

Adobe Flash lost as a web application development standard, and Adobe knows it. They are spending tons of cash right now in a game of catch-up and expect to be the leader in web development again (they were just a short 5 years ago). After their initial, bitter battle with Apple and running Flash apps on iOS, they turned things around and you can now use Adobe tools to deploy apps on iOS. They already released a beta of a complete IDE for building HTML5/JavaScript5/CSS3 applications. It’s called Adobe Edge.

Adobe PhoneGap

With the power and capabilities of Edge growing with every release (because their customers are demanding it) it is most likely that PhoneGap will be tightly integrated as the de facto framework for building applications in the tool. Much like when Appcelerator purchased the Aptana IDE and converted it into Titanium Studio which allows us to code, build and deploy applications from one tool, Adobe Edge will be a complete IDE for HTML/JS/CSS application development.

Further reading: CNET | Adobe Sharpens Edge

Desktop

Now, if you are building desktop apps, PhoneGap is not an option because it is exclusively mobile. It’s the main reason that Titanium Desktop became so successful. Unfortunately, Titanium Desktop seems to be an abandoned, or at least orphaned, child in the Appcelerator roadmap. The few Appcelerator employees that I talked to at the conference two weeks ago did not have any answers as to how their desktop product fit into their future plans. They are currently focused 100% on their mobile application development tools. This is most likely because Appcelerator is resource strapped and simply giving all of its focus to what customers are demanding RIGHT NOW.

Adobe has no such limitations. Their AIR Runtime already allows developers to build HTML/JavaScript applications that can run on any desktop OS. Unfortunately, it could not run on every mobile OS, so it will most likely be abandoned and replaced with the eventual PhoneGap successor for mobile apps. I don’t see Adobe abandoning the desktop because they already have a dedicated presence there, and with the (finally) released information about the Microsoft Windows WinRT API in which you can author complete applications with JavaScript, it plays right into the hands of Adobe.

It’s highly probable that Adobe Edge has AIR integration for desktop applications before the official 1.0 release.

One Source

So what this gives us is more than one option for every environment. The source code for the GUI would continue to be in one language, but then could be built, or interpreted, to any platform. It will be interesting to see what Adobe does with the PhoneGap platform in the next year.

JavaScript

1. WinRT for Windows applications
2. Adobe AIR for Windows/OSX/Linux applications
3. PhoneGap for mobile web apps with native capabilities
4. Titanium for desktop and true, native mobile apps (and now web apps)

I find it interesting when I talk to developers who are focused on Java and .NET platforms about how JavaScript will soon replace a huge chunk of what they currently have to do when making applications with a user interface. I would think it would be a source of jubilation – no more worrying about cross-platform UI issues in compiled code – but I find there’s still a lot of resistance and denial even though the facts are all right in front of us.

This next generation of application development is going to be fun, not only because we can reduce the amount of code we need to write, but also because the entire industry is moving away from the immobile desktop and towards the mobile device platform.

This is a modification to the code found at a blog called Code Bytes. Unfortunately, I can’t credit the developer by name because nowhere on the blog does he/she actually provide a name or bio.

This was developed for version 1.1 of the Titanium framework. If you are using a later version, this may have been fixed.

/*
 * This code augments the Titanium framework code by detecting any element that has the
 * 'isDraggable' class assigned to it.  If that element is dragged, the entire window
 * is dragged correspondingly.  Also, only works on left-mouse click.
 */
var isDraggableWindow = function() {
    this.addEventListener('mousedown', function (e){
        function drag(e) {
            var currentWindow = Titanium.UI.currentWindow;
            var currentPosition = {x:currentWindow.getX(), y:currentWindow.getY()};

            currentPosition.x += e.clientX - mousePosition.x;
            currentPosition.y += e.clientY - mousePosition.y;

            currentWindow.moveTo(currentPosition.x, currentPosition.y);
        };

        if (e.button === 0 && ~e.target.className.indexOf('isDraggable')) {
            var mousePosition = {x:event.clientX, y:event.clientY};

            document.addEventListener('mousemove', drag, false);
            document.addEventListener('mouseup', function (e){
                document.removeEventListener('mousemove', drag, false);
                document.removeEventListener('mouseup', arguments.callee, false);
            }, false);

        }
    }, false);
};

// Then in your main module/application, you simply pass the ID of the top-level element
isDraggableWindow.call(document.getElementById('topLevelHTMLElementInApp'));

We added the following restrictions to the original code.

1. Only works on left-mouse click.
2. Only elements that have been assigned the ‘isDraggable’ CSS class will trigger window drag. This class doesn’t actually have to exist – it just needs to be added to the HTMLElement. Without this restriction, clicking on ANYTHING in the app and dragging will move the window.

Event Link: AMD and CommonJS modules

On October 11th, we’ll be covering Appcelerator’s Titanium framework which is an open-source framework that allows you write an application in JavaScript and then build native apps for iOS and Android (and Blackberry soon). You can also deploy the application to the desktop – whether it be Windows, OSX or Linux. One source code library to deploy to 6 platforms!

Event Link: Appcelerator Titanium Framework

On October 25th, we’ll be discussing how to build a JavaScript application and deploy it in the Adobe AIR runtime. With Adobe AIR, JavaScript developers can use their existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web.

Event Link: JavaScript and the Adobe AIR runtime

Whatever the reason, if you want to make anything clickable, it’s very simple. Simply add the following listener.

id    : 'myLabel',
xtype : 'label',
html  : '<div class="myHelpLabel"></div>',
listeners : {
    render : function(c) {
        c.getEl().on('click', function(){ this.fireEvent('click'); }, c);
    }
}

Poof. Now you can detect when that element is clicked in your controller (if you’re using the Sencha MVC architecture).

init: function(){
    this.control({
        'sampleView #myHelpLabel' : {
            click : function(c) {
                // Do something brilliant
            }
        },
        ...

Now that I no longer work at DaVita and for Smith Micro, the company, while it doesn’t embrace social media, certainly isn’t completely ignorant of its power and possibilities. In a recent issue of Harvard Business Review, I very much enjoyed reading an article with interviews from senior people at large companies discussing how they are handling the social media beast.

Yes, all of them mentioned how security and leaking is an issue, but the companies who made online expression part of their corporate culture – rather than blocking all possible access by every employee – found that their teams went out of their way to responsibly share information when communicating online.

DaVita was a great company at managing, nurturing and supporting the local social interactions of people all across the company, but seemed clueless when it came to the online extension of those relationships.

I wonder how many companies out there are truly making an effort to embrace the future rather than sticking their heads in the sand and pretending that the change isn’t happening. Of course, there are some organization that simply cannot risk their teams having the ability to share information online while they are work – I understand that. However, it also appears that some companies hide behind this visage of “oh we’re working on far too important stuff to risk some stupid employee telling everyone about it” when they manufacture paper clips, or build medical devices, when the truth is that they simply don’t understand how to manage it.

Fear and ignorance are powerful motivators.

When jQuery Attacks!

Well, when I hooked up my laptop and fired up my VMWare instance of Ubuntu, it failed to get an IP address from the DHCP server, so all my “hard” work was for naught. Therefore, I’m simply going to share my code with everyone and have you run it yourself, and anyone else in your office that can hit your machine.

Real-time Communication With Now.js

Now.js is one of the most exciting Node modules I’ve run across. You can hit their website to read more, but this is how they describe what it does.

• NowJS creates a magic namespace “now”, accessible by server and client
• Functions and variables added to now are automatically synced, in real-time
• Call client functions from the server and server functions from client

I have to admit, when I first hit the site, I was thinking, “Yeah, right.” Luckily my healthy skepticism was immediately dashed as I ran their example, and it worked! Without the need to change system settings, or add in a bunch of hoodoo-voodoo code somewhere else to make it look like real-time communication.

Anyway, go to their site, read up on it, and after you’ve run through their examples, come back here and grab my Beer Drinkers & Hell Raisers code from my Github account.

In there is three files, but you only need chat_server.js and beerdrinker.html.

The only modification you need to make is on line 22 of beerdrinker.html where you place the IP address of the machine that has Node running.

<script src="http://{insert IP addy here}:8081/nowjs/now.js"></script>

Now, technically, there’s more than 40 lines of code when you count all the HTML and additional Node code I have in there to enable the file serving… BUT the code that makes my cheesy beer drinking game work is 39 lines of code (amazingly, only 8 lines at the server!).

Once you clone the repo locally, simply execute -

node chat_server.js

And then have your friends hit http://your.ip.address/beerdrinker.html. All you need to do is -

1. Enter your name in the input field and click Register
2. Once everyone is registered, have fun seeing who can drink everyone else under the table.