A week ago, I finished my first ever marathon with a painful time of 3:30:42. I’m ecstatic. It’s about 15 minutes faster than I hoped for, or a little more than ~30 seconds faster per mile than what I trained for. Despite that, 42 seconds is going to haunt me for quite some time. A lot of people have asked me what it was like, so I decided I’d write a recount of events of the whole thing from start to finish.



For some reason I wake up at 3am; an hour before my alarm. As I get up and change, I hear my roommate returning home from the bars which I find hilarious. I prep my breakfast of a bagel with peanut butter, a banana, and a blue Gatorade. I fill up my camelbak, put in my contacts, and hop on my Vespa to pick-up my bib from my work since they picked them up for us the day before.


I am told I should pick my bib up from the bus coming from LinkedIn HQ in Mountain View between Howard and Harrison. Well, I get there on time and low and behind, no one is here. And it’s still pitch dark. I’m not going to lie, I am a little worried that they are going to be late and I won’t have my bib in time. Like every other time I worry though, it all works out and the bus arrives 10 minutes later.


My co-worker’s boyfriend works right by the start line, so I decide to take up his offer of using their bathrooms before the race. I’ll skip the details, but two words: life saver.


I arrive at the RUN365 tent and I start to feel the nerves. There is an absurd amount of people here and the sun hasn’t even come up. I’m starting to get nervous about things like not hydrating enough, only having 3 hours of sleep, and whether I’m going to have to use the bathroom during the race. My official wave is wave 4 which had an average pace of 9:00 – 9:30, but instead decide that I’d rather start at the pace I plan to run, which is 8:15 – 8:45 in wave 2.


The first wave is off. I hop the fence in our private booth to jump in the wave and target the 3:45 total time pacing group. I turn on my marathon playlist that I made and start my Nike+ run tracker. I exit the gates 4 minutes later after the gun and think to myself, “well, here goes nothing”.

The Race

Mile 4 (The Marina)

At this point, I’m in the Marina chugging at about an 8:15min/mile pace. I’m still with the 3:45 pacing group and can’t help but notice that there are a lot of cute girls in my group and they are all super fit. But I didn’t sign up for this race to meet women. I signed up to cross this off my bucket list AND beat my friends’ times. I’ve been taking one shot block every mile at this point and start to feel more tired than I usually feel at mile 4. I assume it’s the lack of sleep more so than the faster pace.

Mile 5 (The Hill before the GG Bridge)

I don’t know what hit me, but my mentality changes from this point forward. I start going up the hill before the bridge and something in my mind clicks: I want to run faster up this hill than the pacing group. I have been running these hills for 2 months and feel like I can maintain my pace going up them. I slowly start to speed up and leave them behind.

Mile 9 (The GG Bridge)

Coming back over the bridge, there’s a slight downhill. I decide that I should try and take advantage of the grade and start to elongate my strides and run a bit faster. At this point, I am consistently passing people and the groups have thinned out significantly. Every water station, I grab one cup electrolytes and two cups water to save the water in my camelbak for the remaining hills/end of the race. I still feel tired, but I tell myself the hardest part is over and there’s a long downhill coming up.

Mile 13 (GG Park)

I don’t feel good anymore. The smiles for the cameras have disappeared and I feel soaked in sweat from head to toe. I’m doubting that I’ll be able to finish the race at this pace and I should slow down, but I don’t. I just tell myself instead that I’m halfway done and I just need to get through GG park to get to the flat parts of the race where I’ll be fine.

Mile 14 (GG Park)

My Mom and her fiance said they’d be here. At the mile marker, they aren’t here, so I assume they must be further down the road. My Nike tracker is telling me that I’m running at a 7:58 mile pace, so I now know I’m on target to be below 3:30 and keep trying to bring that time down as the race goes on. About half a mile later I see my folks. They aren’t ready at all and when I wave at them, they scramble out of surprise to take a photo and show me the big heads they made of me. I give my Mom a hug and then sprint back into the race to make up for the lost time.

