On Interview Coding Exercises...

03.21.2014 12:35 by kbeckman | Comments

That time of year has come again where my current client has committed to more development work than the existing team can complete by the promised launch date… [Sigh…] We’ve all been there. It’s the unfortunate, situation that occurs when months of work is spent on improper and misguided business priority. Startups and young companies get a pass here because their environment and focus changes rapidly as they’re still trying to figure out what works for their business.

 

But for a lot of companies, inevitably the day comes… SLAP! ..and a new or potential client sets a new priority for your team that has little to do with the focus of prior months. Now the clock is ticking and “we got a long way to go and a short time to get there” because the sales team has already promised a launch date. [beware sarcasm ahead…] So the logical thing to do is throw a lot of money and developers at the problem. With a little luck, pizza and late hours we’ll all be high-fiving this fall when the project is finished.

 

My client is in full-on hiring mode now and we’re getting candidate submissions from Careers 2.0, TopRubyJobs.com and every tech recruiting firm in town. In addition to the standard resume, we’re requiring serious candidates complete a coding exercise for review by the interview team.

 

Over the past couple of weeks, I’ve reviewed well over 20 code submissions. Sometimes the process has been surprisingly pleasant as we’ve seen some exceptional code submissions. Other times it has been pretty painful… Pain is actually a good thing when reviewing code submissions for potential candidates, because it’s not the pain of reviewing bad pull requests for production applications. In end, pull request pain is what we’re trying to avoid. We started requiring the submission of code exercises about 6 months ago and have tweaked the process a bit along the way. We’ve found that with the right approach, code exercises are an invaluable tool to help gauge the eventual code quality of potential candidates. By no means is it fool-proof as I’m sure we’ve passed on some talented developers; but for the most part, the process has worked well. It has been a great tool to see whether or not we want to move forward with the final stages of the interview process and whether or not the potential candidate would work well within the existing codebase.

 

As one of the interviewers, I thought I might pass along a few words of advice to any potential candidates out there. Keep in mind that much of what I say probably applies to code exercises for any development position – not just the openings we’re looking to fill. Additionally, at the end of this post, I mention a few personal take-aways I’ve absorbed from the interview process.

Exercise Guidelines (for context)

Without giving readers the entire example (and without giving any potential candidates a lead on any of the specifics), here’s a quick overview of our coding exercise guidelines. We try to leave the implementation details wide open for interpretation, but steer the candidate in somewhat of a general direction.

 

  • Read a dataset from a provided set of CSV files and perform some calculations.
  • Print your results to STDOUT.
  • The developer is in complete control of what gems they choose to use. …if they choose to use any.
  • There is no database requirement. Use one or don't use one - we don't care. The solution can be completed with or without the use of a database.
  • Approach the problem as if you were intending on deploying this to a production environment.

That’s it!

Take Advantage of the Opportunity

Not everyone has the time or aspires to be an open source contributor or active blogger; and thus, many developers have a pretty lightweight public Github profile. I get it, you use Github for work stuff only – that’s fine. Everyone has different priorities and if you haven’t had the opportunity or the time to put your work on public display, here’s your chance! Treat the exercise as though you actually want others to see it. In this case it’s a significant factor on whether or not we think you’re a good fit for the job.

Write for Production

Coding exercises for interview purposes are more than likely contrived and simplistic, but hopefully it’s fun too. When you’re submitting code, the reviewers are looking to see whether or not it is production quality regardless of what the code is supposed to do. Take some time and put some effort into the solution because code really smells if you don’t. Prove that your solution has evolved a bit over the course of your work – iterate on it. As with any first-pass on code, it could probably use some refactoring. Approach the code in the same way you’d develop a feature for an application you’re working on. 

Source Control

I’m actually a bit surprised that I’m even mentioning this… However, we’ve gotten a lot of submissions through .zip or .tar.gz files. Really?! No one will ever merge something from an archive file into a production codebase. If they do, you’ve just found an organization that should go on your employment blacklist. Submit the code in Github or Bitbucket… Not only does it make the code easier for others to review, but it gives the reviewers some insight into your development approach through the commit history. Additionally, we’ll also be able to tell if you were B.S.-ing about your TDD disciplines.

