The Curious Programmer

Software, Gadgets, Books, and All Things Geek

What I Learned From My Buddy’s Interview with Amazon — August 26, 2015

What I Learned From My Buddy’s Interview with Amazon

Amazon has been in the news a lot recently. If you have not heard, the New York Times released an article last week that shed some light on what it is like to work at the giant tech enterprise, and (spoiler alert) it didn’t make Amazon look all too great. On the contrary, some of the stories that the employees told were borderline shocking with one employee quoted saying

Nearly every person I worked with, I saw cry at their desk.

Now I don’t work at Amazon, so I can’t contest to the truth of this statement, and many people that do work there have spoken out against the article stating that it did not reflect their own experiences they have had while working there.

However, around the same time last week (before I read the article), my good friend and fellow software developer was contacted by Amazon for a SDE (Software Development Engineer) role they had open. To give you a little history on my buddy, he has about six years of professional development experience at both a start-up (for four years) and a Fortune 500 company (2 years) as a software engineer, with a small amount of software consulting work on the side.

Now I know this is not a ton of experience, but it is also not just a little either (many developers are being hired straight out of college these days). I believe he saw and learned a lot from his previous working experiences and has progressed as a pretty good engineer. Knowing these things, I wasn’t that surprised that Amazon contacted him and wanted to see if he would be a good fit for the company. I also believed that he would most likely get a job offer if Amazon valued the qualities that everyone seems to say is most important in a “great developer and leader”. He most definitely was familiar with many of my books that I have publicly stated are “The Most Influential Books That Every Software Engineer Needs to Read“. In fact, his favorite book on software development was the same as mine (Code Complete 2), and he knew software architecture, design, and construction inside and out. Amazon, I thought, was going to get a great employee.

However, I was surprised to find out that the company had eliminated him after the first interview.

“What went wrong?” I asked him. I knew he could create great software and that he was a pretty good interviewer as well, so this didn’t make sense to me that he could be dismissed so quickly.

He went on to explain exactly what had happened.

The first interview that the recruiter had set up with him was not an interview in the traditional sense. It was a data structures and algorithms implementation exam. He explained that he was required to log on to a remote server and solve problems in an editor without text completion (much like doing a white boarding coding session in other interviews). He told me that he had 90 minutes to complete three implementations of algorithms that would pass the 50 or so automated tests that Amazon ran on his solution.

This was the kind of stuff you had drilled into your brain in college. Algorithms and data structures and all the mathematical theories that go with them (graph theory, number theory, and greedy algorithms were among the knowledge pool that you would need to possess to successfully complete the problems).

Most languages have all of these algorithms and data structures implemented for you now, so very rarely (if ever) will you have to do this under a time constraint and no resources to help you. However, none of this mattered to my buddy, or Amazon for that matter, when it came down to it. My friend (being out of college for over five years now) could not remember how to implement these in the most efficient way possible (yes, getting the right answer will only get you about half the points, full points only come from algorithms that have the lowest asymptotic time and space complexity possible).

I felt sorry for him. He seemed like he wanted the job, but was quickly ruled out because of a lack of mastery over what computer science is based upon.

That being said, I have to agree fully with Amazon’s decision (and I think my buddy does too after the initial hurt from rejection). They found a weak link in his chain. He may have been the best architect, designer, leader, and teacher that they would ever have employed, but we will never know because he forgot to remember to practice and keep fresh the fundamentals.

I’ve written about this phenomenon before (here), and received a lot of criticism for it, but a lack of the fundamentals, once again, cost a great developer a great job (well “great job” is debatable if you read the Times article…). In my article, I talked about being able to do something as simple as reversing a singly linked list (something everyone in computer science 101 should know how to do) and everyone was upset and said that “there is no reason to know how to have to do these elementary things anymore” because they are already handled for you by the framework and libraries that come with the development platform.

While it is nice to have these, YOU STILL HAVE TO UNDERSTAND HOW THEY WORK!

It’s obvious that companies like Amazon, Google, Apple, and Microsoft have realized this judging by their interviewing habits. Regardless on your beliefs if this is “right” or not, it can be said that if you want to work at the world’s most prestigious software companies, then this type of understanding is a MUST. If you don’t, then maybe you can get by being a great developer after mastering the teachings of books such as “Code Complete”. However, you will not be completely well-rounded. My buddy was familiar and read many of my “12 Books Every Developer Needs To Read”, but he did not, however, read my #4th Ranked book on the list, “Introduction to Algorithms“. If he had read and understood this, I can confidently say that he would be flying to Seattle right now getting ready to start his first day at Amazon.

