Category Archives: Job Hunting

2014 Summer == Full Time Data Science Work

For the last three months I have been working at as a data scientist and engineer. Its been a great experience so far and I’m blown away that this is where I landed after starting this journey a year plus ago.

Impostor Syndrome
I’ve coached others going through moving into engineering about how to believe in themselves and they are smarter than they think. I totally get that you want to fake the confidence till you get there. Don’t be cocky just be resolved to figure stuff out.

Still I felt overwhelmed by the impostor syndrome. The fear of the company figuring out I’m a fraud and firing me during that first month was powerful in my mind. It didn’t matter how much I rationally knew better. Thankfully I have a good community of people who have gone through similar experiences with starting jobs that I was able to fall back on for support.

The feeling has subsided with time as I expected, but it does keep me on my toes to be vigilant in my growth in the space and make sure I’m having positive impact on the company.

The Company has been an amazing experience for my first data science and engineering job. I couldn’t believe it when they put me through almost a month of training and rotation for on-boarding. It helped me get to know the team and get more comfortable working with the group pretty quickly. I’ve heard of some companies doing this for their employees and it shows how much the company is invested in you.

The people are extremely friendly, welcoming and willing to help when I have questions. It’s not a negatively competitive or condescending environment that makes me feel like I have to hide weaknesses. It has allowed me to ask questions no matter how stupid I think they are and to grow so much faster as well as deliver so much faster.

They have also made plenty of time for me to grow even though I just started. In addition to the near month rotation, they sent me to the GraphLab conference and gave me time off to take a short Spark class I got into at Stanford. And next month they are giving me time to go to StrangeLoop. In the consulting world, there is no way I would have been able to take time away from work to grow myself being so new to the company. Granted I know the more I learn the better I become as an employee. However, not all companies are able to or willing to make the time for this type of growth.

Also as you can gather from above, the company does not take over my life. The hours are 10 to 6 and people typically stick to that with a few working occasionally outside those hours. We do fun stuff together during and after work but it’s not mandatory and makes room for you to have a life.

We do happy hours every other week and sometimes play board games especially on Fri. Earlier in the summer, we would gather around the TV in a big open meeting room and “work” while watching some of the World Cup games. And almost every Friday close to the end of day, we break for what feels a little like an open mic sessions. Anyone can present on a topic they think will be valuable for the team to learn about. It helps us see what other groups are working on or learn about new tools and methods we may want to use. I’ve presented a couple of times already on GraphLab and provided an overview of data science by leveraging my PyCon presentation.

Basically its been a great place to work.

The Work
The first week on the job, one of the senior engineers had me ship code. Basically you push up code that will change the live site in some way. This can be a big deal especially for a site that is so comprehensive and beyond just a start-up. So it was pretty cool to do that and not break the site in the process.

During the rotation, I did collaborate on a few bugs, but I was given an assignment to do as time permitted to answer a question using MrJob and Hadoop; thus, the previous post. I knew this from general experience and from talking to my friends who were working. Still I will note that nothing compares to hands on experience. Working on the MrJob project taught me so much about  Hadoop, AWS, how to access data at work and just gave me a better understanding of the big data hype.

Lately I’ve been working through implementing a Multi-armed Bayesian Bandit solution. Again teaching me so much through figuring out how to implement for the specific company.  We’ve built out a testing environment and coded the solution in Python initially but the live code we are implementing into is in Java and uses the Gradle framework.

I asked for the opportunity and was given the time to take a crack at converting the solution into Java before working with one of the engineers who is more versed in the code base. Java is a bitch but it has been a thrill figuring it out for the last few weeks. I understand much more the concepts around functional programming and interactive kernels and so forth.  And I did manage to figure out and convert and test the algorithm in Java which did make me feel fantastic about that accomplishment.

I definitely have days were I’m so excited about the work I’m tackling and feel so lucky to be able to do this for a living.

Strange Stuff
Before I even started, recruiters were contacting me for other jobs. Literally I changed my LinkedIn profile the week before I started at and at least 3 recruiters contacted me that week. Very flattering but also funny considering I hadn’t even worked yet. I know people who are still looking who are better versed in math and/or programming than I am and having a company officially hire me added this level of credibility at least for recruiters to want to talk with me. I am stressing this to point out there are many qualified people and I think they are worth a look whether they have a full-time position in this space on their resume or not. Frankly, I think drive and determination are more important characteristics to look for.

Also friends were putting me in touch with people getting into the industry to give them advice on how to go about it successfully. Again flattered but considering I was scared to death of loosing the job the first month, I did not feel qualified to give anyone advice.

Additionally, my path was not easy and this journey is far from over. I still have a ton to learn and I have many days at work where I feel like I know nothing. Again thankfully many in my community have shared those experiences with me, and I know this is typical. Hell one of the senior guys at work was saying he has those days still all the time. That’s the best and worst part about this. Everything keeps changing so it can keep you constantly humble but also challenge you a ton to learn.

