Category Archives: Hackbright

Hackbright Academy experiences

Delayed Zipfian Week 12 Wrap-up

A little delayed for good reason but here we go. Zipfian’s 12th week focused on interview practice, a conference and the graduation celebration.

Interview Practice

Most of the 12th week was spent going back through previous materials and drilling/simulating interviews. Data science has a different interview flavor from software engineering. Companies vary in what they are looking for and what they will ask and the content for data science covers a broader range of topics.

Companies may be looking for someone to:

  • build out internal dashboards that provide business metrics
  • design and build data analytics backend
  • implement and maintain tools for others to get access to metrics
  • build customer facing product features that are data driven
  • establish company data strategy
  • different combinations of above
  • all of the above
  • something else not listed

If you know where you want to focus, that can help scope your studies and your job applications to some degree. Still there is a lot of material to go through and ideally you want to review:

  • data science pipeline
  • general experiment design
  • machine learning algorithms
  • probability
  • statistic models & tests
  • data analysis (esp. regarding model performance)
  • programming (esp. white boarding)
  • product metrics / growth hacker

My plan of attack is to pick a topic to study for a couple of hours and then switch to a different topic. There is a little more to this approach and I’m typically tackling areas where I know I’m weaker or I anticipate to cover in an upcoming interview. Zipfian also gave us a number of study resources and sample questions to work through that has helped in the preparation.

Conference(s)

The class attended the Big Data Innovation Summit in Santa Clara during the last week. Content covered machine learning and big data trends.

As you may have read in my last post, I missed half of the week and events because I went to PyCon. PyCon was amazing and even thought it was hard to prep for that while also going through the bootcamp, I am so glad I did it. The conference also had plenty of content around data science and you can find videos for the even at Pyvideo.org.

Graduation

I heard there was lots of dancing and drinking and partying at the graduation celebration and that several previous alum came back to join in the event. It was an all-nighter which reminds me of another bootcamp’s graduation party.

I was definitely sad to miss the festivities, but I’m so happy for all of us that we graduated!

And that is not all folks…

It feels weird and awesome to be done (sorta). It’s funny how everyone started saying close to the end that “you are almost done and then you can relax.” And I would laugh cause I already knew what was coming because of Hackbright.

There is no relaxing immediately after…okay maybe for like a couple of days but then you are right back into the thick of it if you are interviewing. Most bootcamps don’t get this expectation set correctly just yet. I still heard it from the recent Hackbright graduates that they were surprised there was still so much work left to do.  I’ve also heard it from a few people I’ve gotten to know attending other bootcamps in the area.

The interview process kicks in and its lots of studying, interviewing, studying, interviewing, studying, interviewing, sleep a little and then study. The bootcamps have a week or two after hiring/career day to help support those going through the process. And granted not everyone goes into this loop but many do.

Thus, I am currently in the study/interview cycle myself to explore the options out there and looking forward to getting through this part of the process to when I can finally take a minute to relax.

Last Thoughts

One of my cohort, Ike, has been keeping a blog about his experience at Zipfian that I’d definitely recommend if you are interested to know more: Yet Another Data Blog

And I will say this for those wondering about the value of the bootcamps, I have been getting good job leads from Zipfian and PyCon and also through my Hackbright connection. The alum connection from Hackbright has brought me opportunities that I didn’t have last year, and I’m very grateful to have this network.

Zipfian is basically at the point of the path that Hackbright was when I attended last year. Not as many know much about them yet and their alumni network is small right now. Still it is growing and it will be fun to see how strong it becomes in another year.

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.

Companies:

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.

Schedule:

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.

Approach:

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.

How Flask, Heroku & Alembic Play Together

I just spent a couple days getting up to speed on database migrations in general, how to make it work with Flask and Postgres and how to make them work on Heroku. There is some information out there but it took a little time hunting down what I needed; thus, I’ve summarized some of the main steps to help get others up and running with Flask, Heroku and Alembic.

Why migrate? Best practice is to avoid recreating your database(s). Usually you just want to make changes to the existing database(s) and track those changes. If at any time you need to go back to a previous version, the migration docs will help you easily revert to an old version / schema and then upgrade back to the most recent depending on your needs.

Migration Types: They are usually discussed as either schema (structure of the database) or data (the stored stuff – aka creamy filling). Sometimes they take place at the same time and sometimes not.

A Flask Migration Package Option: Alembic

Previous posts included how much I leveraged Flask Mega Tutorial for building a web application (app). In regards to migrations, Flask Mega primarily focuses on SLQLite which is not as helpful because Postgres is needed for Heroku deployment.