I hope you enjoyed this article, and if you did, please subscribe to my blog at jasonroell.com. If you don’t feel like doing that (darn you!) then I would appreciate it if you liked or shared the article to other developers that you think would benefit from it! Thanks for reading!

Use Software Metaphors to Your Advantage — August 11, 2015

Use Software Metaphors to Your Advantage

Being a software developer, we’ve all experienced a time in which we had to explain a technical matter to a non technical co-worker, manager, or customer. This, as we know, is not always an easy task to say the least. Software development can be complicated and individuals not concerned with the technical aspects don’t speak the technical language that we all use. It is our responsibility as the technical professional then to be able to elucidate our ideas to them to provide them some understanding and insight.

People tend to only understand what they can see. For most people it is difficult to grasp more abstract matters without somehow visualizing them. Software is an example of such an abstract matter.
So what do we do???
Well one idea that comes to mind would be to use metaphors. Metaphors are perfect for this situation because metaphors allow you to bridge the gap between something you understand thoroughly and something you understand poorly. Leveraging the power of metaphors your will quickly (depending on the quality of the metaphor) be able to elaborate your technical software jargon into a model that your listener will be able to understand and relate to.
I think this will be clearer with an example. Let us visit the process of developing software through a comparison with physically building something. This analogy is typically used because most people are at least relatively familiar with building something sometime in there life, whether it was a Lego tower, doghouse, swing set, residential house, or even a skyscraper.
Along those lines, people are also familiar with some of the basic concepts that are involved in these matters. For example, even if a person has not built a house on their own before, they still understand that the walls and floor have to be built before you start painting or laying down carpet.
This basic and almost universal understanding is exactly what we are looking for. We can now take concepts completely foreign to the listener and apply them to ideas that they do understand.
I’ve used this metaphor before to explain the reasons behind paying for a development tool or a third party library. Many times a manager who is not technical cannot understand why a development team is asking for “X” amount of dollars to pay for code written by another company or developer.
“Why wouldn’t you just write it yourself???!” they complain. “We hired you to develop, not give you money to pay for code or use open source code developed by someone else!”. If you do not come from a technical background this might seem like a perfectly valid point, and sometimes it even is, but many times this is the wrong attitude to have. Let me explain…
When a construction worker is building a house, does he cut down the trees and shape them into lumber? Does he build his own tools from scratch? Does he build the windows, counters, toilet, dishwasher, dryer, laundry machine, or refrigerator? No. Of course not. In many cases the carpenter doesn’t even build the cabinets. Often these come pre-assembled and the carpenter just has to know how to hang the cabinets. Why is this? Could a carpenter build a cabinet? I would sure hope so. So why doesn’t he?
In building a house, you wouldn’t try to build things you can buy already built. This is because even though sometimes the materials you are buying can be expensive, the main expense is always labor! The same goes for software. If something is complicated enough that it is going to take more than a month to build from scratch and there is already a pre-built solution that completely satisfies your needs, then it makes more sense to spend the two grand on a software product than to pay your developer twice that much at least for his hours developing it from scratch.
Now I know that many people will disagree and say that the solution should be tailored to the business, and this is definitely sometimes the case. Just as it is sometimes the case that an individual will want to have everything in there house custom made. But guess what? This will cost them much more, just like it would to have a developer develop their own robust object relational mapper.
The same goes for tools that developers use. Would you want your carpenter to be stuck with just an old hammer? Or would you want him to get the job done faster (and cheaper) with a nail gun?  I relay this metaphor to managers when they won’t pay 100-200 bucks for some simple tools (ReSharper for us .NET guys 🙂 ) that would greatly increase a software developer’s productivity. The cost of the tool comes out to be what you would be paying the developer for about a half days work, yet almost always you are going to get much more value than that out of spending the money on a tool that will help the developer crank out a bunch more quality lines of code.
The building-construction metaphor could be extended in a variety of other directions which is why the metaphor is so powerful. Many terms common in software development derive from the building metaphor: software architecture, scaffolding, construction, foundation classes, and many many more. Use these metaphors to your advantage so that you aren’t stuck with a listener that has no clue, and now no more interest, in what you are talking about.
I hope you enjoyed this article and if you did please subscribe to my blog at jasonroell.com. If you don’t feel like doing that (darn you!) then I would really appreciate it if you liked or shared the article to other developers that you think would benefit from it! Thanks for reading!
5 Essential Skills Every Developer Needs to Have — August 5, 2015

5 Essential Skills Every Developer Needs to Have