Tests…

Yes, we’re looking to see if you test your code. If you ever get past a coding exercise to the next round of interviews without writing tests – employer blacklist. On more than one occasion, we’ve seen submissions without tests… Surprisingly, I’m happy to see these because I can automatically dismiss it without any further review. You’ve just made my job easy – and I appreciate that.

Good Tests…

This is without question the most important thing that I’m looking for when reviewing code submissions. I don’t only want to see tests, but thorough and valuable tests. Show clear intent and value in your tests and make sure the tests cover the important areas of your work. Use tests to help you flush out your final solution. It’s extremely important to approach the problem with TDD in mind.

Ruby 1.8.7

Yes, we actually received one solution indicating in the project README that it targeted Ruby 1.8.7. “I haven’t updated my laptop to the newest version yet…” For crying out loud, man! Ruby 1.8.7 hasn’t received bug fixes since June of 2012 and all security fixes stopped almost a year ago (if you don’t believe me, read this). This type of thing is nothing more than developer laziness and suggests you know little or nothing at all about RVM or rbenv. Targeting the latest version of Ruby is nothing more than a quick shell command to set up! Dial 187 on Ruby 1.8.7 and take this as an opportunity to try something new if you haven’t already!

Database Usage

As I mentioned earlier, the coding exercise in our case can be completed without the use of a database; but the decision to do so is left entirely up to the developer. If someone decides to use a database, it’s usually SQLite3 (which is fine because it works everywhere). However, we are going to check to make sure that you’re not specifically targeting SQLite3 because there’s no web project I know of that would use that in production. Use the ActiveRecord ORM and for Pete’s sake, don’t write inline SQL. Yes, we had a submission that had a hard-wired SQLite3 dependency with inline SQL. In my experience, developers (of any language) who think inline SQL is an appropriate practice instead of only-rarely-as-an-exception are cancer to teams. If you don’t believe me, hire one and let me know how that turns out for you. Inline SQL is poor programming practice even if you have tests covering the functionality.

A Rails App? What about STDOUT?

When instructions clearly state to “print all output to STDOUT”, don’t submit a Rails app. Additionally, don’t use “rails new some_application” to generate a project template for the code submission because there’s going to be a lot of unnecessary bloat in your solution… We originally left it up to the developer for the choice of whether or not to write a Rails app, but we’ve since changed the instructions to specifically ask for console output. Previously when Rails apps were submitted, we critiqued the whole project – controllers, models, routes, tests, HTML markup, etc. Now when Rails apps are submitted, it’s painfully clear that the instructions weren’t followed and projects get immediately dismissed. It’s incredibly important to follow the given instructions…

In Closing…

Not only has the code submission and review process been good for our interview process, but it has been good for me as a reviewer… One of the best things you can do for yourself to “level up” as a developer is read, inspect and execute a LOT of code. Over the last several weeks, I’ve done just that.  I’ve seen some approaches to problems that I would never have considered. I’ve learned some Ruby “trick shots” that I’m probably going to use in the future. …and I definitely gained some insight into what others will probably be looking at when the time comes for me to submit my coding exercise.

My 2013 devLink Abstracts

04.02.2013 12:40 by kbeckman | Comments

After a little bit of prodding from a friend and colleague of mine, I submitted a couple of abstracts for talks at devLink 2013. I’ve been thinking about submitting some talks for about a year now. Well, now I don’t have to think about it anymore – but I might have some prep work to do!

 

Introduce Ruby to Your .NET Environment

[Intermediate to Advanced]

Interested in Ruby, but so far have only tinkered with it at home in your free time? How about at work? Nope… “We’re a .NET shop. …and IronRuby hasn’t had a release since early 2011. Isn’t that project dead?” Now there’s no need for excuses and no need for a Ruby implementation that runs on the CLR. This session provides some real-world examples proving the benefits of using Ruby alongside your .NET environment and helps make the case to include Ruby as part of your development toolkit.