Sunscreen Advice
For those getting into the space (I heard from a number of you this summer), I highly encourage jumping in. What I have been sharing is that a bootcamp may or may not be the right experience for you. There were people I know who did not get a lot out of Hackbright or Zipfian as much as I know people who did. The approach, people, experience or whatever just didn’t work for some.

I can’t tell you to quit your job and take the risk because I don’t know what is best for you. And I don’t know the hiring stats beyond, it is definitely not 100% hiring rate into the field after those programs. I think anyone who survives those programs should get hired because of the rigor and determination required to sustain through them. Still companies are selective and will do the best for themselves by hiring for talent and fit. You probably won’t like all the people in your class, and may even hate a few. The job search process for you could be almost a year after you are done, maybe more. You could find this is not a field you want to get into. All of these things I’ve seen happen because the bootcamp process is not a gold ticket or a promise of success for everyone.

You make that success for yourself. If you decide to do these programs or whatever approach you take to get into the industry, make sure to own it. It is your responsibility and no one else’s to make you successful. You can have expectations for education you pay for to a point. Still the one who is going to be most concerned for what’s best for you is you and that is not going to change no matter where you go or how much you pay to get into something. You really have to make sure that you show up to whatever you try to do, be willing to participate, thankful for the help you receive in whatever form it comes, constantly look inward on what you can do to improve, try not to compare to others and fight to overcome any internal ego issues that may battle against you.

Get clear on why you are getting into data science and/or engineering. Different reasons can determine the best path for you too. I’m here because the challenge and constant learning makes me feel alive and I love it as much as it frustrates me. I seek opportunities that make sense for what I want to get out of the space and I’m constantly re-centering on what I need and want to learn as I get clearer on what the space is about. You don’t have to have those reasons to get into it. Just be honest with yourself on why you want to be in data science and engineering and what you expect from it. And be open and ready for the fact that whatever you expect will not be what you get. It may be very close or very far off.

I want to see more people working in engineering and data science because it’s definitely needed and there are a lot of people who feel like I do.  We are willing to help make the path more accessible. Still it is really on you to figure out what is best for you and then fight for it.

Blog Next Steps
I have learned so much in the last three months and there are many times I’ve thought, I should write a post about it. Reality is this site has become a lower priority while getting up to speed on work and getting a lot clearer on where I want to focus my studies. I’ve also tried to get some level of sanity back into my non-work life. I will try to make time again for posts but its tbd on frequency. Thanks for all those who have been reading so far and sending me great feedback. Seriously, much appreciated.


Interviewing Sucks

Yeah I know this is not a revelation and some of you out there enjoy the process. I say you are probably a little sadistic or masochistic or both if you do.

It’s a mental and emotional roller-coaster and as mentioned in a previous post, its like taking finals non-stop for as long as you are going through the interview process. It drained my energy and kept me from feeling creative or feeling motivated to just code for fun. Its been so long since I posted code consistently on Github which makes me a little sad.

While interviewing, I was typically too busy managing the interview pipeline and studying. By pipeline, I mean finding companies, setting up interviews, actually interviewing and then following up and doing this for each company. Several companies have multiple rounds from 1-6+ depending on the company. When I wasn’t dealing with the process of interviewing, then I was studying which I’ve mentioned in my last post how wide the range of topics are for data science interviews.

Many people talk about how the interview process is broken and there are some attempts to fix it (at least in the SF tech community from what I’ve heard & read). But let’s face it, putting people in an awkward, stressful fishbowl environment and having them perform tests that typically don’t relate to their job to see if they are a good candidate is biasing the results for people who interview well.

Interviewing well does not mean that person is the best for the job. One of the smartest and most talented people I know does not interview well and any company that passes up on that person is literally missing a gold mine of talent.

I get it that companies can only except so much risk and they are trying to find ways to vet productive and successful people they add to their team. And as mentioned, there are efforts to improve the interview process. Since I was in the thick of interviewing for the last couple of months, I wanted to note a few experiences in what worked and didn’t work in how companies interviewed.

  • Treating the interviewee like a person and valuing their time vs. making them feel like another number. Some great experiences were going to lunch with people I would work with to see how we gelled and even just as simple as having them make time for me to ask questions or check if I needed a break during long interviews.
  • Being prepared. I had a couple of interviewers tell me they looked up my Github profile before they talked to me which impressed me. On the flip side of this, I had interviews where the person came in telling me they didn’t really know who I was and why I was there. I know they are busy but this ties into my first bullet above.
  • Explaining the process and setting interview expectations. Some companies would send an email or do a call where they would explain the process which helped me prepare. There were a few times where interviews turned into surprise tech interviews when they had been explained as just “get to know you” interviews.
  • Creating as realistic an environment as possible for tech interviews and keeping it contained. One of the best interviews in relation to this was when the person had me solve a code challenge on his computer. I was told to use any resource I normally would (e.g. Stack Overflow) to solve the problem. The challenge was also focused on a specific problem that related to the type work and the environment was all setup so I could just focus on the problem. Granted he watched me while I worked and this could be too difficult for some but being able to code like I would almost normally was definitely one of the more positive tech interviews.
  • Giving constructive feedback. One of my favorite parts from the bullet point above was that the guy gave me solid constructive feedback at the end. This happened in a few other interviews but not always. Getting that type of feedback really helped me  see how well that person can communicate and evaluate work. It spoke volumes about the company and experience I would have there.

