Capital One People & Money Hackathon

Capital One has definitely moved all the way up there in my book for being a cool and innovative bank for sponsoring such a kick ass hackathon.

Here are the challenges:

Screen Shot 2015-03-08 at 7.35.12 PM

Our team originally planned to build an app for millennials to help them save without really thinking about it or doing much. After surveying people around the neighborhood waiting for brunch and shopping at Whole Foods, we learned that millennials are either already saving religiously or just can’t/don’t save. (Read: They either wouldn’t use our app or didn’t need to.) We did learn, however, that 70% of the parents we interviewed who have trouble saving really wanted help with saving for their kids’ college tuition. So we pivoted from helping millennials save money to helping families kick their fear of finance.

The Team

IMG_5865
Left to right: Chao, Adam, Will, Brian, David. Guess where I am. We’re missing Mike :(

Adam: Experienced back-end developer
Chao: Amazing designer – close friend and colleague of Will’s
David: Awesome designer/Research
Jenny (me): Back-end developer – since I worked on the front-end last hackathon
Justin: Strategist/Research – Product Manager by profession
Mike: Strategist/Research – Finance expert (not in picture)
Will: Android Super-Ninja – Boss by profession

Genius Fund (http://geniusfund.instapage.com/)

marketing_screenshot

The Android app we built has a beautiful UI/UX designed to be like a fitness tracker focused on maximizing the user’s motivation to consistently hit their saving goals every day. We utilized the LevelMoney, Nexmo, and Plotly API’s. The back-end is built with Node.js, with pieces of pubnub, plotly, and many other things here and there. We are one of the few, if not only, team that built an Android app, which probably helped with us standing out.

Things We Tried to Do

Adam and I wanted to use Parse in the beginning so that we can have a cloud based app and wouldn’t have to use Heroku, but we ended up using Heroku because we already knew how to use it. I tried to integrate Pusher that I learned to use at Makers Academy and then PubNub that a senior dev recommended I check out, to get real time transaction updates, but it didn’t really work out. Plotly was successfully integrated by Adam, but we couldn’t it get looking beautiful, so we decided to not show that. We also planned to use Redis and MongoDB, but experience has proven that hackathons are great for making you choose what’s nice-to-have and what’s need-to-have. Though we learned a lot and were lucky to have a chill team, sticking to doing a few things with fewer tools as awesomely as possible is a more likely recipe for success.

Advice to Hackthon-Goers

  •  Justin and I rehearsed over 20 times starting 2 hours before our demo and got a consistent 2 minutes 45 second timing. Our presentation ended up getting to 5 minutes and we didn’t even get to do our super cute team high-five+knee-pop that we rehearsed. I cannot stress rehearsing and expecting your demo to take 1.5 ~ 2x the canned rehearsal time enough.
  • When unsure of which languages or tools to use, go with the tools the more experienced programmer(s)’ expertise.
  • Have a designer. Even better to have 2. Seriously. I read on a blog somewhere while researching for my first hackathon to join a team with a designer and this advice has held very valid for both hackathons I’ve attended.
  • At least skim over the API’s even if you have no idea what you’re doing or looking at. Both hackathons I’ve attended had more than 5 API’s + tools involved. Though you don’t really know which ones would be relevant until you form a team and have some sort of idea, the more you can prepare ahead of time, the better off a start you’re at, of course. I’m already a newbie, so I can’t afford to be even more behind by neglecting my due diligence.
  • Make an account on the platform the hackathon provides for finding team mates early. I filled out my profile and information as much as possible. Photo is a must; skills for sure. It shows you care. Obviously.
  • A strategist/PM reached out to me 1-2 days before the event. I ask if it’s okay if I’m a junior developer, and they always say, “Not a problem at all. We’re all here to learn and make new friends.” Deniz, from my first/previous hackathon reached out to my 2 days ahead of time; and Justin, reached out to my the day before. They were both incidentally the only PM/strategists that reached out to me. I always joined their team. Joining the PM that reaches out to you, alone, may be a good enough sign you’re going to have a good time.
  • I’m new at programming, but I’m not ashamed or sorry about it. Be open about it and if people don’t look insanely busy or stressed, ask questions and ask for help. We’re all here to learn, and I realized that I actually taught some of the experienced engineers I worked with something new.
  • PAY ATTENTION. Check important links immediately, and write important shit down. Don’t assume all the slides and information would be provided for sure. For example, the other team who shared the co-working space after 9pm with us totally panicked when they couldn’t find the API link that they wanted to base their whole app on on Saturday EVENING. The link on the handout didn’t actually link to the API. It was briefly presented at the kick off of the event, and I was the only one who noted it down in both teams. Someone even asked if the kickoff slides would be shared, after they realized they neglected to note some pretty important information like API keys and how to access the non-public API’s, and the organizers said yes, but I’m still totally unaware of how or where those slides are shared.
  • Devs, don’t be precious with your code. There were no problems on our team, but it seems the more precious people are with their stuff – be it code, designs, names, features, ideas – the harder time they have when pivots are made. And there are always pivots. Always.

Unimportant Important Stuff

  • Nexmo t-shirts are top-notch. Do not pass up a chance to grab one. THEY. ARE. SO. SOFT. The design is great too. I feel more cool than like a walking billboard.

    IMG_5858
    Shirt says, “I would change the world …if they’d only give me the source code.” Props to Tim and Nexmo!
  • The food Capital One provided is also top-notch. Best food I’ve had at a tech event. Thai food for the kick-off on Friday. YES ASIAN FOOD. I ate two plates and forgot to take photos. Anything that isn’t pizza and beer just makes me really happy nowadays.
  • PCH has an amazing space. Front cafe is across the street and the outdoor space is fantastic.

Pics or they didn’t happen:

IMG_5837
Italian dinner for Saturday night
FullSizeRender 2
Finished affogato from Front Cafe
IMG_5848
Look at this majestic office pch provided.

Experience & Thoughts

I’m not exactly sure why I’m always so lucky. First hackathon, amazing experience. It made me want to go to MORE hackathons as soon as possible. This hackathon is my second, and yet another AMAZING team.

I worked on the front-end at my previous hackathon, so I thought it would be good to pop over to the back-end side this time. Trying to work with Will to build an Android app may also be biting off more than I can chew, but getting some exposure to Node.js and learning from Adam was manageably challenging.

Having many Capital One people at the event was extremely helpful. Ron Secrist (like Ryan Seacrest), Toby Russell, and Lin Yang was essential to the insights we came up with for building initial idea and pivot. It was also a great feeling to know that there was someone from all the featured technical partners with featured API’s. I particularly enjoyed speaking with Tim from Nexmo and Gregor from LevelMoney.

Some of the API’s were still in development, and I noticed a lot of engineers struggling to figure out which API(s) to use. I met one engineer who was trying to figure out which API to use Saturday morning. It would have also been really cool if we could:

  • make some transactions and move money around
  • more/real data – we couldn’t use our personal accounts even if we were willing to; we integrated plotly but because of the limited data, the charts didn’t look that cool
  • work with more banks – not everyone uses Capital One
  • allow us to create some fake user accounts – so that we can perhaps involve money and people, since it is called the People and Money Hack

This hackathon is not an all-nighter style hackathon, which I am thankful for, and it worked out alright. We just went to co-working spaces after 9pm, which PCH closes, so that worked out pretty well for our team and one other team. Another way how having social, personable team members provided a very practical advantage. We worked until 2am on Friday and 12/1am (daylight savings!) Saturday evening. This helped the team well rested and fresh the whole time. :)

 

Results are going to be announced soon – gotta go!

 

Update:

We won 2nd place for Kicking the Fear of Finance!!!

1st Place for Money for Millennials: Sway – SO AWESOME. Should definitely check this one out. His presentation skills were on point, too.

1st Place for Kicking the Fear of Finance: SaveSense

Didn’t catch the second place winner for Kicking the Fear of Finance, but I feel honored to rank amongst these teams and individuals and humbled by what these teams have built over the weekend. I’m pumped for my next hackathon!

Accelerate SF Hackathon

This weekend, I attended my first hackathon to kick off Developer Week 2015 in San Francisco.

The Dealio

I’m attending Developer Week and this hackathon came with the package.  The are a whole bunch of sponsors, API’s and tools that we are encouraged to use. I skimmed through and looked up many of them, but it’s really a lot.

Thoughts

I feel so lucky to be contacted by Deniz, a very welcoming Swiss guy who also brought this designer friend, Jonathan, to the hackathon. I asked if it was okay that I’m a junior developer and he says it’s totally fine. He and another junior developer had already planned to work in Python, Django and MongoLab, so if didn’t mind, then he said everyone’s just here to make friends, have fun, and maybe build something. His team was already more than 5 people, so they won’t/can’t go for the prizes. This is exactly the kind of team I want to be on.

Though it seems to make most sense to most people that finding a team that wants to use languages and tools that one is strongest is in, I’ve always followed people. So I didn’t care that we were going to use languages and frameworks I’m completely unfamiliar with, I knew with this guy and this team, I could just focus on trying to add value where I can, rather than worrying about being good enough or possibly dragging the team down. I had a hunch that I would be able to just enjoy my first hackathon and take from it what I can.

First impressions: The amount of women I saw at the hackathon was quite delightful. Yes, all of the tech community’s effort to get more women in tech is working! Now we can work on having them stay in tech!

The Team

left to right: Deniz, Camille, Ali, Vee, me, Jonathan
left to right: Deniz, Camille, Ali, Vee, me, Jonathan

Deniz and Ali worked on the backend with Python, Django, and MongoDB. Ali is a junior dev and Deniz has had experience coding with those languages and tools before

Vee and I worked on the front-end working with JavaScript, CSS and HTML. I would also take care of git and integrating the back-end and front-end.

Jonathan is our designer. I’ve read on multiple blog posts on hackathons that a team should have a designer. Jonathan’s a great designer and it made Vee and my work way easier.

Camille is Jonathan’s girlfriend who tagged along to see what building a proof of concept looks like and she was our researcher and analyst that typed up the information we would be putting on our website.

TripGo

Our app is an itinerary builder that helps someone plan a trip based on the number of days they would like to spend at a destination.This is business idea Deniz would like to build a proof of concept for and potentially explore after the hackathon. Vee and I worked on the front-end together with our amazing designer, Jonathan, responsible for its beautiful design.

The homepage:

TripGo

The Results/Itinerary page:

TripGo2

The backend is python and MongoDB.

Here’s a video demo:

I wasn’t sure what to expect for my first hackathon, but this turned out to be an amazing experience. I’ve read a few articles about the frustrations of women attending hackathons and how stressful they could be sometimes, but this turned out to be more than I hoped for. Not only did we build something I’m pretty happy with in such a short time, our team has really bonded with one another as people, too. We all exchanged phone numbers, added each other as friends on Facebook, and made legitimate plans to hang out together after the hackathon. We already took a fro-yo break during the second day and met all the team members met the significant others of team members with a significant other. Ha!

Update:

We won a $50 Amazon Giftcard from MongoLab!!

We’re all having dinner with our prize next week! :)

