Femgineer

Technical Interviewing 101

Having been at Mint.com for nearly 3 years I have had the unique opportunity of interviewing each of my bosses, and several of my co-workers.  Not to sound like a sycophant, but there is a reason why we hired each one of them.  During the interview process they surpassed all their peers in terms of having a passion for technology, engineering aptitude, stellar communication skills, and being curious enough to try the product prior to the interview!  I realize that not everyone is a “Rock Star Programmer” of the Ed Burns persuasion.  But there is some basic homework that needs to be done prior to each interview.

1. Brush up on algorithms:  I ask pretty basic freshman or sophomore level CS questions that I find people fail time and time again.  If you’ve been in industry for awhile its easy to forget all the algorithms you were taught, but that doesn’t mean you can’t crack open a book and skim through a few chapters on the basics such as sorting, big-O notation, and graph theory.

2. Write some code: there are countless websites out there that have practice interview coding questions such as implementing fibonacci iteratively vs recursively, or traversing a tree.  Please visit them!  And more specifically nail down the syntax for the language you are interviewing for.  Its not a deal-breaker, but it is a good idea to be as polished as possible.

3. When presented with a problem you don’t understand ask questions: while you might think you want to be an ace, and impress the interviewer by solving the problem as fast as you can and without any help, you do more damage by correctly answering the wrong problem.  Instead, pause to think about the problem, ask the interviewer questions on anything that seems unclear, and then proceed to solve the problem.  Remember we’re grading on process not just correctness, so its pivotal to communicate the solution, approach, and when you run into any roadblocks, because after all that is what’s going to happen on a day-to-day basis.

4. Read what your resume says and make sure you can explain it: anything you put on your resume is fair game, and employers will pick and choose projects to ask you questions. You should be able to communicate at a high-level the goal of the project and your role in it.  And if you put down that you know SQL, be prepared to write some SQL!

5. Use the product: I cannot emphasize this point enough. I know there is this pie-in-the-sky principle that as engineers our primary motivation is to work on tough problems regardless of what the business is, but if you haven’t even tried the product out how can we judge your enthusiasm for the company.  Being an engineer, especially at a startup is more than just cranking out code, its understanding the direction of the business, and being able to evolve with it and meet its needs.  If you’re not into the product or buy into the business model, how can we expect that you will put in the long hours.  Remember we want to hire you because we’re into you, and you should be just as into us, otherwise its going to be the case of unmet expectations on both ends.

I will conclude with the following: I realize its a recessionary year, and that people are scrambling to find jobs, and  I will admit to having looked for jobs during recessionary years myself.  The key to being a viable candidate is about understanding your strengths, selling yourself on those strengths, polishing up on your weak areas, and also communicating how you would make a unique impact on the product.


Exit mobile version