Alembic is a migration tool that is better maintained than the sqlalchemy-migrate package, and it is from SQLAlchemy’s author.  There is documentation on how to setup and run database migrations. I’ve listed out some of the main, basic steps needed to setup alembic, migrate revisions and run it all on Heroku below. This is assuming you’ve already created a database locally as well as added it on Heroku and promoted it as the default.

Where there is a $ or => the words following should be run in the command line and yes, these directions are based on Mac. 

How to Start

  1. Install alembic $ pip install alembic
  2. Add to requirements $ pip freeze > requirements.txt
  3. Initialize it inside your project root folder $ alembic init alembic
  4. Ignore the .ini file for this basic installation
  5. Change env.py with directions at this link.  If the app is in the Flask Mega structure then just replace with app but make sure your Config file is setup for postgres:

import os
if os.environ.get(‘DATABASE_URL’) is None:
SQLALCHEMY_DATABASE_URI = ‘postgresql://localhost/<db_name>’
else:
SQLALCHEMY_DATABASE_URI = os.environ[‘DATABASE_URL’]

  1. Create first revision $ alembic revision -m “First revision.”
  2. Find and add change scripts for upgrade and downgrade to the new revision file
  3. Migrate $ alembic upgrade head
  4. Repeat 6 – 8 for further local revisions and migrations
  5. Revise Procfile:

migrate: alembic upgrade head
upgrade: alembic upgrade +1
downgrade: alembic downgrade -1

  1. Git add all changes $ git add .
  2. Git commit $ git commit -m “Procfile and running revisions>”
  3. Push to Heroku $ git push heroku master
  4. Run alembic migrate on Heroku $ heroku run alembic upgrade head

If you get something like the following then it went well:

Running `alembic upgrade head` attached to terminal… up, run.****
INFO [alembic.migration] Context impl PostgresqlImpl.
INFO [alembic.migration] Will assume transactional DDL.
INFO [alembic.migration] Running upgrade None -> *********, Create account table
INFO [alembic.migration] Running upgrade ******** -> ********* Add zoomlevel to locations.
INFO [alembic.migration] Running upgrade ******** -> *********, Test add favorite.
INFO [alembic.migration] Running upgrade ******** -> *******, Test add favorite.

To double check changes went through on Heroku, here are a couple commands:

  1. Launch Postgres interactive environment on Heroku $ heroku pg:psql
  2. Look at tables => \dt
  3. Look at table schema => \d <table name>

That should cover it to get started. Creating a revision file and migrating locally as well as on Heroku are steps that should be repeated for each new migration.

As always there is more info out there for nuances and complexities to migration. There is also the autogenerate functionality that can automatically define change scripts for things like a schema change, but it is limited in what it can do. Check that out in the reference documents. No matter what, I recommend always taking a look at the revision file just to make sure it will do what you need. And have fun migrating.

 

Deployment is not the Devil (Flask & Heroku Tips)

On a previous post I claimed deployment is the devil because after several successful (not always easy) deployments, pushing up my Sun Finder app proved elusive. I seriously wanted to scratch my eyes out at times with all the errors and issues. Still it was a good learning experience (one that I fought against but a good one all the same), and I did finally deploy as of last week! Check it out at sunfinder.io.

So deployment isn’t all bad but it sure can be frustrating if there is a ton more work that is needed to deploy after the long haul of web app development.

To help others new to deployment and especially working with Flask, here are some things I learned along the way.

First off, if you are working with Flask then use this help page as a starting point on how to develop and setup apps on Heroku.  On the left side of the page, there are links that provide similar support for other frameworks. Just make sure to setup a repository to store your project and configure remote access.

1. Local Database

The biggest deployment challenge I had was importing a pre-populated database from my personal computer (local).

Overview
Heroku provides a Postgres add-on from Heroku Postgres which adds a remote database onto the application. When a remote database is provisioned, a config variable is assigned to the repository which usually includes a color in the name. This variable is a reference to the URL where the empty database is accessible.

DB Remote Storage Option
In order to load a pre-populated database, it has to be stored remotely in a service provider like AWS S3 (Amazon Web Services Simple Storage Service) or Dropbox and then imported to Heroku. S3 is a popular storage solution because its been around for a while and is known for its optimization. I haven’t looked into Dropbox as a solution, but I suspect its a good option as well.

High-level directions on how to setup S3 for Heroku are provided at this help page. AWS also provides pretty extensive usage directions.

