How to get a job offer

Based on one hour session with Dylan from the senior class.

Dylan is one of the first in the senior class to receive and accept a job offer. He must have something special.

The employers looked at the following things:
– his personal project.
– his group project
– his personal website.
– his GitHub profile

Personal website:
– His website is fantastic. Hence, whenever the employer wants to see the portfolio, he sends the website to impress them.
– It has to be responsive. Employers would literally resize the window to check.
– A good model is alexpaley.com

Personal projects:
– Working and pretty/presentable
– Not necessarily the most complicated project
– The other extreme is the technical challenging ones, such as building a WebRTC framework or build a REST interface to Mongo(?)

Group projects:
– Understand all the code other people wrote.
– Implement a couple of design patterns such as observer or mediator in the project.
– Make sure the code is nice / clean / presentable to employers

GitHub profile:
– Activities are important. Similar to your undergraduate GPA, it is hard to cheat on your commit activities.
– Showcase a couple of the projects

Other recruiting channels:
– AngelList
– LinkedIn (change your title to software engineer)

High level thoughts:
– 50% technical details
– 50% like-ability

Practical stats:
– all interviews coming from hiring days
– 5+ onsite interviews with more voluntarily declined
– To nail the 5 minutes speed dating in hiring day, be personable, smiling. A lot of conversations end up being non technical. Don’t underestimate the people you meet since he might become your biggest advocate inside the company.

Phone interview:
– 50% tech depth
– 50% personable

Onsite interview:
– 3-4 hours each, one hour per person
– All coding on whiteboard
– Talk through the coding process
– Practice writing code on the whiteboard
– Be proactive. Reach out and not necessarily aggressive.
– When struggling, don’t get frustrated. Ask for help.
– After making a mistake, admitted it.

Other thoughts:
– Meteor.js is cool to know. However, it is so new and so powerful that few companies are using it in production. Also, employers might not take you seriously if you build a project with Meteor. Meteor is definitely the go-to weapon in a Hackathon.
– When asked about the expected salary. First, avoid giving a definitive number, saying “average market rate / what is competitive”. Second, if pressed again, referring to a high anchor point, “Peter in our previous class got an offer of $125k with signing bonus. While I don’t expect your company to offer the same salary, it does give us some range to think about.”

Common interview questions:
– Write SQL to join two tables
– Explain CSS box model
– Promises
– Implement promises in jQuery without using .done() or .success()
– jQuery events
– Make a drag & drop modal without using any library. Hint: mouse_down -> mouse_move -> mouse_up
– Backbone
– Some angularjs

May or may not be true:
– People likes Ruby but don’t like Rails
– CoffeeScript is ok

Example – what is the output for the following program:

var a = 8;
alert(a);
var f1 = function(){
  var a = 7;
  alert(a);
  var f2 = function(){
    alert(a);
    var a = 6;
  }
  f2();
}
f1();
Advertisements
Standard

Day 38, Meteor.js and event systems

Today kicks off the semi optional Meteor sprint. I have used Meteor.js to build my personal project: replay.meteor.com, hence knows the basics. It only took my an hour to finish most the basic requirements and I then moved on the client project.

For the client project, I finished several things today:
– Handlebar templates for the two pages
– Convert the CSS to Stylus (http://learnboost.github.io/stylus/docs/js.html)
– Put some dummy data in and did a proof of concept collection-view binding

Many other things happened today. One is that my college friend Shanshan came over to visit the school. The other is Marcus taught us on how to write an event system. The last one is Dylan taught us on how to prepare for interviews. It seems like they will be separate blog posts.

Standard

Day 37, MySQL it is

After debating for another several hours, MySQL it is.

There was a guest lecture on Angular.js. I don’t know enough about it because I am very invested in Meteor.js 🙂

Why Angular?
– To build single page apps
– It is maintained by Google so it won’t go away (well, Let’s ask some other folks. Can you hear me, Google Reader? Oh, how about Google Wave? Oh….)

Some quick notes:
– ng-app
– ng-model
– ng-repeat
– ng-click
– ng-submit
– It watches variables(?)

<ng-model ="name">
{{name}}

– dependency injection. Sounds like a double-edged sword to me…

Anyway, definitely should give it a try for a small side project.

Standard

Day 36, Parse or MySQL

Today is the first day of our client project and we spent many hours on debating between Parse or MySQL

Sprint reflections:
– People don’t like the way how client projects were introduced
– Marcus expressed that he really wanted to include authentication as one sprint but just could not find a time.

Standard

Day 35, memories

Have to leave all my old friends behind and rejoin the classroom. Now, back to work.

Notes on working on a client project:

Good projects are:
– under promise, over deliver
– many touch points including face-to-face, Skype, email

Bad projects are:
– No communication through out
– Big bang delivery in the end
– No hardstop
– Leaking client information on the blog

Advices are:
– Do NOT skip the regular check-in
– Be transparent about the progress

Before the kick-off meeting:
– Prepare questions

During the kick-off meeting:
– Take notes
– Try getting everything you need to kick off the project
– Try leverage the 30mins or 45mins effeiciently

Possible Questions for the kick-off meeting:

Tech/workflow
– Fork/pull vs branches
– Ticketing system
– Stack choices
– Web / mobile
– Third party integrations such as Stripe, Twilio or MailChimp

UI / UE
– Types of users
– User stories

Others:
– Business model
– Business roadmap

Standard

Day 33, Sinatra

Magic!!!!!!!!

That is what I am thinking all the time. I thought Ruby itself has enough magic, I was so wrong! When I say magic, I don’t mean anything negative. Please refer to this quotes – “Any sufficiently advanced technology is indistinguishable from magic.”

ActiveRecord:
– ORM
– generates many methods for you, such as model.findall_by_column_name
– amazing feature set. Used as a model for many other ORMs
– many Ruby frameworks use ActiveRecord

Sinatra:
– lightweight compared to Rails; JavaScript equivalent would be Express(?)
– used for a CRUD application with medium level complexity
– Rails would probably be a better choice for more complicated applications with a lot of user interactions and page by page navigations
– not sure about which site has the largest scale Sinatra App

Standard