What is this Redis creature in my code?

Since coming back to NYC last week, I’ve fallen ill TWICE and so I ended up sleeping and watching NetFlix a lot in the beginning. A friend from my high school, Robert,  reached out for some help on his non-profit organization, RescuingLeftoverCuisine, in the mailing list I subscribe to and I reached out to see if I can help out and get some coding practice in. When I learned more about the program, could you imagine my glee when I learned the codebase is in Ruby and RSpec? I was like

Laughing-Baby

After I cloned the code from Heroku, the first thing I did was try to get the tests running and followed the errors messages until I got the tests green.

The first problem I ran into was not being the original developer and being unable to create a database. I reached out the original developer for help on this as I wasn’t making much progress trying to figure it out on my own. He told me to look in the database.yml file. Lo’ and behold, his credentials were there. I checked my old projects to see if I had a database.yml file and gather some more pieces to this puzzle. I ended up deleting the two lines with his email and password and I got a different error. Progress! …I think. I will run this by him when we meet up.

Databases can now be created and migrated. I ran into some issues, so I did the bin/rake db:drop, create, migrate dance and things started working.

I was finally able to run rspec, and this “Redis” thing was breaking most of the tests. So I investigate and employed my shiny new code-problem-solving skills Makers Academy dug out for me.

I found these helpful articles on openmymind.net: Redis: Zero to Master in 30 minutes | Part 1 | Part 2 |. It turns out Redis is a key-value data store, which can be thought of as a data structure engine, according to openmymind.net. I was also delighted to learn that Redis is the most popular key-value data store and sponsored by Pivotal Software, because Pivotal is a company I also have my eye on applying to! Very cool.