Look, I’m not breaking new ground with the information above, just giving some thoughts on my experience. I will say that even though interviewing really does suck, it also was very valuable.

When I started interviewing, I had to just tell myself to buckle down and drive after this. I was so tired after Zipfian and PyCon that it was the last thing I wanted to do, but I knew the timing required me to just regroup and push forward. I felt like I didn’t know anything when I started even though I did, and I made a point of making blocks of time so I could study as well as figure out how to solve questions I got from the previous interview. All the interviews and studying did help me become stronger on the topics.

Plus, data science is still such a new and not fully defined field and I still didn’t know how to explain what I wanted to do. The interviews gave me a chance to get clear on how companies define data science and what they really needed as well as what I want to work on in the field.

Many companies were interested in me for more metrics reporting and BI which makes sense with my business background. Still I am very interested in building things such as implementing a recommender system or applying NLP or MapReduce which is really more about developing data products. Hell, as it becomes more practical, I also want to get into applying neural nets. (All in good time.) Ultimately, the interviews allowed me to get clear quickly with companies on what we were both looking for and whether the role was a match.

A couple other things that helped the process:

  • Github Profile: I got into a space last year where I was posting daily on Github and that really paid off with some companies who saw that I could code. FYI, I’ve posted a lot of messy code there and I try to focus on getting code up more than worry about making it perfect. It will never be perfect.
  • Blog: Explaining my thought process here and progress over the last year helped a few times with people understanding me a little before we met.
  • Network: It has been ridiculously helpful the people I’ve met this past year for me to vet what the companies really are like as well as for the companies to check me out beforehand.
  • Practice: Even though I don’t love interviewing, I will totally agree that going through several made me stronger and I wouldn’t change that.

So interviews suck but they do have redeeming qualities. When you are going through it, take breaks when you need to, talk to your friends (especially those who have gone through the process) and just keep moving. It can be hard but it is survivable. And good luck!

Zipfian Hiring / Demo Day – How it Works

This past week was the big hiring/demo day for Zipfian Academy where we presented our projects to a number of companies seeking data scientists. Zipfian’s hiring day is a lot like Hackbright’s career day. So the nice thing about going through it was that I knew what to expect.


Sixteen companies attended hiring day which was a great turnout, and I was thankful there wasn’t another 9 because talking to 16 was still exhausting. Some companies were hiring their first data scientist who would build the strategic direction as well as put it into action. While other companies have teams that they want to grow. So there was a mix of start-ups to large organizations.


In the morning, each company gave a 1 minute introduction on who they were and what they were looking for. Then all the students presented 3 minutes each on our individual projects. We used slides and did a very brief overview or our project goal, approach, results and next steps.  We broke for lunch and then we did the speed interviewing like we did at Hackbright. Each company had a table and the students would rotate around. We were given 7 minutes to talk and the conversations varied based on the company and what they were looking for.


Preparation was really focused on reviewing company bios as well as putting together project presentations to explain what we did. Zipfian drilled us on those presentations. They had us draft them the week before and run through them a few times with lots of great feedback. It was tough to go through when there was so much else going on, but it was very valuable to get us in shape and clear on our project story.  We also worked on putting together bios for the companies as well as received bios about the companies who were attending.

During the day, I went with my previous experience of asking questions about the company, roles they were hiring for, culture and tools they use. A few companies asked technical questions and/or specific questions about my project. I also got questions about my background and what role I was looking for.

Afterwards, I changed my approach from my last time through this of sending emails immediately. Partly because I needed a breather and took a day off from school the day after to handle a number of errands that had piled up.  Also, because it was nice to let the experience percolate.

Zipfian & HB Comparison:

The speed interviewing was pretty much the same except having the students rotate and consolidating the project demos to just one presentation. I really appreciated not having to repeat my project spiel more than once, and it kept the individual conversations more authentic (vs. rehearsed speech). That also gave more time to get to know the companies.

On the whole, I felt more comfortable the second time around because I actually knew many of the companies and have a broader picture of the community. There were a few people there that knew and/or worked with some of my fellow Hackbright alums and friends. One of the coolest six degrees was that one of the representatives was at the hardware hackathon where my team built the Arduino car. It gave us something else to talk more about and removed some of the awkward getting to know you process. So even though I didn’t know the people directly, they didn’t all feel like complete strangers to me.

To clarify, I wouldn’t have felt that way at all if I hadn’t gone through Hackbright and all the stuff in the last year. It really set the stage for me to have a better perspective on the hiring day experience.

