Allow “Phone a Friend” during Technical Interviews?

February 4, 2013

I’ve been thinking about this recently and it seems a little crazy, but what if you allowed people who were going through technical interviews the option to either phone a friend to help with the question, or even allow them to look for an answer online?

I haven’t tried this out yet “in real life” but it does seem like a pretty interesting experiment.  Here’s what I think of both these options and why i’m not shrugging this off as insanity:

Phone a Friend

This is what popped into my head first: the candidate has a question to answer and can’t figure it out.  They get 5 minutes to call a friend to get advice.  The candidate then has to explain the solution and how the friend helped them do it.  How could this possibly be a good idea?!

Well, for one thing this closely matches the real world.  People don’t always have the answers and talking to co-workers and good friends is a always a great way to find them.  Having the ability to articulate the question quickly, and understand the solution quickly is a great quality to have for a hire.

In addition, having peers to ask shows a little about their social group and the types of knowledge in that circle (this says nothing negative about candidates that don’t have friends to ask).  Bonus: their friends are exposed to the candidates hiring process and experience.  It’s a great way to get exposure!

Find an Answer Online

If phoning friends doesn’t sound crazy to you, this shouldn’t either.  This again is a normal activity engineers do when confronted with a problem they don’t have an immediate answer to.  They scour the internet for hints, papers, sample code, etc to help them formulate some type of solution. Why not allow this process during a technical interview?  Give the candidate 5 minutes to go online and do what they want to find a solution.  Then let them explain the solution and where they found help to formulate it.

Not having the immediate answer is less important than the ability to find a great solution that the engineer completely understands and can explain.  I honestly think that there is a group of people out there who aren’t great at figuring out something they haven’t encountered before, but who are excellent at implementing and leveraging solutions they have encountered – even in creative and new ways (I definitely know some people like this).


The more I think of it, the more I like it.  Obviously it all depends on the candidate’s comfort level with this, and the types of questions that will be asked.  I do know that i’ll be mulling this over for a while to come.

What do you think?


Make sure you don’t know what you’re doing (part of the time)

January 10, 2013

Throughout the years, I’ve held many positions at different companies and lately I’ve been reflecting on which ones really made a difference in me growing as a developer, manager, and overall good person to work with (my opinion of course :).

I’ve come to the conclusion that to really grow, you need to put yourself in a position where you don’t know what the **** you’re doing – part of the time.  This means that on some things, you feel confident in your ability to execute and have the experience to make it happen, and part of the time you’re in uncharted territory – being in situations or working on things you’ve never done before.

Feeling 100% confident in your current work?  You’re probably not getting much new knowledge or growing as fast as you can.  Feeling 100% lost in your current work?  You’re probably in way over your head!

So having a little of both is ideal. The actual split – 50/50 or 70/30, etc. depends on your comfort level, but I encourage everyone to seek out a little personal uncharted territory.

If you want a technical co-founder, show them you’re serious first.

December 7, 2012

Like other technical people I know,  I often get a pitch from someone regarding an idea they have.  They tell me how amazing their idea is (sometimes it is), and how they are looking for a technical co-founder to build the product so they be gazillionaires.

Their pitch is great, the targeted market is good, the product seems feasible, and they have some friends who would be strategic advisers.

So after the show and dance, they wait for me to say “Wow! that’s an amazing idea, when do we start?”.

But I don’t.  I don’t take them seriously.

Why not?  Because they haven’t proven to me that they have the vision and ability to make it happen.

Technical co-founders have to spend weeks, if not months, putting something together – dedicate quite a bit of time upfront – and these presentations aren’t enough in my opinion to show you can walk the walk.

So I came up with a very simple solution.  I give them homework.

Here is a typical example:

(presentation ends)

Them: “So what do you think?”

Me: “Looks great <insert name here>.  So when are you going to have a mock up ready?”

Them: “What? What mock up?”

Me: “Well, before you even want to consider developing, you definitely want to take the time and envision your product.  You know, mock up a fake version of your application so that people can play with it.  See how it feels and works.”

Them: “Oh.  Don’t you need technical knowledge for that?”

Me: “Nope.  You just need to know what you want – maybe some designer advice as well – and some simple tools to put it together.  There are lots of great tools to help you mock up your website and mobile app”.

Them: “I see.  That’s a good idea.”

Me: “Yeah.  Why don’t you ping me when you’re done with that and we can talk about it”.

(conversation finishes up).

For me, something like this is the minimum i’d expect from a non-technical co-founder – someone who can get this part done at least to some good level without hand holding.  It also shows how serious they are about dedicating time and resources to their idea and their ability to execute.