This session includes demos, discussion and Github projects covering the following:

  • Use Ruby (in combination with PowerShell, Albacore, MSBuild and WebDeploy) to streamline your Continuous Integration and code deploy process. Build your code; exercise it with tests; and package/deploy it all without writing a single line of MSBuild XML.
  • Build a stronger relationship with your QA Team by introducing Ruby as the scripting language of choice for integration test automation. You’ll make everyone’s job easier and make automated integration testing a first class citizen in your development process.
  • Tired of spending an afternoon setting up a production or test server? Are your base virtual machines chronically outdated? Use Ruby code and Opscode Chef to bootstrap your servers and use code to setup your servers instead of doing everything manually. Infrastructure as code!

 

Demystifying Single Sign-On

[Intermediate]

Single Sign-On – SSO… If you’ve considered single sign-on or identity federation for your organization, those three letters are probably better rearranged – S.O.S. This session will help you sort out all the acronyms and protocols so you can start in the right direction to a successful implementation. We’ll take a look at Windows Identity Foundation and Windows Azure Active Directory (formerly Access Control Service) and how they fit in the overall solution.

This session covers:

The Basics…

  • Token Issuers and Relying Parties (with demo)
  • Comparison of WS-Federation, OAuth and SAML-P
  • SAML AuthN Token Overview
  • Dissection of WS-Federation Web Requests

Advanced Topics…

  • Identity Federation with Trusted Organizations (with demo
  • Important Architecture Considerations
  • Social vs Corporate Identity

 

What do you think? Do either of these sound interesting enough to make the cut? I ‘m hoping so… Either way, speaking or not, I’ll see you in Chattanooga in August!

Fight Back Against Pseudo-Security

09.11.2012 13:27 by kbeckman | Comments

At least some of your online personal and financial information is AT RISK RIGHT NOW. Some of your information might already be compromised… Even worse, some of the companies hosting your information may not even know that a breach has occurred. And worst of all, your personal information might be IS in the hands of companies with  bullshit security practices.  Online security breaches are an increasingly common occurrence… Back in June, LinkedIn was hacked and 6 million of its users’ passwords were posted online – mine was one that was stolen… A month or so later, Yahoo! was hacked and 400,000 user accounts were compromised. Today, well-known hosting service and DNS registrar – GoDaddy – was hacked and the number of affected sites is in the millions. Although a leak of passwords or personal information may or may not have been part of the breach… Folks, those are just the major instances this summer.

 

Amidst all the web chaos today, I became aware of the half-assed, don’t-give-a-shit security considerations of my former web hosting vendor – Arvixe. Here are the details…

 

Arvixe Billing Users Beware!!!

Until a couple of weeks ago, coding4streetcred.com was hosted through web hosting vendor, Arvixe.  The hosting arrangement was extremely vanilla – just a single server configuration sharing an IIS instance with who-knows-how-many other sites. Arvixe’s pricing was reasonable and the initial setup was incredibly easy. In the two years coding4streetcred.com resided on their servers, I only had a couple of issues with the IIS integration of Microsoft’s WebDeploy utility (probably only because WebDeploy wasn’t a mature product yet). Their support team was awesome and I always got a quick and relevant response. Despite my satisfaction with Arvixe, I recently decided to move my site to Amazon’s Elastic Compute Cloud for a couple of reasons: a) Amazon’s free usage tier; and b) I wanted more experience with Amazon’s Web Services platform for my current and upcoming development contracts.

 

All in all, my experience with Arvixe was good until today when I received the following email from their support team as I attempted to close out my account…

Hello Keith,
I am sorry to hear that you have moved your hosting services to another provider. I can close your account [account name removed] for you, effective immediately. I'll just need you to confirm your identity by providing the last 4 characters of your billing password. If you need to reset your password, please go to [link removed].