It is still a very long day and everyone (students and company reps) said the same. Still after it was all said and done, a few of the students who were still around went out for ice cream which was definitely a good way to wrap that day.

Last Note:

One week left for Zipfian and next week is interview prep.

Wrap-up & Kick-off in One

It’s been over 8 months since I graduated Hackbright (HB). It also has been a while since my last post, but the last one was a bit difficult to follow. Plus, things have been …. busy.

Tips on Life After Bootcamp:
It has been an interesting several months since I started this journey and a good portion of that being what took place after HB. I know I’ve talked about this a little before but I’ve watched 2 classes since mine go through the HB withdrawal as well as met many from other bootcamps who have struggled with the “what’s next”.

So I want to take a minute to talk about tips on what to do with yourself outside a bootcamp (or without a bootcamp) and in so doing, give some insight into what I’ve been doing these last several months.

When finishing a bootcamp, many have struggled with the lack of clear direction because when you leave something so structured, its a bit hard to put a plan of action in place as you are still trying to learn about the space. Many struggle with just knowing where to focus because there are so many options competing for attention. It can be a very similar experience to people who leave school for the first time and try to enter the “real world”. One key to success here is to create as much structure as possible and focus on what you want to learn or think will move your career along.

  • Interviewing:

Usually most grads from bootcamps are interviewing by the last couple weeks of the program as well as up to several months after. There are a few people from my program that just landed jobs last month for the first time. Even while interviewing, there is that question of how to go about spending your time. There isn’t a specific rule on this. It is about finding what works for you, and putting a plan into action. For example, you could split your days half and half between studying interview questions and sending out resumes or have one week dedicated to working on problem sets with the following one dedicated to going on interviews. You don’t want to be too prescriptive but its important to take charge in defining your career goals and like any software problem you would tackle, break those interviewing goals into steps on how to achieve them. There are plenty of resources out there you can leverage, and I’ve got another post in here about interviews and prepping for them that goes into this subject a little further.

  • Skill Building / Continued Learning:

Bootcamps are limited in what they teach and if you want to work in software then you need to keep building your skills. There are so many tutorials and online courses to utilize out there and even ask around your bootcamp community for recommendations. Some will work better than others for your learning style. So test out different ones. Also if you know you just want to code in a specific language like Ruby or Scala, then spend time on studying and practicing those skills (especially when you are in between interviews and trying to figure what to do now).

More generic skills that are valuable to work on are:

Testing & TDD (a necessary evil) You should try writing tests for one or more of your projects if you haven’t already, and read about best practices in TDD especially for your language(s) of choice. It’s a very important and valuable skill for most jobs you are going into. So it’s a good idea to go ahead and practice now to show your dedication and commitment to field.

Encodings & Character Sets & Such – Learn about Unicode vs. ASCII, code points and how to encode vs. decode (e.g. apply UTF-8).  I spent about a few weeks looking through this stuff while working on a Twilio app. Still a little confusing but important concepts to understand when passing data between different systems, character sets and spoken languages (let alone encodings). Many established programmers pointed me to the article “The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets.” by Joel Spolsky. It’s a good place to start and I just recommend finding something to work on to practice encoding and decoding and playing around with character sets.

DateTime – I kinda hate datetime like everyone warned. I have been into the black hole of date time now many times so I get it. It’s hard to keep straight timezones and leap stuff and where your server vs. your user is in terms of times that are stored and shown. So accept the pain and practice using datetime in a project from a client vs. a server perspective. Think about clients that are not in the same location as you (esp. ones who do and do not have daylight savings). Practice applying datetime functions in the terminal and understanding what they do. The tip everyone has given me is store datetime as a timestamp on the server whenever you can.

Object Oriented Programming (OOP) – Practice building class structures and generating object instances because it’s a tricky subject. OOP is pretty popular design approach used in software development and thus its good to be as familiar as possible with how code it. I don’t have a lot to say here. OOP is just good to know.

Databases – Take time to learn about how to structure and work with databases. Play around with how to migrate, upgrade and rollback your project database. Think about how to minimize the calls to the data and improve performance with the way the data is structured. Also try out one or more of the NoSQL options on the market. I’m a huge fan of Redis because its like a dictionary/hash.

Deployment – If you didn’t deploy your final project, take the time to learn how to do it. It will teach you things to consider about your code (esp. when it breaks when its live). It will make you a better programmer having that big picture experience. For example, I’ve used Heroku a few times now and its taught me how to structure and reference files so they will work on the server. Now when I start a project, I just start out in with a structure I know will work on Heroku instead of having to go back and rework and rename all the files. Heroku is good deployment option with great documentation but they aren’t the only ones out there.  I do recommend trying other options to broaden your experience. Deployment of course totally helped me appreciate datetime challenges better.

And of course just build stuff to practice and expand your experience as well as to have something to share for what you are working on. Try finding other people to collaborate with to get experience co-coding. Also explore stuff that you like (in case you don’t like anything listed above). It’s important to find the fun in what you do because it will motivate you to keep learning.

  • Hackathons, Conferences & Meet-ups:

In addition to interviewing and building skills, take advantage of any hackathons, conferences and meet-ups that are in your area (esp. the ones that align to your interests). These are great venues to learn more about the community and opportunities that are out there.

Conferences usually post speaker and topic lists to help you know what content will be covered. As for hackathons, they can be great opportunities to go practice building a product and working with a team. I’ve noticed hackathons with large prizes tend to be pretty commercial and competitive. Many people who compete actually bring projects that are already in development despite the rules. I’m more a fan of the low-key hackathons that have mentors and are more focused on learning. I did one with Electric Imp where there was at most 50 people and they had plenty mentors to help. Plus they let the audience vote on the winner.

In the Bay Area there are many conferences and hackathons during the year and a number of them are free or very discounted to encourage developers to attend. Find venues in your area and go. If there’s a fee, volunteer and/or apply for financial aid. And if you don’t have a meet-up that addresses your interest, then start one.

My Year in Brief Review / Practice What I Preach:

So yeah I have done pretty much everything above and then some in the last several months. Thus  => busy.

I have probably attended up to 2 or more hackathons and conferences a month from July to December. In addition, I was hosting almost weekly co-working meet-ups for others I’ve met in the field as well as attending (and sometimes speaking) at different meet-ups. I’ve been providing adhoc mentorship to people in my community and thankfully working with a couple mentors regularly as well as several others as needed to help continue to grow my skills. I completed MIT’s online intro to CS which was very helpful in reinforcing concepts I had learned as well as give a more rounded context to my work. They should be running another one on edX this spring. I have also been squeezing in many other programming tutorials when I can. I especially find it interesting to learn new programming languages to better understand the ones I know. And when I can find the time, I play with hardware.

While studying and attending events last year, I also worked on setting myself up as an LLC so I could freelance and build products on my own. And setting up a business on its own, is quite the education itself. There could be many posts on just this if I made time. Still I will note that it is an alternative to consider and I’ve seen other classmates do contract work after bootcamp.

So Now What:

Being a glutton for punishment, I’m going back to do another bootcamp. I have had an interest in machine learning even before I started Hackbright. So I’m starting at Zipfian Academy next week which is a 12 week focused data science and machine learning bootcamp.  Should be intense, interesting and I’m sure there will be lots to take-away. I plan to get back into the habit of posting to share my experiences. Can’t swear to how often but there will be other posts on Zipfian. It should be a fantastic challenge and a different perspective considering where I’m at now. I’m already busy cramming stats, linear algebra and multivariate calculus. My head feels a bit full.

For those of you out there still figuring out where you are going and what you want to do with yourself for the year (and yes that could be anyone and probably everyone), I know this sounds cliché but you just have to make the path that works best for you and try as hard as you can to not let someone else dictate what success looks like for you.

Good luck! And happy belated new year.

New Job Fear – You are not Alone

I have been wanting to write this post for a while. After we graduated Hackbright and we started to land jobs, a common fear that popped up was fear of failure.

I found myself regularly talking to new alum unfortunately on a one-on-one basis since we were all spread to the wind in our unique job search experiences. Many were and are thrilled about landing the new job, but that excitement typically included and/or was replaced by the realization of “Oh god, I really have to do this now.”

Seriously, almost everyone expressed that same sentiment and granted its easier to express doubt like this in one-on-one conversations. Still I wanted to pull everyone in a room to have this conversation (like a self-help group), and I regularly told people how they were not alone and this is normal.

This fear at its heart is being found out to be a fraud. That the person who hired you will regret it and heaven forbid, fire you. That you won’t fit in, never be good enough and/or you’ll do something so badly that it will destroy your career. I can go on but fraud and failure definitely covers most of it.

These fears are understandable and as mentioned, normal and it’s just important to remember for anyone starting a new job, you are not alone and you can survive this. And when I say you are not alone, I’m not just talking to the new Hackbright grads, I’m talking to anyone starting a job.

From my experience in consulting, I remember the first several projects that I started and how much fear I had as well as others when taking on a new client and project. The good thing (if you can call it that) about consulting is it makes you go through that enough to help push you past or at least numb those fears. But don’t get me wrong, I still get butterflies (or worse sometimes) and I had many successful and not so successful projects.

Most managers are focused on all the stuff they need to get done and what will go a long way is someone who lands in the new role with the drive and enthusiasm to help make the work burden eventually easier. Managers typically understand there is a ramp up period for someone new starting a job (especially someone new to the field) and ideally, s/he should give you room for that.

What can help is to talk with your manager about her/his priorities and try to establish goals/metrics for your work. Something to work towards helps give focus and show progress. Also, ask for regular check-ins with your manager to discuss your questions and project status. It’s important for your boss to see you regularly and hear what you’ve been up to. It’s also important when you are just getting started to have these check-ins to make sure you are staying focused on the right things and avoid being stuck on a problem for too long.

You may not get these check-ins or goals and if not then try to set your own. At the heart of this, I definitely recommend getting an understanding of what are your manager’s priorities and biggest challenges and thinking about what you can do to help.

