1 November 2011

Subscribe to Engineering Growth

Stay up to date on new essays and updates on Growth Engineering.

You: a CS student looking for your first or second part-time job while in school, eager to try some of this ‘programming’ stuff in the real world.
Them: Somebody you're contemplating working for.
This: A list of questions you should ask to make sure this job is going to be a good fit.

Modeled after The Joel Test
  1. Do you already have technical people on staff?
    If you’ve never done web/mobile/whatever development before, being the first technical hire for a ‘business founder’ start-up is a mixed bag.  Especially for your first experience, having a qualified technical mentor makes a big difference for how quickly you pick things up and whether you learn to do things ‘the right way’ the first time around or not.  There’s a whole class of developers out there that have picked up PHP/Javascript from sketchy tutorials that get the job done but result in sloppy/outdated code.  

    Googling around is a great way to learn, but having a competent technical mentor point you to the right/best practice/reputable tutorials and explain things early on is the difference between having a piano teacher set your posture or a cursive teacher ensure your handwriting is legible early on.
  2. Who is going to be working directly with you?
    Before taking any job, meet the person you are going to be working with most directly and take them out for coffee.

    Culture fit: Software engineering attracts all kinds of people; talking to your future potential mentor helps make sure that the two of you are going to be compatible.  There’s absolutely nothing wrong with not being able to easily get along or fit with somebody, and you’d rather find out that you’re going to be the odd one out in a company now than have to deal with it for the rest of the semester.

    Mentorship experience: Has your future mentor ever been a mentor before?  It’s fine if they haven’t, but extra bonus points if they’ve gone through this process before.  Alternately, it really helps if the mentor has ever themselves been technically mentored by somebody - they know first hand what it’s like to be in your shoes.

    Ask: What worked well in your last technical mentor-mentee pairing?  What kind of issues surprised your or would you want to change when we work together?

    Eric, my boss for the past summer, started our first day at work by asking what I was hoping to get out of the internship.  This stumped me for a good fifteen minutes; it was a fantastic question that helped crystallize our professional relationship and help us structure our work accordingly - “Alexey, you mentioned you had hoped to get more exposure across the stack. Do you want to work on the CSS for the new page we’re building?”
  3. Will my code matter?
    One of the greatest joys of writing code is seeing your code ship and run in the wild;  having users benefit from your design decisions feels great. If at all possible, make sure the code you will be writing does that.  There are (at least) two reasons it may not: internal software or dead software:

    Internal: Joel Spolsky described the Five Worlds of Software Development almost a decade ago.  Internal software doesn’t have to be well written or engineered; it is typically written quickly and then left to (hopefully) still work.  There’s a ton of ‘internal’ or ‘good enough’ software in academia and start-ups, and being able to be good at writing prototypes or good-enough software is a useful skill; just make sure that it’s not all you ever do.  At some point, make sure you get to work on code that needs to be great and not good enough; the amount you’ll learn about software engineering and code readability is drastically different.

    Dead: Most start-ups fail; your code may never see the light of day.  Even at big companies, one of my friends from this summer had her project cancelled half way through her internship for unrelated reasons.  There’s no clear way to keep your code from being part of vaporware; the best that I can recommend is to follow your gut: does the project you’re considering joining seem like it’s going to happen with or without you, or is everybody living on a prayer?  
  4. Who had my job before?
    If your potential employer has had interns before, ask to talk to them about their experience for a reference check.  If a potential employer is trying to dodge the question of past experience, that’s a huge warning sign.  
  5. What are the expected outcomes of our work?
    You’re looking for two types of outcomes: first, a particular set of skills through the job, and second, products that you can point to and say “I built that,” or “I built this part of that.”

    What languages/frameworks/libraries are we going to be using?  Do my mentor/boss/co-workers know these technologies well, or are we going to be picking a lot of them up as we go? There’s nothing wrong with having to pick up something new, (in general, most every project you do will probably involve learning to use a new library of some sort) but having somebody on the team with domain-specific experience helps.  Make sure you understand what technical skill-set in particular you are going to pick up, and then check that the technology you are learning is the kind being used at the places you want to work.  As of the time of writing this, I’d personally recommend picking up some of [Android/iOS development, Coffeescript, NodeJS Ruby, Ruby on Rails and/or Python].

    One of your tasks as a CS graduate is to build a reasonable one-page resume/portfolio/github account showing off your credibility to potential employers for the summer or full-time.  Be careful not to spend a year working on a project you can’t ever talk about.  

    Ask: is this work I will be able to point to online?  Will I be able to show the source code to potential employers?  Are there any parts of my work that I can open source and stick on my github profile? The answer will be ‘yes’ more often than you expect.
  6. What is the format/schedule for this job?
    There are a couple possible schedules for part-time jobs, from the very rigid (coming into the office on specific days and working set hours) to the very flexible (“can you get this done by next week?”).  Which works best for you depends entirely on your schedule.

    For me, having set hours for working part-time (but not full-time) has been a huge help.  I’ve got enough things going on between classes, work and extracurriculars that if I don’t pencil in X hours a week for a particular activity, it’s unlikely to get done.  Working in a specific location also helps place me focus and helps avoid everyday distractions.  Plus, if you’re working for a start-up, they probably have free snacks.   In terms of days for part-time work, I’d recommend either one or two weeknights or most of Friday.

    That said, everybody is different.  It may be that you’re able to get your work done in part-time chunks throughout the week.  Regardless, make sure to speak to your potential employer about their propsed work schedule and try to understand their motivations.  An answer like “oh, we’ll figure it out” is a useful warning sign that the potential employer hasn’t taken the time to think through how exactly your position will work.
  7. How often will we have code reviews or pair programming?
    If all you do is write code until it works and then submit it, there’s no real mentorship going on; you’re just a part-time employee.  Mentorship means that you are getting feedback on your code consistently, if not for 100% of your check-ins then at least for a considerable fraction. Not every start-up can afford to do 100% code reviews the way that Microsoft, Google and Facebook can, but skimping on code reviews entirely is not acceptable.

    Alternately, pair programming with your mentor means that you get to ask questions during your collaboration and absorb the kinds of little tips and tricks that are mostly passed down through apprenticeship.  Best practices for pair programming as mentorship is worthy of its own blog post, but the one tip I’d have is make sure the mentee has the keyboard for the vast majority of the time.

    Code reviews or pair programming; potentially both.  If you’re getting neither, you’re not learning any more than you would be if you were working alone.
  8. How will I be compensated for my work?
    Programming work pays far better than most student on-campus jobs. Rates vary: I’ve seen lab work at as little as $8/hour, internships can go between $12-25/hour and your pay as a freelancer is bounded only by your imagination and what the market will bear.  

    That said, at this stage in your career I’d prioritize learning over compensation.  Even at a relatively high salary, the fraction of your college loans that the internship will ever pay off is likely to be negligible.  If your financial situation allows for it, I’d pick at least your first or second part-time job entirely based on how much better of a developer the job will make you, and worry about the money later.  Even if your sole focus is financial gain, a solid but unpaid internship pushes your lifetime value forward far more than a well-paying dead-end part-time job.

    The difference between a great and a mediocre job/internship is huge.  I learned more in 3 months at Facebook than I did in 3 years as a software engineer in the Israeli Defense Forces.

    On the flip side, the benefit of a paying job means that the company is invested in you.

  9. What if they offer equity?
    “Whatever they offer you, equity or salary, ask for the other one”

    I can’t find the source of this quote, but it reasonably sums up the best practice here.  The start-up is making a choice about compensation: whatever thing (equity or cash) they don’t give you is the thing they consider more valuable, and therefore the thing you should be more interested in obtaining.  

    I remember emailing a web-developer who was a mutual friend when I was starting out and offering to work together.  All was well until I offered equity ‘as compensation’.  I never heard back. Start-ups throwing around equity offers left and right in lieu of payment are a pretty good ‘tell’ for amateurishness, especially given how favorable the current climate is to entrepreneurs wishing to raise early-stage capital.

    In general, I think I agree with
    my boss from this summer, who basically considers the equity component of his compensation to be the equivalent of a lottery ticket - nice to have, but not to be depended on.

    There’s no hard and fast rule for whether to accept equity as early-stage payment or not, but ‘no’ is a pretty reasonable default. “Either pay me for my work or show me how I’m going to get mentorship from this position,” is not an unreasonable answer at all; don’t be afraid to use it.  For the less confrontational, a simple “I’d love to work with you, but I’m on financial aid and need a steady income” is a completely reasonable excuse.