ARE YOU SHITTING ME?! PROVIDE THE LAST 4 CHARACTERS OF MY PASSWORD?! For the first time in the history of my Internet usage, a company has asked me to verify my identity by providing details of my actual account password… Unbelievable! After I politely replied via email and tweeted about my disgust with their plain text password storage, I got the following response via Twitter (full conversation is included).

image  image

I finally reset my password to finish the account termination only to find that Arvixe actually sends plain text reset passwords through email! This was another first for me – plain text passwords through email… If you use Arvixe, STOP USING THEM IMMEDIATELY.

 

Why Would This Be a Problem?

Any time you find that all or part of your password information is stored in plain text, IT IS A BIG PROBLEM. The cryptographic details are outside the scope of this post, but I’ll tell you this…

  • Passwords stored in plain text are accessible by anyone (in this case Arvixe employees) who has access to the system database.
  • Passwords stored in plain text are available in plain text to anyone who compromises or hacks that system.
  • Passwords stored in partial plain text can provide enough information to hackers to break the encryption cipher used encrypt the rest of your password. 
  • Passwords sent via email in plain text are only as secure as your email provider’s security. Passwords should never be sent via email – NEVER. An appropriate approach is to send a secure link that allows you to reset your password through some application utility.

It’s no joke… Even worse, this concerned Arvixe’s billing system – the same system that is capable of storing credit card information allowing you to automatically renew your hosting account as needed. Thank goodness they didn’t have any of my credit card information stored. At least not to my knowledge anyway.

 

The Minimum You Should Be Doing to Protect Yourself

The sad truth here is that there are droves of clever hackers out there that can and will break into a system where your account information is stored. The companies hosting your information won’t be able to stop them every time… Fortunately, there are a few things you can do to limit your attack surface… I’ve listed them below in order of what I think are most important.

  • Use a different password for every online account. This sounds a lot more difficult than it actually is… There are several good password management services out there for free or a small fee that can help you with this. I use LastPass. It integrates with every browser and they have mobile apps so you can use them on your Android or iOS devices. A different password for every account minimizes the effect on other accounts if one is ever breached.
  • Don’t store credit card details online. Most sites don’t require you to store credit card details. The exceptions would be those sites that require it for recurring charges… Only do it when or if you have to.
  • Max out your password strength. Every site has different rules regarding password strength (i.e. password length, upper/lower case character requirements, special characters, etc.). Use the longest password with the most numbers, special characters and combination of upper/lower case characters that the site will allow.
  • Be wary of passwords in plain text. If you ever find that your account provider stores passwords in plain text (or even part of your password), terminate your account immediately. The same goes for account providers that send passwords in plain text via email.
  • Make half-assed security practices public. Tweet it. Blog about it. Tell your friends. Other people need to know too… With a little exposure to bad press, companies might actually make it a priority to change their ways.
  • Always be vigilant about your personal details. Your financial stability, credit score, free time and countless other details of your life depend on it…

 

In Closing…

Cyber security is nothing to ignore. If your personal or financial information is online, it is at risk somewhere. There are countless ways your information can get into malicious hands. Unfortunately, it is just an ugly detail of Internet usage. Do everything you can to protect yourself… Stay safe out there.

A Good Burn…

08.05.2011 08:04 by kbeckman | Comments

Nothing technical here… I just wanted to call mention to an email that I received from arguably my most famous subscriber – the 16-time World Champion Superstar professional wrestler, Ric “The Nature Boy” Flair. Ah Ric, this takes me back about 11 years when I first discovered how to send SMTP emails without including my actual email address. Spoofing email addresses is simply GOOD CLEAN FUN. The short email I received sent me down Memory Lane and jogged my memory to some great office burns and practical jokes I’ve seen and been on the receiving end of over the years.

 

Subject: your blog sucks!!!

From: Ric Flair (tobethebest@youhavetobeatthebest.com)

Body: “WHOOOOOOOOOOOOOOOOOOOO!!!”