It can take a couple of months for anyone new to feel like they are fitting in and successful. Many of the Hackbright alum into the first couple months or so of the job expressed feeling overwhelmed and uncertain that they were able to have an impact. Those fears have been dissipating. It’s seeing your contribution to something at work get recognition and/or show value that will usually help alleviate the pressure. With enough practice and experience in the field the turnaround time on accomplishing this can and should be reduced.

Now for the reality check (aka where I destroy the tooth fairy). It’s healthy to have your fears and typically you will be fine in the new job. Still not all jobs are created equal and there are worse case scenarios out there that totally make the fears warranted. There are jobs where you won’t fit in, where you hate your boss, where you won’t feel like you can make any impact or where you could even get fired. This is also normal and again, survivable.

What you need to realize and remember is that those jobs were not right for you anyway and that they won’t destroy you unless you let them. Life is short and really you don’t want to waste time in toxic job that is stunting your career if you can help it.

Sure some jobs are hard to get and not everyone has the luxury of finding a replacement job easily. It is important to know that in the face of any of these worse case scenarios, you can find an alternative if you are willing to work for it. You may have to work harder than others but it will be worth it to find a job where you have support and are successful.

Just remember you are not alone in these fears and you can survive them.

Oh The Fun You’ll Have with Technical Interviews

Technical interviews are just tough. For the month and a half I went through them, I felt like I was constantly studying for and taking a final exam. We were trying to cram at least a semester’s if not a years worth of computer science concepts into our brains as well as practice how to solve problems with an audience in a handful of days.

Initial Experience
I definitely felt fear at the white board the first several times I was there. I would go blank and forget everything I knew. I was lucky if I remembered my name. But trust me when I say that you will survive this and practice is the key.

Interview Structure
Technical interviews vary in delivery from over the phone, view web meeting/Google Hangout or in person.  They range from an hour to spanning over a couple of days. Behavioral and get to know you questions are mixed in at times but the main focus is to run through coding a solution to at least one problem (e.g. reverse a string or merge sort).

Usually you can code in your preferred language. The interviewer may ask you to work on a whiteboard or on paper to write out the solution, and the typical expectations on how to respond to a problem are as follows:

  • ask clarifying questions
  • write in code how to solve the problem
  • explain out loud as you write your thought process
  • run through sample input and expected output to test the solution

At times, white-boarding felt like being asked to chew gum, rub my belly and head in opposite directions and cure cancer at the same time.

If you finish the problem sometimes the interviewer asks you to rework and/or expand the solution (e.g. write fewer lines or improve space complexity). Sometimes they give you more than one problem to solve (usually during meetings more than an hour and usually by different interviewers). Typically the interviewer asks about solution time complexity which is Big-O.

For technical phone interviews, you will usually do a call and use a web interface so the interviewer can have you code a problem on a shared screen. These interviews typically are an hour at most to get a sense for whether you are someone they want to bring in for an in person and more in-depth interview.

Some interviews also contain questions on computer science subjects and that really varied based on the role and company. Also there is the infamous brain teaser questions that I only came across once in an interview. These questions are used to test the way you think and there is debate on effectiveness.

Bottom line for the technical interview structure, the interviewer wants to see how effective you are at solving a problem.

Approach Recommendation
During the interview, just remember to keep talking about what you are thinking and why. Use pseudo code to help create an initial solution plan if that helps. Just make sure you write actual code and don’t get too caught up in syntax.

Before and after interviews, I took on the approach to code at least one sample problem a day. It made me much more flexible and faster in my problem solving as well as improved my Python knowledge. Sometimes I just coded straight on the computer. Other times I get mentors and friends to drill me on a whiteboard. In between that, I would study recommended computer science topics and look at sample brain teasers.

When I started, I searched the Internet for example Python solutions to typical problems in and they were tougher to come across than Ruby, Java or C. So I started a repository on Github (Interview Problems) to consolidate sample problems and solutions I’ve seen or heard about in interviews. Recently, I started to expand the repository to rework the problems in other languages (Ruby & JavaScript for now). Feel free to check it out and contributions are always welcome. Also, Project Euler is a good resource for example problems to work on.

Other helpful resources during my interview study:

Best advice I’ve received is be authentic, confident and up front when you don’t know something. I know it sounds counter intuitive to be confident and admit you don’t know something. What you want to indicate is that it’s not something you know about and then explain how you would go about finding the answer. What companies need is someone who will show they are resourceful and capable to tackle the unknown in a systematic way. 

Ruby on Rails & Python Trek

Wow its been a while since I last posted. Lots going on with interviews last month and then deciding to teach myself Ruby on Rails and being obsessed with Julython. I completed and launched my first Rails app (technically second after the sample app from the tutorial) at the beginning of this week. It is a simple thing that literally is just a button and I couldn’t be prouder.