IAM: User & Permission Setup
After signing onto AWS, go to the IAM section under Deployment & Management section. In this area, setup a user and obtain security credentials. Make sure to capture the credentials  (Access Key ID and Secret Access Key) for later reference. Then setup a group and assign access permissions. Go for the admin permissions setup if its just one person. Once the group is created, click on it and look below the tab section for the option to add a user. Make sure to add the user to the group.

S3: Bucket Setup
From IAM, return to the main section by just clicking on the box in the top left corner and choose S3 under Storage & Content Delivery section. In this area, create a bucket (aka root folder) to store the database. Make sure to create the bucket in the region where the app is stored which for Heroku is the US Standard region. This is important because S3 is free for in region data transfer rates. Also, make sure the group is granted access permission to this bucket. At this point the database can be uploaded.

DB: Compression,  Upload & Configuration
In order to upload a database, compress the local copy first which is also referred to as dumping. Heroku’s directions on how to create a compressed version of the file can be found at this page.  Create the dump file and open the AWS bucket in order to access the upload option. Once the file is uploaded, add the AWS security credentials into Heroku configuration following the directions on the Heroku S3 help page.

DB: Import
I followed the import directions on Heroku’s help page that explained compression but there were a number of errors (like “invalid dump format: /tmp/…/sunfinder.dump: XML  document text”). In order to resolve these problems, I logged into the Heroku Postgres site.  It showed all of my Postgres provisioned databases and when I clicked on one of the databases, I was able to see connection settings and statistics. There is an icon of two arrows pointing in opposite directions in the top, right corner that provides a list of additional options. There I clicked on PG Restore and found more explicit command directions for import. The only part of the command that needed to be changed is to swap “your data file” with the dump file name that is inside the bucket. This resolved my errors and enabled database setup.

Just remember that any changes made to the local database need to be compressed, uploaded onto AWS again and imported in order for it to be seen in the remote application.

2. Static Content

When I first read the Heroku S3 help page, I mistakenly thought I had to store all of my static content on S3 (e.g. img, js, css). Granted previous deployments seemed to work and not require this, but I couldn’t get the css and js files to load correctly on my application.  I was getting a 403 error with a link to an XML page that said “Access Denied”. 

So I loaded all the static content on AWS S3 and made it public. This actually made the application work once I changed the static file references to the new AWS location and links. Then I finally figured out that the Heroku application key configuration was incorrect and thus, the problem. So I rolled back my changes to keep the static reference links internal vs. pointing at AWS.

Using AWS to store and reference static files is more useful in situations where there is a significant amount of content and/or users are loading content onto the application. There is a lot of literature out there that provides more details.

3. Heroku Configuration & Updates

In the process of setting up the Heroku repository, don’t forget configuration. It can make things go wonky like 403 errors if its wrong. In the errors around static page loads, my configuration of the Flask app secret key was incorrect on Heroku. Definitely read this link and make sure to load all the secret keys that are needed.

Additionally, make sure to git add and commit changes in order to push updates to Heroku. If a change doesn’t show on the remote site, it’s possible that it wasn’t committed before the Heroku push.

4. Not All Browsers are the Same

Another error/warning I found was in the he Chrome browser’s Inspect EIement console: “The page at … displayed insecure content for ….”. The dots represent a link that the warning referenced. My current hypothesis is this is because I loaded HTTPS Everywhere on my computer and some of the links in my site point to sites that do not use secure socket layer protection. Its just not an option at some sites. This is just a warning and does not prevent my application from functioning. If I learn more, I will update this post.

One thing that I was reminded of while troubleshooting my app is that not all browsers function the same way. So I opened my app in a different browser to check if some errors and warnings would go away. Its just one more way to test the application and help narrow down the problems. Granted there are many browsers and versions of browsers that can impact functionality and plenty of materials on how to develop for all those variations.

5. When All Else Fails – Reboot

Initially I made the first Sun Finder deployment attempt in June. When I returned to deployment in Aug., I tried working with the already established Heroku repository and configuration. At some point in my error tackling, I realized its better to just reset and restart. So I deleted the Heroku repository and created a new one. This didn’t resolve all my errors, but it did help clear out some of the more mysterious ones (e.g. the ones unknowingly created during the learning process).

For those out there working on Heroku deployment, I still stick by a previous post comment that Rails is an easy experience, but it is very doable to achieve deployment with other frameworks. If anything it can be a little more educational at times. Just don’t let the challenges keep you from that final hill to launch.

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.

Resources
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:

Advice
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.