Sprintly 1 on 1s

I have been doing on one one meetings with my team for the last couple months. Or more realistically 2 on 1 meetings since the Project Managers at my employer tend to be involved in everything. Despite being only 15 minutes long, it takes 2 hours to do all eight of them. Typically, we will ask, “How are you doing? Is there anything you thought was good or bad in the sprint? Is there anything you need to do your job?” The meeting ends up being a light chat where we can talk about issues in the project. Things that haven’t been fixed yet. Or ideas that the team member had, but didn’t want to bring up in standups. Often all people can think of is an outstanding issue that we haven’t been able to get management to solve, and we just promise to follow up on it. I find that the 1 on 1 meeting works best for the more subdued and introverted team members who don’t like to speak up as much. They have good ideas on the project, they just will not bring them up publicly.

Some people recommend doing weekly 1 on 1s, we ended up doing biweekly meeting since we are doing two week sprints anyway. I think that I am accessible enough to the team, but since some of our people are in another office it might be worthwhile to meet with them weekly.

Try doing regular 1 on 1 meetings with your team. I find its really helpful with less outspoken people!

Getting into Software Part 5: How to get your first job

I started focusing on Programming for my career after my sophomore year of college. My attempts to get a physics internship had failed and I was at loose ends for the summer. That summer I spent a good amount of time working through a Ruby on Rails (RoR) tutorial that walked me through building a twitter clone web app. This was early in my time as a programmer so I was just following the tutorial and experimenting with changing the html/css, writing views and models etc. My application didn’t branch very far from the tutorial I was following, but it did look clean and allow people to post ‘tweets’. While it wasn’t particularly impressive it proved useful in the fall when I interviewed for a contract web developer position. I was a bit unqualified for this job, which was to write a companion web application to a mobile app being developed by another student at my college. I managed to write a basic prototype using PHP, MySQL and some javascript charting. But I wasn’t able to write the application with my skills at the time. I ended up quitting that job because I was struggling in my Physics studies. Still I had more experience coding and was several thousand dollars richer.

You might think that it was easy swimming from there, but it wasn’t. My real challenge was getting a formal internship after my Junior year in college. I applied to dozens of companies and ended up doing over ten interviews, went to the career fair at my school and had a difficult time finding any summer internships that wanted me. I interviewed at a bank and a small financial firm focused around trading electricity. I have to assume I looked pretty dorky in my suit, and the software engineers that interviewed me were of course wearing shorts and t-shirts. The finance firm I interviewed didn’t even have me interview with a programmer, their programmer was on vacation that day. I ended up interviewing with their manager and then the CEO, who was 45min late for the interview. That was one of the few interviews where I was asked for references and then didn’t get an offer.

### Interviewing strategies / Tactics

Programming interviews are hyped up as being very difficult and involving complex algorithms. I have found that the hype is not accurate. Maybe in Silicon Valley itself they really do ask complex graph solving questions, but in my experience depth-first and breadth-first search were as deep as the graph questions have gotten. One of the harder questions I have encountered was in a phone screen for Google were I was asked a question along the lines of “find the set of three numbers in this list that sum to less than x”. It stumped me at the time but nowadays I know that the solution involves building up a map that caches the sum of two of the three numbers in the set.

Now lets say you have done 20 practice problems on leetcode and still feel like you can’t possible by reading to solve all the problems they throw at you in an interview, well lucky for you its not really about solving the problems. What you want to do is demonstrate that you have a good amount of knowledge on algorithmic problems and that you are good at talking your way through problems. In your day to day you won’t be solving these types of problems by yourself, you will be working with a team and discussing possible solutions. Many of the problems won’t even be algorithmic in nature they might be around business logic or maintainability. The team wants to know if you will be able to contribute to the discussion around problems that arise and that are good enough at talking about problems that you can ask for help when you need it.

Go into your interview and do your best. Afterwards take notes of all the questions they asked that you did not know the answer to. Do some research and find the answers to the problems that stumped you. Interviewers tend to use the same questions so after a few interviews you will recognize almost all the questions you get.

Understand that its a numbers game. Unless you are a top candidate you will need to do more than 10 in-person interviews to get a job. If you interview with 5 people and one of them didn’t eat breakfast, you might not get the job. I have been in interviews where I really liked the candidate and thought he would be a huge win for the project, but the other guys on the team hated him. You will do interviews where you just have a great time, everyone likes you and you have an offer by the end of the week.

### Conclusion
This post dragged out a lot and its still not quite where I want it to be. I will come back to this series later when I am better able to articulate the ideas I wanted to express here. I hope it can help someone get into software programming.

Getting into Software Part 4: How to prepare for your first job or internship?

The best way to prepare for interviews is to build websites in a similar way to what you would do in the working world.

### Programming skills Basics ###

1. Create a website by following a Node.js, Ruby on Rails, or Django tutorial depending on which Language you are learning JavaScript, Ruby or Python. There are a ton of tutorials any twitter clone tutorial works great.

2. Study Data structures and algorithms
3. Study Object oriented design at a basic level.
1. inheritance
2. polymorphism
3. interfaces

4. Play around with Git or Mercurial — we use version control tools every day at work.
5. Create a real time chat website where users can see each others messages without refreshing the webpage.

### Resume ###
Keep it short 1-2 pages

Place your education, skills and work experience in an easy to find place on the first page.
Not all of your experience is relevant, minimize the less interesting experiences and bring to the front the important experience on your resume.

If you have room for clubs and side activities on the first page you probably are not going into enough depth on your experience.