What is Python Trek?
Python Trek is a mashup of Stark Trek and Monty Python scripts, quotes, etc. I built a program to generate random sentence or sentences using a Markov Chain algorithm and post those to the Twitter account @pythontrek. I used Ruby to build the program that generates the tweets and I applied Rails to set up a webpage where anyone can press a button that will generate the random tweet and post it.

Why did I do this?
One of my code challenges last month asked me to write a Ruby program and present it. The company asked me to build something small and didn’t have to be a web app. I only wrote the Markov Chain generator for the challenge and afterwards, I decided to take it a step further and learn Rails.

I am in learning mode, and since I want to learn all the things, I figure why not leverage this opportunity. The reality is that Ruby & Rails (usually referenced as Ruby on Rails) are in high demand since so many companies are using it in the Bay Area. I know it does not hurt at all to expand my knowledge and skills in this area.

For those who are new to Ruby & Rails, Ruby is the programming language and Rails is the framework to build web applications with Ruby. If you’ve read any of my previous blog posts on Sun Finder, you’ll see I use Python as my main scripting/programming language to build my app and Flask is the framework.

I actually understood some of the mechanics of Python better by trying to learn another language as well as web frameworks and how web stacks work by trying to understand Rails.

How did I do it?
Lots of help and lots of time. Thankfully the network I have now was able to give me some great coaching and that’s especially true for a good friend, Jason and my mentor Jeremy. I also just put a lot of time and effort into working through it. Still to give a little more detail to the process:

Learning Ruby
The week and half I had for the assignment back in mid June, I was juggling 2 other codes challenges, interviews and a couple other activities. Thus, I probably clocked about 4 days or so on doing the initial Ruby app.

I spent about half a day on the free Ruby course on Code School get some fundamentals. The concepts in general were pretty similar to Python. Afterwards, I made an exec decision to use a project we did in Hackbright and rewrite it in Ruby. I wanted focus on understanding Ruby and not be distracted with figuring out the program problem I was solving.

Another day or so (total time spread over several days) went to just googling how to do ‘x’ from Python in Ruby. It required some research and frustration at times when I could do one thing in Python that was not something Ruby allowed and vice versa. Like using list comprehension or setting default variables if a hash/dictionary key had not been added yet.

While building out the Ruby app, I also leverage Zed Shaw’s ‘Learn Ruby the Hard Way’ since it’s structured just like the Python version. That made looking up information very easy. Additionally, I found the Ruby-doc site a great reference document when trying to find how to write certain syntax, and as always, StackOverflow was my friend for many answers. But let’s face it, googling was just the way to go most of the time.

Ruby meh:
There were also all these uses of non-standard characters (e.g.. curly braces) that I was not used to in the code and made me think of JavaScript. Also the use of end after any block was a bit annoying, and when I had finally gotten into the habit putting colons for Python blocks, I had to force myself to stop it. While I was coding in Ruby, I would change back and code in Python that same day or the day after because I had other things to work on. It added an additional challenge to the process, but taught me a lot.

Project Functionality
Once I had the program rewritten in Ruby and working on the command line, I started to play with the code to improve its functionality. I was working to align it to the Markov approach because we hadn’t really finished that algorithm while we were doing the project in class. Then I just got fancy creating two hashes/dictionaries for capital vs. lower-case and trying to define the end of sentences based on end marks that would pop up.

Markov Chain
If you are asking what is Markov, check out the wiki article. To give you some sense of it, it’s an approach to create a random process characterized as memoryless. The next state only depends on the current state and nothing before that. It’s not the best solution for predictive text, but it is a way to approach randomly generated text.

Summary Random Text Approach
For the project, the goal is to take a text file full of content from two different areas of interest and mash-up the words by creating a hash/dictionary out of the text. The hash/dictionary is a key:value pairing between two words (in the stricter sense, a word and an array/list). So if ‘a’ is a key then all the immediate words that follow ‘a’ are put in an array/list as the corresponding value. Then to build a sentence, a random key is selected initially, then each new word is used as a key and the associated array/list values are looked up where one word is randomly chosen from the value array/list to add to the sentence. This continues till the sentence meets a limit of no more than 140 characters or less.

I’ve added a little more complexity to the approach that what I’ve mentioned above and if you don’t know about hashes or key/value pairs then the information then just ignore that last paragraph. All you need to know is the program stores words from Star Trek and Monty Python in a way that is able pull and create random sentences.

Why Python Trek?
Initially I used sample text to build the program and when it worked well enough, I switched over to figuring out what text I wanted to create for the official mash-up. I made the decision at like 1 in the morning after several hours of coding that day. I had been watching the original Star Trek while programming, and it’s quite probable, I heard the song, “Always Look on the Bright Side of Life”, sometime that day. So I was like, ‘wouldn’t it be fun to have a Star Trek and Monty Python mash up?’ I’ve definitely been a fan of both and they both hail from campiness. Thus, I spent a couple of hours copying and pasting quotes and script stuff into a raw text file. It really is a bit messy and could use some proper data munging, but I had other priorities to tackle.