After spending some time to understand Redis and the role it plays in the code, I took a look at the Gemfile. I was happy to see many gems I’ve worked with at Makers Academy in the app as well as a bunch of gems I am completely unfamiliar with. I’m excited to be meeting the original developer soon to tuck a few more gems under my belt!

programming

MA Day 59: Graduation & Bunch is now live!

‘Raduation Day. I am so happy with our team’s final project. We spent most of today perfecting and rehearsing out presentation. Our app totally works live on Heroku after only 2 weeks’ work. I am happier today than my college graduation!

Here’s a full video demo of how Bunch works:

It works and everything on Heroku: bunch-us.herokuapp.com Check it out! :)

 

No time for long blog post. Thanks for the amazing ride, everyone! :)

How to Kill It

During lunch the day before our graduation, Ali gave us an awesome on How to Kill It After Makers.

He says that the wildly successful people he’s encountered in circumstances similar to ours shared these traits. He broke this traits and tips into two parts: before & during Makers Academy, and post-Makers Academy.

Before & During Makers Academy:

1. WORK ON SMALL, FINISH-ABLE PROJECTS.

Keep the habit of shipping software regularly on GitHub. This can also serve as a constant way of applying newly acquired knowledge. But be sure not to be overly ambitious and let that stop you from shipping. Go from something simple like printing ‘Hello Word’ to making your program do more sophisticated things. Check out Jennifer Dewalt’s 180 websites in 180 days for some inspiration!