### Interview Preparation and Advice ###

The employer’s goal in programming interviews is focused around estimating how well you can talk about software concepts, see if you have anything obviously wrong about you that you can’t hide in an interview, and see how you can solve problems under pressure.

Your goal in these interviews is to demonstrate that you are a smart, driven and prosocial person who has the technical ability to contribute to the team. Secondarily, you want to gauge how much you like the team, what kind of person your potential manager is, and get a feel for what hours the team considers normal.

At this point most of the programming problems used in interviews are common knowledge. You can expect questions about data structures, sorting algorithms, graph algorithms and object oriented programming. Fizz buzz and Fibonacci and palindrome questions are also pretty common, I have even gotten a question about designing a file system. There are 10s of websites devoted to ‘interview problems’, including https://leetcode.com, and https://www.hackerrank.com. You will want to do some of these problems before you start doing technical phone screens. I recommend doing 10-20 problems. Doing more than 20 is unnecessary because the problems are not that different from each other, just make sure you try a combination of easy, hard and intermediate problems.

You want to appear clean, shave if you grow facial hairs, get your hair in relatively tidy and dress appropriately. For programming jobs its hard to go wrong with a blue button down shirt and dark colored trousers. Wearing a suit is pointless most of your interviewers will be wearing t-shirts, shorts and sandals.

Do what it takes to arrive 5-10min early. Find the office and use any convenient bathrooms you come across. Be polite to everyone in the building you never know who works for the company or if the receptionist is also the HR manager.

We will go over in interview strategies in the next section of this series.

Getting into Software Part 3: How can you tell if you have the right talents for a Software Programming Career?

If you have never programmed before, how can you tell if you have the talent needed at the professional level?

Even if you did badly in school there is a chance that as an adult you could be successful as a software engineer. The demand for software engineers is high enough that people without degrees in Software Engineering or Computer Science can get into the field. The real question is whether you can solve programming problems and demonstrate it to prospective employers.

The way I got started in programming was an online C class, and C is not a bad place to start. Although, today I recommend “learning Python the hard way” which is available at https://learnpythonthehardway.org/book/intro.html. The book can be accessed for free online but is also available in other formats that you can pay for.

Once you have gotten introduced to the language and can write simple programs with the book guiding you, take a look at Project Euler.

Go to https://projecteuler.net/archives and do 10 of the problems in python. If you can knock out a few problems in a day or two without any programming experience other than the course you are probably capable of professional software engineering. If it takes you a week to get your first problem and only a day per problem after that it might still be worthwhile for you to push forward with Software Engineering.

The Project Euler problems vary in difficulty from easy to rather complicated. Don’t think that you need to be able to do the hardest ones to get a job working as a Software Engineer. But you will find yourself dealing with similar problems on a daily basis so you need to consider if you can handle that being a significant of your daily life and the skill that you get paid for.

Getting into Software Part 2: What Skills are Important in Software Programming?

The way I see it there are 3 core skills that are important in corporate software engineering environments, understanding logical trees, finding solutions to obscure problems on the internet, and making sure you write the right solution to the problem.
These can be split into:
* Logic
* Reading Comprehension + Persistence
* Communication
**Understanding and Writing logical trees**
Understanding and writing logical trees is the primary filter in programing jobs. If you cannot comprehend and create complicated logical trees you will not be able to do the job. It is less difficult than logical proofs in an introductory discrete math class in university. The difficulty is that logical constructs are what we work with and there are very many of them.
The most popular logic problem used in software engineering interviews is called FizzBuzz. This is a pretty simple problem that is comparable in complexity to problems you will encounter as a software professional.
***FizzBuzz***
*Write a program that prints the numbers 1 to 100.
For each multiple of 3 print Fizz instead of the number and for each multiple of 5 print Buzz instead of the number. If a number is a multiple of both 3 and 5 print FizzBuzz.*
While the problem is pretty simple if you cannot work your way through it in half an hour interviewers will confidently assume that you are not capable of doing the job.
**Finding solutions to obscure problems on the internet.**
The second big skill is, “finding solutions to obscure problems”, luckily for the modern day programmer 95% of all problems have a solution on the internet. Whether that problem is accessible via google or hidden on github and stackoverflow.com is something you will have to figure out.
Sometimes finding that solution may take hours of trawling the internet and reading through the source code of dozens of dependencies. A software engineer needs to be able to persist through the search despite there being no apparent progress and the high probability that the actual issue is a small oversight that you thought was irrelevant and then forgot about.
These problems tend to be either compiler errors or figuring out how to get a library to do what you want.
**Making sure you write the right solution to the problem.**
The last big skill is making sure you write the right solution to the problem. Typically, software is used to automate internal business processes or to sell products to customers. The people who currently perform these processes manually or sell to customers are not software experts. They are business process or sales experts. Its our job as the Software Engineers to interpret the requirements of the business and turn them into explicit logical steps that fulfill the business need. This is a difficult problem and people who can do it well are rewarded.
One of the big problems in corporate software development is that the people who can deal with logical trees and have the persistence to struggle with a compiler all day are not abundant in the skills required to understand what the business wants or needs. And since extracting the business requirements in sufficient detail can be an arduous process companies will often hire Project Managers and Product Owners to deal with it.
We have gone over the most important skills for a corporate software engineer, dealing with logical puzzles and trees, searching for obscure answers to problems and building the right solution to the business problem. Hopefully, this gives you an idea of what is needed to be a successful Software Engineer.