Fortunately or unfortunately, no one has managed to complete it so far.

Time saved for everyone.

Monakai Inspired Theme for IntelliJ

June 3, 2012

I’m a frequent user of IntelliJ because it’s a great Java IDE as well a great IDE for Node.js.  I’m also a big fan of Sublime Text 2 which is another great editor I use for everything outside the IDE.

One thing I do miss in IntelliJ-land is the the Monokai color scheme that is the default in ST2.  I tried for a while to find some port of the color scheme, but didn’t find something that I liked.

So having said that, I’d like to share my personal attempt at porting the color scheme to IntelliJ with my own twist.

I started with Roger Heim’s port of the Ragnarok Blue color scheme, and went from there.  I only ported the languages I use often so feel free to ping me if you want to share any additional customizations you make.

Without further adieu, here it is (updated for IntelliJ 12):

IntelliJ 12 – n0tw0rthy-12.xml

IntelliJ 11 – n0tw0rthy-11.xml


(I can’t guarantee backwards compatibility to older versions).

Congrats on your new job. Now shut up and listen.

April 20, 2012

I wanted to give some advice regarding starting a new tech job.  And I wanted to share it because lately i’ve seen far too many people that don’t understand this concept and it not only makes their lives harder, it also pisses off their new (any possibly new+former) employer.

Bonus is that it’s really simple to get right.  So here is my advice:

Shut up and listen.

Thats it.

Your new new team doesn’t want to hear you ask why they aren’t using Hadoop, or why they’re using an older version of Python.  They don’t want to listen to you talk about how in your previous company you used this amazing NoSQL thing and scaled their system for 10 trillion users.  They’re don’t want to listen to you explain the benefits of non-blocking I/O for their service layer.

Why is that?

Because until you understand the context and history of their decisions, you’re not in a position to voice any meaningful opinions.

That context and history could include many (good) reasons for doing what they did or requirements that you never thought of.

Instead, you should be trying to learn as much as you can.  Ask questions were relevant in a curious and inquisitive way.  Get some stuff done while you’re at it.

Then maybe you’ll realize some of those original opinions were wrong.  Or maybe not, but now you have the clout to voice them constructively as well as the knowledge to suggest solutions.

And the best part is that it’s actually less work to listen than it is to talk.

From Java to Node.js

January 8, 2012

I’ve been developing for quite a while and in quite a few languages.  Somehow though, I’ve always seemed to fall back to Java when doing my own stuff – maybe partly from habit, partly because it has in my opinion the best open source selection out there, and party because I liked its mix of features and performance.

Specifically though, in the web arena things have been moving fast and furious with new languages, approaches, and methods like RoR, Play!, and Lift (and many others!).  While I “get it” regarding the benefits of these frameworks, I never felt the need to give them more than an initial deep dive to see how they work.  I nod a few times at their similarities and move on back to plain REST-ful services in Java with Spring, maybe an ORM (i try to avoid them these days), and a JS-rich front-end.

Recently, two factors made me deep dive into Node.js.  First is my growing appreciation with the progress of the JavaScript front-end.  What used to be little JavaScript snippets to validate a form “onSubmit” have evolved to a complete ecosystem of technologies, frameworks, and stacks.  My personal favorite these days is Backbone.js and try to use it whenever I can.

Second was the first hand feedback I got from a friend at Voxer about their success in using and deploying Node.js at real scale (they have a pretty big Node.js deployment).

So I jumped in.  In the short time I’ve been using it for some (real) projects, I can say that it’s my new favorite language of choice.

First of all, the event-driven (and non-blocking) model is a perfect fit for server side development.  While this has existed in the other languages and forms (Java Servlet 3.0, Event Machine, Twisted to name a few), I connected with the easy of use and natural maturity of it in JavaScript.  We’re all used to using callbacks anyway from your typical run-of-the-mill AJAX work right?

Second is the community and how large its gotten in the short time Node has been around.  There are lots of useful open source libraries to use to solve your problems and the quality level is high.

Third is that it was just so easy to pick up.  I have to admit that my core JavaScript was decent before I started using Node, but in terms of the Node core library and feature set itself, it’s pretty lean and mean and provides a good starting point to build what you need in case you can’t find someone who already did (which you most likely can).

So having said all that, I wanted to share what resources helped me get up to speed in Node.js coming from a Java background.

Getting to know JavaScript

There are lots of good resources out there on Node.js and i’ve listed them below.  For me, the most critical piece was getting my JavaScript knowledge to the next level.  Because you’ll be spending all your time writing your server code in JavaScript, it pays huge dividends to understand how to take full advantage of it.