how-resume-skills-based

A month or two ago I wrote a post titled “Every Programmer Should Understand This“. I received a bunch of comments on the post, some of which were from people agreeing with the article and some which thought I should be hung for suggesting such an insane idea! Some of the biggest critics of the article wrote that the problem that I introduced was too specific to a field in computer science and that many great programmers might not understand that particular area and shouldn’t need to.

After contemplating about what the nay-sayers had to say, I have to agree with some of their points. Although the article was targeted for more traditional computer science based programmers, there are many other type of developers out there that don’t nessasarily fit into this category.

With this article, I want to provide a more general list of skills that I believe developers and programmers of any specialization should be well versed in. Most of these skills center around the broader skill of “problem solving”.

As software developers, we do not learn to program, we learn to solve problems. It’s not about which are the top five to memorize how to solve, it’s about building the best toolbox of knowledge and methods so that you can solve ANY problem that comes your way.

With that said here are the 5 most important skills to have as a software programmer/developer/engineer:

1) Practice questioning your assumptions

When you run into a bug and you aren’t sure why it is breaking, you need to be able to take a step back and question all of your assumptions about what is happening and what should be happening. Whenever another programmer asks me to help them find a bug, and they explain, “The code is doing X, then processing Y into Z, but Z has the wrong value.” I will ask them, “Ok, please show me that the code is doing X.” They’ll usually say, “That part is working fine, the bug is somewhere in Y to Z.” I’ll respond, “That’s fine, but something isn’t working and we need to question our base assumptions.”

9 times out of 10, the problem was with X and that’s why the other person couldn’t find it, because they didn’t question their assumptions.

2) Know your data structures and when to use which ones 

Higher level languages such as Java or C# are excellent languages to use when practicing this skill. Let’s say you need to store a list of items… whether you use an ArrayList or a LinkedList can dramatically impact the performance of your code. An ArrayList is very fast for accessing arbitrary elements in the list, but it’s very slow for inserting elements into the middle. LinkedLists are vice versa.

Also, did you practice skill #1 and question your assumptions? Is it really a List that you need? Perhaps the elements in the array are guaranteed to be unique, so you really should be using a Set instead of a List. Does it matter what order the items are in? No? Then a HashSet will work just fine, but if you need to keep them in a repeatable, consistent order then you’re going to need to use a TreeSet.

3) Debugging 

The hardest problem to solve is the one where you don’t know where the problem is! This is the mechanism that helps you do (1) Question Assumptions. Learn your debugging tools that allow you to step through the code, line by line, and watch how your variables are changing so that you can where things go awry. However, sometimes simple logging statements are the way to go for debugging. Perhaps the problem exists in a section of code that is going to run 1000 times, but doesn’t start failing until the 900+ time, you don’t want to step through that many. Or perhaps you aren’t exactly sure why a certain calculation is wrong and being able to print out the results at a 1000 different iterations will help you detect a pattern in the errors which will help you hone in on the problem.

4) Google-ing

Being able to use the Internet, browse StackOverflow, look up documentation, and find solutions online is definitely one of the single most valuable skills a developer can have. It’s amazing how many people struggle with this aspect of programming and assume they need lots of formal training and book reading before writing a line of code or trying to install something. (This is not to knock formal training, which has its place, but formal training is not something that should ever be a prerequisite to experimentation and self-learning).

5.) Modeling

You have to take a problem that is too complex to understand in its entirety, extract a common set of elements from it, and represent it a different way. The ability to to perform abstraction is key skill set for any programmer. Examples of this are being able to reduce complex problems into a set of unambiguous procedures, boolean logic; how to turn a real world condition into a set of true and false statements, and good solid algebra. You need to be able to reduce something in the real world which is complex to something simple that you can solve. Math is a very powerful tool for doing that.

To recap, I don’t think there are any problems that can successfully tell you whether you’re a good programmer, but I would say that any problems I would use to identify a good programmer would involve opportunities to judge all five skills above.

I’ve known a fair number of people that are quite familiar with design patterns, complex algorithms, etc., that I would not want anywhere near my code. There is nothing wrong with knowing and understanding these concepts and at some point in your career it will probably be required. However, these are not the fundamental building block of a great developer by any means.

With the skills listed above, an individual would be able to provide an effective solution to almost any problem and that’s what we as software engineers should be able to pride ourselves on.

Thanks for reading, and if you liked this post please subscribe to my blog at JasonRoell.com and leave any comments below! I would love to get everyones views on the most valuable skills for a programmer to have in the industry today!