That’s what I’ve got.  Am I missing anything?  Let me know in the comments.

PS. Should I work for this startup I just met that can barely pay and only has business folk on it so far?

Maybe.   Your goals for a part-time job should be to learn and to get paid, in that order.  No technical people on staff means you’re going to have to pick everything up yourself.  None or barely any payment other than equity means that you are effectively doing the work pro-bono.  The question then becomes: is this a better opportunity for me than
  • Working on my own side projects, or
  • Taking a research position / alternate internship?

The answer is a maybe.  If you are particularly passionate about the idea, or like me have a hard time focusing on side-projects that don’t have solid deadlines, and you can’t find an alternate position that lets you learn the same technology but get paid/receive mentorship, go for it.  

PPS. Where do I look for awesome Mentorship opportunities at Penn/in the Philly area?

Here are the places I know about.
  • Penn:
    • The Daily Pennsylvanian is looking for a couple of new faces.  I’ve written about this before - the pay is terrible, the responsibility is great, it consumes you and a year later you come out having your shit together and go on to work for google or start a company.
    • PennApps Labs, (which, in fairness, I’m affiliated with) just finished our mentee recruiting process.  We’re not actively hiring right now, but feel free to shoot an email to labs at pennapps.com if you’re interested and let’s chat.  We are comprised of former Facebook, Google and Amazon interns (amongst others) who care about student-run technology and the quality of our code.
    • Coursekit is starting a Hacker House on campus.  Dan and Jim, the technical founders, are competent and friendly like no other, and former CS TAs.  I’m very, very excited to see how their program will go.  Email dan at coursekit.com if the form doesn’t work for you.
  • Philly:
    • Devnuts is a Northern Liberties hacker space, and home to Jarv.us.  Again, I’ve written about (and helped) these guys before.  They appear to have a very well thought-out internship process.  
    • Indy Hall is another co-working space, this time in Center City.  A bunch of companies work out of there - I’d email their general ‘contact’ email and see who may be hiring.
    • Gabriel Weinberg of DuckDuckGo fame already has one of our interns, and he wouldn't mind another. Gabriel is a solid hacker and, I imagine, a great mentor.
PPPS: You should follow me on twitter, check out my Intern's Guide to the Bay Area and maybe consider Hosting a Hackathon at your school (and/or come to ours).


Tags: #advice #penn #recruiting-penn-engineers