Mile 15 (GG Park)

More hills! I can’t believe how many god damn hills there are in this course. I’ve run this part before, but haven’t since my last long run of 24 miles three weeks ago. Surprisingly, I see the fastest guy in my training group ahead of me who said he was going for sub 3:30 before the race. I walk up behind him and say, “I told you I’d catch you”, and pass him. Yeah, I know, I’m kind of a dick, but in my defense, I said to him that I might catch him later. I didn’t actually mean it when I said it though.

Mile 19 (Panhandle)

Holy balls, I’m out of the park! Thank god because I only have one pack of shot bloks left and my legs feel really heavy. Oh wait…no, I don’t have those shot bloks because they apparently fell out of your camelbak. I panic a little because I feel like they give me a huge burst of energy everytime I eat one. Most likely it is pyschological, but luckily I remembered there is a GU station coming up in the Haight and I could just grab some food/energy there instead.

Mile 23 (Potrero Hill)

I’m cramping up in my hammys and calves. It’s not to the point where I can’t walk, but it’s sharp pains that hit me sporadically. It doesn’t hurt for more than a split second, and I imagine I look like something is shocking me in the ass. I’ve eaten both my GUs at this point and figure I’m about to run out of gas soon. However, I’m counting down the miles at this point, telling myself I only have X left. Also every time I cramp up, I am verbally saying out loud: “mind over body” and “you got this”. There’s another hill coming up on 16th and I feel like my body is about to break down going up this thing, but then miraculously Journey comes on with “Don’t Stop Believing”. It is like Manifest destiny and I keep my pace going up the hill.

Mile 25 (The Ballpark)

This girl keeps passing me and I keep passing her. I’m not sure if we’re both ultra competitve or my pace is fluctuating up and down. I’m feeling the cramps more often now, and am willing myself to the finish line. I see a lot of people walking and two guys who are laying on the ground from exhaustion. Nike+ is telling me my pace is 7:52, but I know it’s wrong because the mile markers are about a quarter mile off. I am too tired to do the math in my head, but I think I’ll be before 3:30, which is now the new goal.

As I look up, I see a guy in the distance from my running program who I wanted to run with pre-race but his target time was too fast for me. I am slowly catching up to him until I finally catch up to him to say, “surprise, I guess I should have paced with you”. His response was, “damn dude, you’re fast”. We are passing the ballpark at this point and I ask if we’re going to beat 3:30 and he says yes. I am assuming he started in front of me, so I trust him, but I still feel like I have some more left in the tank.

Mile 26 (The Embarcadero)

The sun is shining, you can hear the cheers in the distance, and I know I only have the equivalence of one lap around the track left. I pretty much feel a cramping sensation in one of my muscles every 10 seconds and it sucks. As I get closer to the finish line, the cheering makes my adrenaline start pumping. What’s the most logical thing to do at this point? Well, it’s quite simple…sprint. Yes, I kid you not. I decide to sprint the last 200m of the finish line. I wish I had a video because I felt like that is probably one of the most physically grueling things I’ve ever done in my life and my face shows it.

The Finish Line

I cross the finish line with a half-smile across my face and slow down to a halt right after crossing. Well, immediately both my legs cramp up completely and I fall down to a crouch. I’m sitting there for 2 seconds wondering if I can get up, but a lady comes up to me and asks if I’m alright and that I need to move out of the way. I tell her ok and look up only to see someone wheeling a wheelchair towards me. I laugh and wave it off. Then hobble my way away from the finish line. Every step hurts at this point, I feel like my nipples were grinded with a cheese grader, and there’s a knot in my shoulder like I’ve never felt before. I stop my run tracker and see it’s 3:31 and I can’t help but think “dammit” at first, but I’m still really proud of myself. I grab a boxed water and coconut water and then proceed to get brunch with my parents after.


The question I always get is: Will you run a marathon again?