2. WRITE REGULARLY AND PUBLISH.

This should be work related and technical. Julia Evans writes 200-300 words a day for her blog: https://jvns.ca/ I guess I’m semi-on-top of this since I’ve been running this blog. I need to try to get more technical though.

3. HAVE VALUABLE IDEAS TO SPEAK ABOUT AT EVENTS AND MEETUPS

Speaking at meetups is a great way to build credibility and <secret tip> the bar for speaking at local meetups usually isn’t that high, but you look like a total expert regardless </secret tip>. It doesn’t need to be something you know extensively about, but anything you can talk about for about 30 minutes would be sufficient.

4. MEET PEOPLE AND CREATE A NETWORK OF PEOPLE WHO HAVE YOUR BACK.

Do this by attending meetups and keeping in touch with people you’ve worked with and staying in the pulse of things so that you don’t miss out on unpublished opportunities.

Getting a Job

1. COLLECT A HUGE LIST OF LEADS.

Just anything under the sun that you would be remotely interested in. Bookmark them and have a huge list. Not many companies advertise junior roles, so just mention it when you are networking to collect leads. Inbound leads and leads through your network are the best.

DO NOT USE RECRUITERS.

I asked Ali about in-house recruiters and they seem to be okay, but having a recruiter or recruitment agency as your main source of leads is like slowly sitting on a very long, thin pole. They are incentivized against your interests and would probably hurt more than help you AND the company you’d like to work for.

2. DECIDE WHAT’S IMPORTANT TO YOU, REALISTICALLY.

Big company vs small company? Big vs small tech team? Go somewhere where there are dev slightly better than you. Think about your learning goals and skills development. As junior-juniors, it’s quite important not to develop nasty habits at companies that don’t know what to do with a junior. But money might be an important factor for some people while other care most about location.

3. SEND OUT CV AND COVER LETTERS.

Be sure to have JUNIOR DEVELOPER SEEKING EMPLOYMENT highly visible on your CV. Show shipped software on GitHub, then education, then maybe nice things other people have said about you if you have two pages. For an American CV, there’s probably only room for the first two things on one page. Cover letters should cover big topics and questions such as how you might add value as a junior or some sort of critical understanding of the company you’re applying for.

4. GET INTERVIEWED.

First there’s fluff, and people are just trying to see if they like you. Then there’s the technical challenge which is usually the majority of what dev interviews are made of. A good way to start is usually to repeat their question back to make sure you understand what it is being asked of you. Ask to clarify assumptions and ideas rather than starting to type code immediately. This behavior is a major red flag. Don’t be afraid to say “I don’t know… but maybe I would look into this/that” or “I don’t know, but could you tell me about it?” If they refuse to tell you about something you don’t know, it’s probably not a stellar company for a junior dev. How can you be expected to know everything after 3 months?