As a Java developer you’re probably trained to think in OO designs.  With me, this was the part that I focused the most on.  Fortunately (or unforunately), JavaScript is not a classic OO language.  It can be if you shoehorn it, but i think that defeats the purpose.

Here is my short list of JavaScript resources:

  1. JavaScript: The Good Parts – Definitely a requirement.  Chapters 4 and 5 (functions, objects, and inheritance) are probably the most important part to understand well for those with an OO background.
  2. Learning Javascript with Object Graphs (part 2, and part 3) – has lots of good Node material, but this 3 part post is a good resource to top off your knowledge from the book.
  3. Simple “Class” Instantiation – Another good post I read recently.  Worth digesting.

Learning Node.js

With a good JavaScript background, starting to use Node.js is pretty straightforward.  The main part to understand is the asynchronous nature of the I/O and the need to produce and consume events to get stuff done.  Here is a list of resources I used to get up to speed:

  1. DailyJS’s Node Tutorial – A multipart tutorial for Node on DailyJS’s blog.  It’s a great resource and worth going through all the posts.
  2. Mixu’s Node Book – Not complete, but still worth it.  I look forward to reading the future chapters.
  3. Node Beginner Book – A good starter read.
  4. How To Node – A blog dedicated to Node.js.  Bookmark it.

I felt that going through these was more than enough to give me the push I needed get started.  Hopefully it does for you too (thanks to the authors for taking the time to share their knowledge!).


Java is all about open source frameworks.  That’s part of why it’s so popular.  While Node.js is much newer, lots of people have already done quite a bit of heavy-lifting and have shared their code with the world.  Below is what I think is a good mapping of popular Java frameworks to their Node.js equivalents (from what I know so far).


In Java land, most people are familiar with Web MVC frameworks like Spring MVC, Struts, Wicket, and JSF.  More recently though, the trend towards client-side JS MVC frameworks like Ember.js (SproutCore) and Backbone.js reduces the required feature-set of some of these frameworks.

Nonetheless, a good comparable Node.js web framework is Express.   In a sense, it’s even more than a web framework because it also provides most of the “web server” functionality most Java developers are used to through Tomcat, Jetty, etc (more specifically, Express builds on top of Connect)  It’s well thought out and provides the feature set needed to get things done.

Application Lifecycle Framework (DI Framework)

Spring is a popular framework in Java to provide a great deal of glue and abstraction functionality.  It allows easy dependency injection, testing, object lifecycle management, transaction management, etc.  It’s usually one of the first things I slap into a new project in Java.

In Node.js… I haven’t really missed it.  JavaScript allows much more flexible ways of decoupling dependencies and I personally haven’t felt the need to find a replacement for Spring.  Maybe that’s a good thing?

Object-Relational Mapping (ORMs)

I have mixed feelings regarding ORMs in general, but it does make your life easier sometimes.  There is no shortage of ORM librares for Node.js.  Take your pick.

Package Management Tools

Maven is probably most popular build management tool for Java.  While it is very flexible and powerful with a wide variety of plug-ins, it can get very cumbersome.  Npm is the mainstream package manager for Node.js.  It’s light, fast, and useful.

Testing Framework

Java has lots of these for sure, jUnit and company as standard.  There are also mock libraries, stub libraries, db test libraries, etc.  Node.js has quite a few as well.  Pick your poison.  I see that nodeunit is popular and is similar to jUnit.  I’m personally testing Mocha.  Testing tools are a more personal and subjective choice, but the good thing is that there definitely are good choices out there.


Java developers have quite a list of choices when choosing a logger library.  Commons logging, log4j, logback, and slf4j (wrapper) are some of the more popular ones.  Node.js also has a few.  I’m currently using winston and have no complaints so far.  It has the logging levels, multiple transports (appenders to log4j people), and does it all asynchronously as well.

Hopefully this will help someone save some time when peeking into the world of Node.  Good luck!

Mergers and Acquisitions Insight From an Ex-Googler

October 12, 2011

I recently attended the Silicon Valley Code Camp at Foothill College and it was pretty interesting.  Lots of sessions to choose from this year.

One specific session stood out for me.  Ashish Kelkar gave a great talk about his experiences in Mergers and Acquisitions in the Consumer Internet – specifically about his 6 years at Google being part of the team that did just that.

There is lots of good information on why they buy companies, how much they pay, how the process works, and when to negotiate.

Definitely good stuff.

Here is a link to the deck or you can browse the embedded version below:

Did you learn anything new from this?