Right now there’s no specific race I want to do. I would say that if someone challenged me to one, I would definitely consider it, but I trained for more than half a year. That is an absurd amount of time looking back and I’m honestly glad it’s over so I can go back and pursue other goals of mine.

I will say that completing a marathon is no easy task. Qualifying for Boston is probably impossible. I’m glad that I can cross this achievement off my bucket list, and am greatly thankful for all the support I got from my friends and family. Looking back, there were countless runs I did hungover on Saturday mornings. Many injuries that I had to overcome from bad shoes and running too fast. I think what I learned the most from this race is that I can do anything I put my mind to. Whether it’s physically or mentally challenging, and I can only attribute that to the values instilled in me from my upbringing. If my family wasn’t all so god damn competitive, there’s no way I would have finished that without walking a bit. I now am the only one in my family to run a marathon and I’m pretty sure it’ll be that way for a while :). In closing, I just want to say once again, thanks all who supported me and I hope this blog post will inspire you to run a marathon in the future!

Wow! It’s been a little less than a year since I began my new career as a Software Engineer here at Slideshare. I’ve been meaning to get around to writing up a blog post about my life in the past few months, but just never got around to it. I spent a lot of time re-adjusting back to my life after graduating Hack Reactor in June last year, and then went 110% to make sure I did my best to not fuck up while I started my new career path into full-time development. Spoiler alert: It’s been pretty fucking awesome!

Life Updates

I’d say for a good 6 months, my work/life balance was a little out of whack, but I still managed to do some awesome things! Rather than go into the details, here’s a short summary:

  • Scott Bonebrake, moved in with me here in North Beach.
  • My 7v7 Men’s soccer team (Unathletic Madrid) and 11v11 coed soccer team (Ajax) won our league.
  • Some dude headbutted me while playing soccer in December and broke my nose.
  • Started training for the SF marathon this July.
  • Traveled to Boston, Vegas, LA, and Austin to visit friends and family.
  • Had an awesome three week vacation in South Korea and Malaysia with my #travelbros (FYI, we aren’t bros. We use the term ‘bro’ in a satirical way).

Work Updates

Okay, time to get into the section where I brag about my technical and work achievments this coming year. I think the majority of the people who read this blog are either my good friends or someone who has stumbled upon it searching for information regarding the success of graduating from Hack Reactor or bootcamps. I want to just confirm to all the people on the ropes that it was hands down the best investment I’ve made in my life, and I would make the same decision twice in a heartbeat.

I remember around this time last year, we were wrapping up HR and got a sense of everyone else’s coding abilities. I never felt like I was the strongest programmer out of that class despite the fact I came in with the most experience and background. However, I knew I was one of the hardest working, and looking back at my life, that’s something I’ve always been good at. I can hypothesize all I want of where this trait originated from, but my best guess is my father worked his ass off and my older sister was/is way smarter than me. In metaphorical sports terms, my sister is like Lebron James while I am more like Tony Parker. She is just naturally gifted, while I had to put in the time and effort to become the somewhat intelligent man I am today.

Over my time here at Slideshare, I’ve grown from a guy who was scared of stepping on people’s toes…to being one of the leaders on my team. We’ve grown a lot this year. Our office in SF has almost doubled in size and as shocking as it sounds, I’ve become one of the “old guys”. Figuratively and literally. I analyze every codereview, interview candidates, mentor new college grads, and even get my own intern this month (yay?). All while deploying (and fixing) features that get viewed by millions every day.

It’s quite exciting still and it’s a lot easier when your team is a great group of people to work with on a daily basis. Free lunch helps too. So does free sponsored events like Tough Mudders and Marathons. Seriously, working in tech is like being a spoiled child with endless access to candy. Thank god I have some self control to not eat Haribo gummi bears every day.


In my last update, I showed you my first big project I deployed. Well, since then, I’ve had even more success. For starters, I spent a good amount of time understanding SEO and sitemaps. This is probably an underlooked topic by most when it comes to the web. Mostly because it’s a big black box at Google with countless theories. For the non-technical, it’s like the “yellow pages” of your website for bots to crawl all your links. I spent a lot of time purging all the “bad links” from it to make Google stop hating on us.