Setting up the @pythontrek handle was the simplest part of this project, and I was a little surprised the handle wasn’t taken. Setting up the code to link to the API didn’t take too long because all the work I’d done with APIs before made it pretty easy. Plus, there was plenty of sources out there that shared the code and how to set it up.

Beyond the Challenge
Being the type A person that I am, I had to take this challenge further and learn more. I went through my code with my mentor and got help refactoring the solution from a functional structure to a class based structure.  Also, we worked on modularizing the code because the functions were very long and weighty. Making those changes took a day with help. Still what really made this a valuable exercise was deciding to learn Rails so I could publish a page that would give other users access to generating random tweets.

I spent about a week 1/2 spread over 2 1/2 weeks trying to go through the Ruby tutorial my friend showed me, Ruby on Rails Tutorial. I had hoped it would just take a couple of days, but let’s face it…Rails is complicated. Its hard going from Flask to Rails because as they tell you, “Rails does a lot for you.” That is not necessarily a good thing when a lot of times you are trying to understand what exactly it is doing for you.

When building out Rails, some key files and sections to be aware of:

  • Gem file lists all the gems/packages/libraries needed for the application. This is like a Flask requirements file that lists out all the programs and packages that must be loaded in order for the program to work.
  • Routes file defines paths to views similar to the decorators (@app) put above view functions in Flask. Basically the decorators are being listed in a separate file that help generate views based on corresponding controllers and actions.
  • Controller folder/section defines the view structure with specific actions for the views (e.g. page render or redirect). If there is any data manipulation that should take place elsewhere and content in this section should stay focused on concepts around building views, passing data, maintaining sessions, etc.
  • Model section is focused on structuring database content and interactions
  • Views section includes the templates for pages that are rendered.

It’s a little tricky to the get hang of Rails because there are a lot of other files and folders that help and support the web application as well as short-cuts that are supposed to make it easier, but once you work with it enough, it will make sense.

Test Driven Development (TDD)
The tutorial I used spent half the time going through how to do test driven development in Rails. I had wanted more exposure to TDD and this was a nice way to integrate it. There were times I hated RSpec (Rails TDD) because it liked to throw all kinds of errors that I had a hard time with because I had a hard time understanding what Rails was doing. It did force me to really work with Rails.

Heroku & Postgresql
Something else the tutorial went through is how to launch an app on Heroku. It took me a solid day of wrestling with Heroku and Postgres but I finally got the hang of it. The tutorial doesn’t cover everything you will need, but I can say that both Postgres and Heroku provide all kinds of documentation and there are plenty of people who post about it.

A couple of things I learned are that when setting up Heroku with Postgres, you don’t need a password in your database yaml file. You do need a user name that has been granted access for creating databases. If you get errors regarding the user, look-up how to setup a user in Postgres, and just open a terminal to do it (again stressing to make sure to grant the user the create db rights).

A useful database.yml file that I leveraged for the format when creating my file can be found a this link. Also, note you need a local test db for Postgres, but that does not get posted to Heroku. Additionally, don’t forget to rake create:db and migrate when there are changes to the databases.

Python Trek Button
Eventually (last weekend) I got the sample app from the tutorial to work; thus, I finally switched gears to build the web app for my Python Trek. As mentioned, I was just trying to build a page with a button that anyone can push to generate a random sentence and post to Twitter. Seems easy enough and seems like a lot of work after the fact to accomplish it. It really would have taken me a weekend or less if I had used Python and Flask.

Text File Alternative
What made this application a little tricky was that I was not building out a database(db) model. I wanted to use my text file solution where I just open and read from the text file and generated a couple hashes through a class object. Most tutorials and any helpful code to leverage is written from the perspective of using a db model. The way I tackled my solution was to store my class structure in the library section (lib) as well as the text (source) file and the tweet method I defined.

With help, I learned how to reference those files through the controller and pass the information needed into the web page. I also applied Ajax to post up the tweet that was generated after the button was pushed on the same page as the button. Thankfully that just went into a script tag on the main page template.

Stake in the Ground
The good news is I finished the app and it works. It was not easy learning a new language and framework considering I’ve only been doing this since late Feb. Still it was a great exercise that I would recommend to anyone who is going through the programming learning process.

This week, I’ve been switching gears back to some stuff I want to do in Python for a little while. There is a lot more I can do with this app (hell my friends are already asking that I let them create user accounts and track who pushes the button more) and I would like to continue to leverage it as a learning ground. Still I’ve done what I’ve wanted to do so far. Additional next steps will have to get in line.

Side Note – Seriously?
The morning of my interview last month, I opened the project and was surprised to see a file labeled python. Initially thinking it was a mistake since I had written the project in Ruby. It finally dawned on me how I had shortened the name Monty Python and by using them in my mashup I was inadvertently (probably subliminally) putting a reference to the Python language in my application. It wasn’t till I showed the project to my mentor after the interview that he made me aware of the fact that Python actually is named after Monty Python. Seriously, no clue.