Brewed in the hoppy city of San Francisco

0 notes &

One out of the two Dodge Ram we had got stuck in the snow that morning. 

I found that baby snow remover hidden on the side of the house and started to have fun :) 

The truck stayed stuck in though and we ended up loading the other truck with 8 people to go to the mountain that day. Fun time.

5 notes &

Interviewing in the Silicon Valley.

One of the most complicated thing I’ve found as a foreign graduating student is to find the opportunity to put in practice what I have learned over the years of studies.

It could easily become a non-sense circle where getting experience can only be done in a company and a company would only hire you if you have experience. The dog bites its tail and as a foreign student you end up having to leave the country. 

I would like to share a few thoughts about how to overcome this problem, and also explain what I’ve learned during interviews, and what you should and should not do.

To start with, interviewing in a company can be a long and difficult process. As a graduating student, you have very few work experiences to share, so it becomes harder to talk about what you’ve done, and most of the interview will be oriented to what you know, and what you want to do.

In terms of what you know, companies will be looking at the basic questions and algorithms that people here consider being - the basics. The basics include :

You should be able to write an algorithm that uses a Linked List, or a Binary Tree, and be able to explain why a binary tree is a good way of solving a problem versus using a list or an array. How to explain that ? Well you can quantify the performance of an algorithm using the Big O Notation.

The first time I was asked to explain the performance of my algorithm, the only thing I could say was: “Well I guess it’s fast”. And then my interviewer made me re-write this algorithm using a different kind of data structure which would obviously run much faster, and all I could say to quantify the performance of this new algorithms is “Well I guess it’s much faster now.” I obviously did not get the job :)

Even though I knew without “really knowing” that some data structures would be a better use in certain conditions, I just could not explain the “why” was it really better. This is when I started looking at the Big O notation.

It is important to be able to quantify the performance of your algorithms during an interview. It is one way of showing your interviewer that you know what you’re talking about, and it will make you feel better about the choices you make during an interview.

Your interviewer will always try to see how much you know. It is ok to reach the limits of your knowledge. Your interviewer is not trying to destabilize you. He/She just wants to know your limits, and how fast can you understand new problems.

One thing that almost every recruiter/interviewer will look for is, how well can you write code. There are two ways of doing this:

  • They can ask you to write code on a white board, or on a computer, and watch the way you write things.
  • They can look at your code before hand if you’re sharing open source code.

Yes, that’s right! You should share some of the code you write with people for free ! One of the best ways to do this now-a-day is by using It is in my opinion as important as having a good resume, or a LinkedIn Profile, or recommendation from co-workers. The reason why, is because GitHub is a community of developer, that will use, share, edit your code, make it better, contribute etc. All these words will sound good to your interviewer’s ears !

Nobody is asking your to share your projects on GitHub, but snippets of code help, especially if they are answering to a problem somebody else is having. And when you share code, make sure to write documentation too, so people know where you’re coming from with this bit of code.

Talking about GitHub brings another interesting question that you are most likely to be asked during an interview. What is your favorite Version Control tool ?  This is a great opportunity to show your interviewer you know the difference betweenDistributed Version Control and Centralized Version control. It is also important to explain why you like one better than the other. A few version control software to know about and play around with: 



I personally use git and Mercurial.

Once you’ve passed the technical tests of your interview, wether you think you’ve succeeded or not, what is really important is not to let stress take over.

Often, more than one person will interview you, and you should not let your next interviewer guess how the previous interview went, even if it was a disaster. Interviewers meet afterwords, and if you’ve managed to have a positive impact on a few of your interviewers, they will defend you if they were impressed by your presentation.

It is important to show companies that spend time interviewing you, that you’ve spent time doing some research about the company. When I interviewed at my current job, I knew exactly how much money the company raised, and when the head of engineering asked me what I knew about the company, I could not help but smiling and getting that number out. Might have not been the best approach, but he replied with “I see you’ve done your homework”. Wether it’s good or bad - it shows I’ve spent time looking into the company, and I know where I want to go.

Every single info you can gather about a company will help you go through the difficult time of interviews. Startups in the Silicon Valley are looking for people that match the spirit of their employees. Don’t act scared, be yourself and enjoy the moment you spend with these people. I want to say that being a good fit for the company does not only mean that you have a strong knowledge in Computer Sciences, but also means that you can interact with the people that you will work with - and this is a very important part of the interview.

Be prepared for all kind of questions that are not Computer Sciences related.

Common questions that you should be ready for are:

  • How do you like our product?
  • How would you improve it?
  • Do you have any questions about how the product works?
  • What would you like to do in the company?
  • Which project are you the most proud of?
  • Do you like working in a team?
  • What are your weaknesses? 
  • What are you bringing to the company?

At the end of an interview, you will often be asked if you have any questions. If you have questions, it’s time to ask them, if you don’t have any questions, don’t make up on quickly, because it is most likely going to be a bad one! 

To summarize:

  • Know the basics of Computer Sciences, even if you don’t use binary trees on a day to day bases, you’ll be asked to prove you know how they work. 
  • Pick a language and stick to it. There’s nothing worst than changing language every 3 months.
  • Only keep the things that you really know on your resume. If you’ve only used JavaScript once 2 years ago, don’t put it on your resume, because you will have to explain your interviewer your don’t know THAT much about it.
  • Don’t stress.
  • Practice on a whiteboard before hand.
  • Know about the company you’re about to interview with.

Interviews are like an exam. They need to be prepared days, sometimes weeks before the D Day.

So be ready ;)

Filed under interview San Francisco Linked List Binary Search Tree version control silicon valley