Mobile Swipe

This is definitely my most exciting feature that took me a few months to build and perfect. We call it “mobile swipe”, but it’s our mobile web player that brings native swiping to all our presentations. It’s responsive and works on all devices leverages several JS libraries. So far the feedback has been very good and no matter where I am, I can show people on a mobile phone or tablet what I do here.

Edit My Uploads

This is my most recent project. I redesigned our “My Uploads” page to be fully responsive and given it a design overhaul. We added some additional functionality to upload a Slideshare directly to your LinkedIn profile, but for the most part, we just made the page prettier.

Last Words

I feel like if I worked at a large corporation, there’s no way I’d have this many successful projects under my belt in less than a year. Maybe it’s right place, right time; maybe not. One things for sure, I still plan to make a large impact on whatever I work on because programming is awesome and I would encourage anyone else to pursue it if you feel there’s a passion for it.


I bet you thought I was going to stop updating this once I got a job! You were * almost * right…

No, but seriously, I’ve been really busy since starting my new job and regaining a social life. It just feels like my life is balanced again.

Life Update

So I guess one would ask: Mark, what the hell have you been doing since wrapping up Hack Reactor and starting at Slideshare?

Well, I spent three weeks laying low and recharging my batteries after the 3 month marathon known as my tenure at Hack Reactor. Basically, a lot of sleeping in, a lot of socializing, and a good amount of reading Game of Thrones.

Now that I’ve started work, I’ve slowly started to get back into the groove of a schedule and it feels really good. I’m back playing soccer 2-3 times a week, finally gave in and joined Tinder, picked up my Vespa from my friend, and even joined a few tech meetups here and there. Despite having more free time compared to when I was at HR, I feel like I’m more busy than ever. Maybe it’s just the fact that I basically ignored my friends for 3 months and have been playing catch up ever since.

Job Update

Since most of my traffic comes from searches about Hack Reactor and referrals from other people’s blogs, I’ll get into the more important updates. I can truly say at this point that I don’t think I could have made a better choice for a place to work. It’s the perfect balance of cool people, cool projects, and opportunity to learn and grow.

It was slow at first fixing small bugs to get familiar with the codebase and trying to remember how to program after taking 5 weeks off in between. I had an orientation at LinkedIn down in Mountain View for my first day. Then the following day joined my team in SF where I was told to deploy on my first day. No sweat, right? Although I was basically a monkey taking directions, I was able to knock it out of the park.

What I’ve realized after 4 weeks of being a full-time programmer is the following:

  • There’s A LOT of code I didn’t write. I spend a good amount of time tracing functions/callbacks all over the place
  • The huge importance of writing tests to cover the previous realization
  • Thank god I know a decent amount of git and BASH
  • Pixel perfect designs are really important!!!
  • Mobile responsiveness and Google Analytics are critical things to have working properly

And on a less serious note:

  • I’m not particularly good at foosball when spinning is involved
  • Free soft drinks, beef jerky, and gummi bears are going to be the death of me
  • Perks at a big company are awesome
  • You do 20 pushups everytime your deploy breaks the site. — I’ve done 40 so far

My First Change

It took me a while, but my first “real” addition to the site is a share modal to share slideshows across your networks. My team is responsible for revamping the consumer experience for Slideshare, and we hope the new designs we’re rolling out will improve the browse and share the experiences for our logged in users. You can find my new modal by clicking the “Share” button on a presentation here.

Well, there’s the update for now. I’ll keep alternating between technical and non-technical posts in the future.

I’m announcing here that I have signed my offer letter and have a new job! Starting July 15th, I will be a Software Engineer for Slideshare/LinkedIn. Slideshare is an entity within LinkedIn, but their offices are located in LinkedIn’s sales office here in local SF. I’m ecstatic and excited about the opportunity as I will be tackling becoming a full stack + DevOps engineer.