Be prepared to ask them some questions. Some generic starters: What are you working on? What’s the best/worst thing you find about working here? Who do you report to? What’s the culture like?

5. NEGOTIATE SALARY.

 Have 3 offers. Ask for £36k. Ask companies to wait a little bit longer for other offers to come in so you can choose the offer you want and 3 is a good number for you to be happy with the choice you made. If you don’t have 3 offers on the table or can’t afford to wait, ask for £36k. This number is for London. But the point here is that companies hiring a junior dev can definitely afford to pay £36k and you need to ask for that number if they don’t offer this to you. Just email them and say you need £36k and don’t make a move (i.e. cave) until they get back to you. It also doesn’t hurt to negotiate because the worst they can say is ‘no’ and you are back to where you started. It’s not like your offer goes away because you asked for more money. And if they say yes to £36k when they initially offered £33k, then a single email made you £3k.

If you find Ali’s advice here as helpful and enlightening as I did, then check out his free e-book that you can download at Happy Bear Software: https://happybearsoftware.com/kickstart-your-developer-career.html

MA Day 58: Dynamic JavaScript Input Boxes

Last day before graduation! Look at our Trello board with everything done!

Screen Shot 2014-09-11 at 6.39.56 PM

I’m spending today getting the tests that my automatically appearing input boxes are breaking.

Implementing the functionality wasn’t all too difficult, though I still had some help from Alex, because things never work the way I think they would or should. The functionality was there by the time I left Makers yesterday evening. I first had the new automatically-generated input boxes show up in 100% opacity because I had broken about 6 tests. Not too bad. I just went in and fixed the cucumber tests one by one and it was basically taking out the step that involves clicking a “+” button and going ahead to the “fill in next address” steps.

Then, when I wanted to make new input boxes semi-transparent until they were focused on (to be typed into) before having 100% opacity. I did this by making a ‘waiting’ class for the input box that is ‘waiting’ to be used. The waiting box will have semi-transparency until it is focused on and .removeClass() is used to make it just a regular input box, giving the next automatically-appearing input box the ‘waiting’ class.

Screen Shot 2014-09-30 at 1.01.19 AMLook at how sexy this is! (Address 3 is where the input cursor is currently.) Give it a go at http://bunch-us.herokuapp.com/!

During lunch, we had an amazing talk from Ali on How to Kill It After Makers. It seems he has given this talk to Makers a couple of times and always received great feedback.

Then all the groups had a dress rehearsal of their presentations in front of the junior cohort and other teams. I was pretty happy with our team’s dress rehearsal presentation and I think it can be quite polished by graduation. :)

Improving Communication

Pivotal Labs hosts a series of fantastic tech talks every Wednesday, and I attended one given by Margaret Pagel, Vice President of Sales Marketing at 8th Light, on Improving Communication. Margaret shares with us her advice on being a good communicator from her careers in sales for 15 years. She covered five main points on building a human connection and making people remember us. Her slides were absolutely beautiful, and I learned after the talk that they were all done by a UX craftsman at 8th Light. The images I’ve put in aren’t the slides she presented, but pulled from a similar talk of hers hosted on YouTube.

Screen Shot 2014-09-30 at 3.25.53 AM

Have 5 key points for small talk about yourself that is likely to be relatable. For Margaret, she introduces herself as a mother of 3, working for her son at 8th Light, living in Florida but working in Chicago, a widow, a huge Green Bay Packer (football) fan. So she talks about family, work, travel, tragedy, and sports, and these are points that people can resonate with at least one of them and she can use start building the foundation of a connection with. So think about stories that are yours, that you’re comfortable telling, that people might be able to relate to and like you.

Screen Shot 2014-09-30 at 3.27.18 AM

Talk about your work and what you do passionately. Know and be able to communicate the value that you can bring clearly. Be able to show you know what your talking about with making recommendations and talking about previous work you’ve done. But building trust and relationship requires patience and takes many small steps over a long time.

Screen Shot 2014-09-30 at 3.28.58 AM

