I have been using Hacker Rank for a month or so to get a feel for it. I know that some companies use it as part of their interview process so it seemed like a good idea to get familiar with it.

I like the site and think the problems are fair, challenging, and can help you to hone your development skills. That being said, a friend had me go through their version of the test they give as part of their interviewing process. I stunk at it. The problem was the timed nature of the process. When solving a Hacker Rank problem in the context of using the regular site, you can explore options, refine your code and algorithms, and have the opportunity to change directions if you start down the wrong path. In the timed interview, this just doesn’t work. I went down the wrong path on the first problem and never really recovered. It wasn’t that the problem was hard, I eventually solved it, it’s just that I thought I could do it using one data structure and then when that wasn’t working I switched to another. That just put added time pressure on the rest of the problems and I made a bad assumption on another problem that pretty much sunk the rest of my “interview.”

I understand, if not like, the need to look for a baseline of programming ability, but feel like tests like these don’t mimic a work environment in a meaningful way that reflects any candidates ability to do the job.

What this and Developer Hegemony highlight to me is the very real need to make myself something other than a “corporate resource.”

Developer Hegemony

If you are a software developer working at any size company buy “Developer Hegemony”. It explores the way companies treat software developer today and how we stereotypically react to that treatment. It clearly argues that we are treated as glorified line-workers and that we need to move to a model where we are treated like doctors or lawyers with independent practices.

For a long time I’ve called my job a “grind” and that even if I went to a “better” company it would still be a “grind.” Developer Hegemony helped me figure out exactly why I’ve felt this way and although the way out is non-trivial I know that it’s the only way to bring joy back into software development for me.

Don't Put Your Async in My Serverless

A lot of the constructs of Node and modern JavaScript are about handling the asynchronous nature of web server/browser interactions. In a serverless world, single threaded execution is ideal and asynchronous code is problematic. While the title of the linked article (“Node is the WRONG runtime for serverless”) is sensationalist, as the author admits, the article argues Python is a better fit in a serverless world.

I was planning on implementing a project using AWS CodeStar starting from an Express template and porting an existing Express application. I then evaluated the code based on this article and found that I’m using promises for the database interactions. As the author notes, this shouldn’t be a deal killer, but I do need to be aware that using many of the asynchronous patterns common to Node and JavaScript server applications is unlikely to be beneficial in a serverless architecture and harmful from the perspective of unnecessary code complexity.

Serverless development feels like Java in 1998. It has been around for a little while, is gaining traction, but there are still some sceptics. The skepticism around Java was the hype around write-once-run-anywhere. I think that caution was appropriate, but the ideal of a virtual machine that could be deployed on almost any platform to run the same non-GUI code became a big deal.

The big idea around serverless is the reduction of operational costs around deploying an application. The cost of maintaining even virtual machines is tremendous compared to an environment where the code is the only thing to maintain. Just like the vision for Java in 1998 didn’t turn out exactly as people were hyping it; I don’t think we know what serverless will look like in 20 years, but I’m betting it will a significant impact.

In the short time I’ve been working with AWS Lambda and other AWS managed services, I can see the norm for server side development moving away from placing software on even virtualized machines. Programming models that abstract out the notion of a host OS seem like a no-brainer at this point. The reduced cost of maintenance and operation in a serverless environment seems like it would be a win for any type of back-end development.

That being said working for a company that primary tracks and optimizes software and hardware assets in an on-premise environment feels like an uncomfortable to be. Of course, on-premise software and hardware won’t go away, just be reduced in size and percentage of importance. Can a company that is entrenched in the on-premise model morph itself into something that can adapt to this new world and combine and optimize the serverless and on-premise mixed model. That’s the question.