Special thanks to everyone, especially Hack Reactor for helping me achieve my goal. It’s crazy to think 4 months ago when I started this blog that I achieved what I originally set out to do! Now that I have a job, I’ll be focusing on programming again and hopefully never have to apply for jobs again in the near future. My duties will include heavy Javascript and Ruby/Rails, with a strong emphasis on testing. So expect a lot of Rails posts in the future!

After going through so many interviews, I decided to blog about what the interviewing process is like for becoming a developer in this day and age. If you refer to my last post, I gave you the percentages of all the stages of each interview. Overall, I went through 30+ applications, 20 recruiter calls, 15-20 phone screens, and 11 on-site interviews. Clearly I am not great at interviewing as I received four offers total, but I do feel like I now understand the dos and don’ts of the interview process as a whole.

Stage 1: The Resume

The first step is to take your resume. Burn it. Then build it from the ashes. I’m joking, but old Word Doc resumes are out. “Adobe In-design” templates are in. If you’re not ready to pay for In-Design, there is an open-source alternative called scribus, which I used to make my resume here. I took two things into account when designing my resume:

  1. Attention spans are short. Less is more.
  2. Seeing something different will probably stand out.

Hack Reactor provides a lot of advice when creating resumes given the fact a lot of people don’t have a technical work background related to programming. Luckily, I had a formal education and a job that performed technical duties, but readability was my main focus. Using my resume as an example, it was structured to have the stronger sections at the beginning and end (skills & education), and then the weaker sections (work experience) in between. Some may argue my job is more important, but given the fact I did not do much programming on the job, I felt it less applicable, so YMMV.

Stage 2: The Application

This is straight forward. You want to send out as many applications as possible. At first I regretted doing this, but as most things go, things don’t always pan out for your first or second choice and having a backup is a good idea. I noticed cover letters were optional most of the time, but if there’s a box for it, always put a cover letter. I used a generic cover letter template that included the following:

  1. A brief intro of why I was interested in the position (1-2 sentences)
  2. A brief description of my skills and previous work experience/school (3-4 sentences)
  3. Links to my current projects I’ve been working on
  4. A note for them to refer to my resume for a list of my skills

What you have to realize here is that engineers (unless you’re applying to startups) are not the first person to read your resume. It’s a non-technical resource, so they are looking for reasons to filter you out, so don’t give them any.

Stage 3: The Recruiter Call

Depending on the size of the company, they may not have recruiters fielding this call, or may skip this call entirely. It’s sole purpose is for them to weed you out. Now, what I’m about to say is not indicative of what I did, but you could literally lie about or inflate your background/skills here. What I mean by this is the sole point here is to sell yourself to someone non-technical. They are gauging your background by looking for keywords and seeing whether or not you’d be a good culture fit. Luckily for me, I’ve had 5 years of consulting background where I was on the phone constantly, so I’ve had some practice.

Overall, sell yourself, but still keep it honest. Just don’t sell yourself short or speak negatively about yourself!

Stage 4: The Phone Screen

The purpose of the phone screen is to arrange a conversation between yourself and an engineer. The main purpose of this call is to gauge a candidate’s technical knowledge by having an engineer ask basic questions that every ____ engineer should know. The format is pretty straightforward. You can expect a 45-60 minute phone call, and possibly a second one given the size of the company.

The format is:

  1. Introductions for both parties
  2. Verbal questions from the engineer asking to describe simple web things that EVERY web developer should know
  3. 1-4 coding problems that are domain specific (algorithms, data structures, CSS, javascript, etc.)
  4. A period to ask questions about the job/company

This stage is heavy technically and less about selling yourself. Obviously, you’ll want to ask some interesting questions at the end to show you’re interested, but I’m assuming that is obvious.

Stage 5: The Take Home Problem