As the talk was for predominantly software developers, Margaret talked about how non-technical people might feel, when developers start talking tech. This is important because chances are, clients are non-technical, because otherwise they wouldn’t be hiring software consultants! So talk about and explain technical terms. Make sure that people in the room who are non-technical, and even those who are non-technical, understand what you’re talking about. It might be helpful to practice talking about a subject to a spouse or friend and work out how to get those concepts and ideas drawn out.

Also, speak up when there are problems or confusion. Ask someone to explain back to you what you’ve just said for a confirmation of mutual understanding, so that you can work on bridging any gaps.

Screen Shot 2014-09-30 at 3.29.14 AM

Margaret talked about facing problems head on when encountering turmoil or calling somebody to get a problem fixed without letting it fester. If the problem involves not meeting a commitment with a client, be sure to keep them in the loop and have them know what’s going on every step of the way. Admit your mistakes and apologize. Be sure that your actions speak louder than your words.

Screen Shot 2014-09-30 at 3.29.56 AM

Make an effort to stay connected to people – calling, asking to meet up face-to-face, taking someone to lunch or breakfast, and remain fresh in people’s minds. Margaret did this by spending time every single month to sit down and wrote a thank you letter to every single client and prospects. She would also include a chocolate bar and send them to everyone and when she would attend conferences, people would ask her she’s ‘the candy lady’, and that’s how remained memorable and fresh on people’s minds.

Good communicators, live it. They live their lives centering around great communication and maintaining these human connections.

MA Day 57: Fancy Input Boxes

Today is our feature freeze. This means no more adding new features and working only on styling and cleaning up code. Our team is right on schedule and we paired on adding some unit tests to up our test coverage and refactoring code where we see fit.

I’ve been trying to get some fancy input boxes since the beginning of the week, and see this as the perfect window to get that in. Basically, when someone goes to the bunch page and starts to enter addresses into the input boxes after the second one, another input box will automatically slide down and be semi-transparent. This would make a much nicer user experience that is sleeker and more impressive!

the_important_field

My team wasn’t so supportive of me trying to add this styling though. Implementing this styling would definitely break a lot of feature tests since the tests ran by clicking a button to add a new input box, and our entire app was dependent on those input boxes working properly. I understood their concerns, but I knew this was the right thing to do and knew that if someone helped me, we could do this and get everything done, with tests passing, with time to spare tomorrow. But my team didn’t seem too interested in working on this, so I would have to do this on my own if I really wanted it. So I asked if I could figure out how to make it work, if they would be cool with it, and the majority said yes, so I have to get crackalackin’!

In the afternoon, I attended one of the fantastic tech talks that Pivotal Labs hosts every Wednesday. This week’s talk was given by Margaret Pagel on Improving Communication.

After lunch, each team did a rough presentation in front of Alex on our final projects for preliminary feedback. Our team got a rough presentation put together and the basic flow of who does what, in what order. Charlotte will introduce our app, I will narrate a demonstration of how Bunch works, Jeremy will talk about the algorithm and backend of the inner-workings of how we churn out our results, Pete will talk about the various technologies and tools involved in building Bunch, and finally Dave will talk about how we can extend and take Bunch further if we had more time.

MA Day 56: ACTIVE tabs

Noam commented that Team Bunch is the only team he’s observed that’s always working/”looking super serious” and never plays any ping pong. Hmm.. Interesting.

Charlotte and I got the tabs for different venue categories – Top Picks, Food, Coffee, and Drinks – working. The hardest part about doing this is applying the appropriate style to an ‘active’ tab. So what happens if the computer doesn’t know if the ‘cafes’ should be in the ‘cafe’ tab? You get restaurant/cafe/drinks content going under the default ‘Top Picks’ tab.

The key is the .addClass() function in JavaScript to give a ‘active’ in its classes to have the appropriate styling applied to it when the tab is clicked, to make the tab look selected. Because we need to tell the computer how a square we’re calling a ‘tab’ is supposed to look when it’s ‘active’ or ‘selected’… whatever that means (to a computer). So we got it looking like this! :) So now, when the “Coffee” tab is selected and cafe results come out, the “Coffee” tab is also highlighted.

Screen Shot 2014-09-22 at 12.51.20 AM

.addClass() baby.