http://youtu.be/iy-LQH8N6Ug (for those of you who get this via RSS)

 

Meeting Invites: Parking Lot Ass-Kickin’

This is my favorite – probably because it caught me so off-guard the first time it happened… I had just started my first full-time .NET development gig about 6 ago. Not more than a week in, I got an Outlook meeting invite from one of the Sr. Devs that I barely knew. I was a mandatory attendee for a meeting the next day…

Time: 09:15

Location: Parking Lot

Subject: Kickin’ Keith’s Ass

Classic.

 

You’re Not Checking In Enough Code

[WTF?!] This happened at the same gig as the one I mentioned in the Parking Lot Ass Kickin’. Our development manager called the team in for an impromptu mandatory meeting just prior to lunch. The meeting started with our manager explaining a conversation he had with the VP of Development regarding the team’s performance. We were hitting all of our early project deadlines, but nonetheless our VP was concerned about the amount of code we were checking in. “There weren’t enough lines of code being checked in… I don’t think they’re working hard enough.” [Are you shitting me?] He went on to say that the development group was going to implement a new bonus structure not based on performance and meeting deadlines, but one based solely on the number of lines of code we checked-in to source control. Our poker-faced manager went on for another few minutes describing the new bonus structure and everyone else in the room was thinking about the new content their resumes would contain before the next work day started… Finally he broke a smile and rolled lunch in for everyone. …and then gave everyone the afternoon off!

 

Always Lock Your Tailgate

This happened at easily the worst software development gig I’ve held in my 10+ year career. Thankfully though, I worked with the coolest group of people who were able to find some humor despite the sweat-shop environment. I rode to lunch with a couple of the developers one afternoon. That day in particular, we were lucky enough to find time for lunch… I got back to my office an hour or so later to find the tailgate of my truck unhitched and sitting against the wall. Thankfully no one saw me toting it down the 4th floor elevator and out through the lobby after work. My tailgate remained locked after that.

 

Honorable Mention:

1) PrankPlace.com for some good ideas…

2) Tape over the optical mouse lense rendering it useless…

3) Randomly injecting business cards of the company’s all-time worst hire into your buddy’s box of business cards…

 

I welcome any reader comments describing some good office burns. I’m looking for some new content… :)

C4SC Update

01.27.2011 06:25 by kbeckman | Comments

I wanted to post a quick update to the C4SC audience and inform everyone about some recent site enhancements as well as some upcoming post changes, etc.

 

.NET 4.0, BlogEngine.NET 2.0

C4SC was redeployed this evening and is now running entirely on the .NET 4.0 platform! While nothing should change the user experience, it’s always nice to advertise major upgrades. Along with the .NET upgrade, C4SC has moved from BlogEngine.NET version 1.61 to the BlogEngine.NET 2.0 platform. I’m really excited about the new features and functions added by the BlogEngine.NET team and highly encourage anyone thinking about building a blog site to use BlogEngine.NET. The 2.0 upgrade has introduced some great features to enhance the administration experience.

 

Syntax Highlighting

I should have paid closer attention to the BlogEngine.NET roadmap... Then I might have noticed the development team was planning the implementation of Alex Gorbathev’s SyntaxHighlighter as a BlogEngine.NET extension. I had recently implemented this in C4SC, but have now scrapped my custom implementation in favor of the included extension. From now on all C4SC code posts will have well-formatted syntax rather than just plain text. I plan on updating older posts to accommodate the SyntaxHighlighter changes as time permits.

 

New Format for Refactoring-Related Posts

All posts related to any type of refactoring will resemble the format used by Martin Fowler in his book, Refactoring: Improving the Design of Existing Code. I consider that to the the single most beneficial book I’ve ever read on software development and will begin to follow the same style in this blog. Each post will include four sections detailing the problem and formulating a solution – Description, Motivation, Mechanics and Example(s).  It should be a good way to accumulate a targeted catalog of refactorings I’ve used and continue to use throughout my software development.