This stage could be substituted for stage 4 or given in addition. It’s what it sounds like though. An employer gives you a problem to code up in the language of your choice and submit it upon completion. These are usually projects ranging from 3-8 hours of work, and is pretty straight forward. A lot of times, the solutions can be found somewhere on the web, but it’s still best to do it from scratch.

Stage 6: The On-Site Interview

Congratulations! You’ve made it to the illustrious on-site interview. I could write an entire separate blog post about the on-site interview and how I don’t agree with it’s structure. However, there’s a good chance, most of my biased opinion is based on the bitterness that I was not very good at these. Here’s what I think will help calm your nerves about on-site interviews. They are simply evaluating two things: 1) How you think 2) Are you a good culture fit.

The format is pretty straight forward. It’s anywhere from 3-6 hours. You meet the team and have several 45-60 minute sessions with 1-3 people (usually just 1) where you chat, whiteboard, and/or pair program problems together. Some interviewers are really good and some are really bad. What you need to focus on is your plan of attack and that’s what I’m going to write about.

What you should do when you whiteboard:

  1. Take your time and think about it before you write anything on the board
  2. Draw a diagram of how your solution should work
  3. Figure out the edge cases first so you can plan accordingly
  4. Write out pseudocode so your interviewer knows what you’re thinking
  5. Write the actual code carefully
  6. Refactor your code, if possible

If your interviewer is good, he/she will help you along the way. If they don’t and you don’t know the answer, don’t say “I don’t know”. Literally, just sit there in silence and think or say you would normally use google.

Overall, it’s not about whether you get the right answer or not. It’s all about the process you use to get your solution and whether you have a structured approach. Programming is very structured profession with a lot of semantics that need to be followed, so just throwing shit at the board and hoping it will stick is probably the worst thing you could do. And I definitely did that a few times just to say something to break the silence. Basically…don’t do that and instead try to follow the steps I outlined above.

Best of luck, and feel free to email me if you have any other questions.


It’s been a while since I’ve blogged lately, but that’s because I’ve been knee deep in interviewing for the past three weeks and didn’t have much to blog about. I have one more on-site interview left before I wrap up all my job applications and then I’ll wait until I (hopefully) get an offer.

It’s been a very interesting journey so far applying for jobs for the first time since graduating college five years ago. What I’ve realized is times have changed and stealing a line from Mugato in Zoolander:

The Numbers

I’ll be honest, before I applied for jobs, I thought my response rate would be ~30%. Because of this, I decided to shotgun approach the application process and shot out 32 job applications and fielded a few recruiter calls as well. Overall, the results were pretty astonishing:

I guess I had the percentage right, but the outcome wrong. 72% of the places I applied to, gave me at least a callback, which also meant I fielded somewhere between 20-30 thirty minute (10 – 15 hours) phone calls total just to get my foot in the door. I think one or two declined a follow up, and others I felt weren’t a good fit so I politely declined continuing conversations. However, about 50% of all my applications proceeded with a technical screen or coding challenge, and 60% of those brought me on-site for an interview. Overall, that’s a total of 10 on-site interviews, but unfortunately that has not panned out into 10 awesome offers. That information is something I will not disclose publicly, but I’m optimistic that I’ll have a great job by this time next week.

So what’s the Secret?

Was it Hack Reactor? Was it my CS-related technical degree? Did my story resonate with employers? Or am I just a good programmer and never knew it?

I’m sure it was a combination of all of the above, but I’ll never know exactly. I definitely feel like being a developer in San Francisco is like being a Tickle Me Elmo 10 years ago around Christmas time. The supply is low and the demand is high, and honestly, quoting one of my teachers at Hack Reactor: “If you can write “Hello World” to a computer these days, you could probably get an interview.”

I plan to follow up with a blog post about the three stages of programming interviews and what was successful and what failed. After going through so many, I feel like you could potentially “cheat the system” by simplying preparing for the types of questions they would ask. To give some context, I was given “code Fibonacci” four times in four different interviews. Check back next week for another update!

Revisiting my MeetMeet web app, I thought I’d share the code snippet for configuring Meteor.js to work with Yelp’s search API. Meteor is still new and the smart packages are still being churned out every day, but one does not exist for Yelp search.

The Pre-Reqs

First things first, you’ll need a Yelp developer account first, which can be found here. Once you sign up and get API keys, make sure you take down the following:

  • Consumer Key
  • Consumer Secret
  • Token
  • Token Secret

Then login to your mongo database with meteor mongo and run the following statement:

Accounts.loginServiceConfiguration.remove({service: "yelp"});
  service: "yelp",
  consumerKey: "YOUR_KEY_HERE",
  consumerSecret: "YOUR_SECRET_HERE",
  accessToken: "YOUR_TOKEN_HERE",
  accessTokenSecret: "YOUR_TOKEN_SECRET"

This inserts the yelp service into the same collection as the other Meteor OAuth helpers. Nothing gets stored on the user account for Yelp, but it’s not good practice to have your credentials in source code.

The Code

I had to utilize Meteor’s built in OAuth1 helpers and a little trial and error, but the finished code is below:

yelpQuery: function(search, isCategory, longitude, latitude) {
  console.log('Yelp search for userId: ' + this.userId + '(search, isCategory, lng, lat) with vals (', search, isCategory, longitude, latitude, ')');

  // Query OAUTH credentials (these are set manually)
  var auth = Accounts.loginServiceConfiguration.findOne({service: 'yelp'});

  // Add auth signature manually
  auth['serviceProvider'] = { signatureMethod: "HMAC-SHA1" };

  var accessor = {
    consumerSecret: auth.consumerSecret,
    tokenSecret: auth.accessTokenSecret
  parameters = {};

  // Search term or categories query
    parameters.category_filter = search;
    parameters.term = search;

  // Set lat, lon location, if available (SF is default location)
  if(longitude && latitude)
    parameters.ll = latitude + ',' + longitude;
    parameters.location = 'San+Francisco';

  // Results limited to 5
  parameters.limit = 5;

  // Configure OAUTH parameters for REST call
  parameters.oauth_consumer_key = auth.consumerKey;
  parameters.oauth_consumer_secret = auth.consumerSecret;
  parameters.oauth_token = auth.accessToken;
  parameters.oauth_signature_method = auth.serviceProvider.signatureMethod;

  // Create OAUTH1 headers to make request to Yelp API
  var oauthBinding = new OAuth1Binding(auth.consumerKey, auth.consumerSecret, '');
  oauthBinding.accessTokenSecret = auth.accessTokenSecret;
  var headers = oauthBinding._buildHeader();

  // Return data results only
  return oauthBinding._call('GET', '', headers, parameters).data;

Input Parameters

  • search: Search term or category names
  • isCategory: Boolean stating whether ‘search’ parameter is a category
  • longitude and latitude: Latitude and Longitude of user’s location (optional)
    • Default location is statically set to San Francisco

You can use Yelp’s provided sample program to test your API credentials work, but if everything works, you’ll get back 5 yelp businesses as a javascript object.

SOON TO COME: An mrt package!

The Serious Side

Well, the day is finally upon us here at Hack Reactor. The dreaded job search! Dun dun dun dunnnnn.

It’s funny how it felt like only yesterday I couldn’t wait for this day to come. Now that it’s here, I am overwhelmed by how many companies are out there looking for good engineers. Rather than start the shotgun approach of applying to as many companies as possible, I’ve been spending the past few days cleaning up my blog and projects in preparation for “Hiring Day” this Thursday.

For the 25% returning visitor traffic (according to Google Analytics), you may/may not notice there are three (YES! Three!) new links in the sidebar.

I felt like it was time to put myself out there in case potential employers were interested in hiring me.

The Hilarious Side

Earlier last week, one of the co-founders of Hack Reactor sent out an email to us to discourage us from applying to jobs. I’m not going to include the entire email, but the email chain went like so:

And my response:

I received many accolades from my colleagues for this. But in all seriousness, it’s probably time to stop the jokes and start taking things a little bit more serious.

This weekend, we took some time off from the regular day-to-day and all went to a Hackathon called Angel Hack. I went in as a team of two with my classmate Philip, and our idea was to create a random recipe generator that integrated with Instagram. We felt that our idea was simple enough to finish in 24 hours, as well as, creative enough to distinguish our product from the other apps generated in the past.

Our whiteboard mocks the night before

Tech Stack

Due to time restraints, resource limitations, and it being our first Hackathon, we chose Meteor.js. Both Philip and I were familiar with Meteor and the single page app was necessary if we were going to build a mobile site.

The Beginning

We showed up at 9am at Yammer’s HQ on 9th and Market. The building is also Twitter’s HQ and it’s clear that Twitter isn’t the only one balling in that building. The first thought that came to my mind upon entering was A) What does Yammer do? B) How the hell do they make this much money?

There’s a mingle session where sponsors setup booths to encourage you to use their services. After briefly walking around and talking to the various sponsors about their APIs and listening to the prizes they had to offer, we decided to change our plan and use Pearson’s API. However, shortly after going down that road, we scrapped it and switched back to Yummly. Philip was front-end and I was back-end, and we collaborated throughout the afternoon developing side-by-side.

The Middle

Around 8pm, we ran into a brick wall with our original idea. We had all our integrations working and pretty much had a finished product without styling, but the Instagram search capabilities were lacking what we wanted to do. To give you an example, say you were randomly given the recipe “Amish Breakfast Casserole”. NO ONE on Instagram tags their photo with “#AmishBreakfastCasserole” unfortunately, and there isn’t a way to perform a Google-like image search using their API.

We quickly brainstormed for an alternative and thought we came up with our savior: Search for each word and create an Instagram picture-like recipe. For example, find the most popular picture for the terms “Amish”, “Breakfast”, and “Casserole” separately and display each one below the recipe. Once again Instagram’s API search capabilities fucked us and is only capable of returning recent photos instead of most popular photos for a tag. Although some of the photos made sense (and were somewhat humorous), some 12 year old girl who tagged her photo with a million hashtags ruined our search algorithm.

The End

The good news is we got to go home and sleep in our own beds. The bad news is we scrapped our idea and decided not to submit it for presentation. I will however, show you the screenshots of our stopping point below and the code can be found here.

Our actual screens

As you can see, we didn’t style the application, but would have made it look nicer if we decided to present instead.

Ten days ago, I embarked on my first balls-to-the-wall hacking experience and I’m pretty proud of the outcome. It’s a site I call (for now) “MeetMeet”, which can be viewed here.

We were given 4 days to work on our personal project, but over our one week break, I thought it would be best to get a headstart after looking at my list of features I wanted to implement. I think the main lesson I learned is that the term “MVP” does not stand for “MOST valuable product”. It stands for “MINIMUM viable product”. However, I think I have a fully (yet a little buggy) web app built in Meteor.js.

What the app does

This is an idea I’ve had for a while that I never had time to pursue. Originally, I actually wanted to make a native iOS app, but am now glad I made a somewhat-responsive web app instead. The amount of functionality built into 10 days is impressive by my standards, and I can only attribute Meteor’s intuitive and easy to use framework for it. Enough technical jargon. Let’s dive into the details.

Here’s how it works (and there’s a section on the site explaining this):

  1. Create an account
  2. Hook up your Google Calendar and Facebook Friends
  3. Select your meeting preferences
  4. Pick who you want to meet from your Facebook Friends
  5. Let MeetMeet auto schedule events based on ‘mutually anonymous agreements’ and free time on your schedule

A pretty basic and straightforward process that I can hopefully build more features for. I have declared it an alpha because I’ve barely had time to test it fully, but from what I can tell, it should work (knock on wood).

Anyways, it’s 12am now, I just deployed it, and I’m the last one here at Hack Reactor. Feel free to sign up and check it out.