Career Timeline

My time at Indeed has had me working across a handful of teams at this point doing a variety of interesting things. I’ll just home some highlights for brevity’s sake.

When I started at Indeed, they were using an in-house plugin system to serve each team’s part of the experience. This system had a global Redux store to pass things between plugins, and teams wrote their plugins using React (class based) and their own Redux store. It was a complicated setup with its own performance concerns, and it took developers some time to ramp up. I worked on the Job Value team who built the campaign experience for the small to medium businesses. I had no experience with React or Redux at the time so I spent quite a bit of my first week or two working on learning these technologies when I wasn’t at work.

During my time on this team, I decided to change to a full stack role which is what I wanted in the first place. I worked with my team lead to make some commits in our back-end written in Kotlin, a language I had zero previous experience with. Our lead was of the mindset that if you can program then the language is just a tool and you should still be able to function on some level in new languages. He was correct as I got in a back-end change with unit tests in Kotlin while still handling my front-end work load. During this period, Indeed migrated to a new federated modules system with function based React components and a new component library. I became very excited about this much better approach and decided to keep my front-end focused role.

A little later, I was offered a spot on our platform team who built and maintained developer tooling, our core website systems, and data driven tools for leadership to more easily track specific things. I maintained our custom eslint plugin which enforced the usage of our new design system in components, built several data rich reporting products, and even took on a solo project which automatically detected accessibility issues in our QA environment, then made Jira tickets for each violation. This solo project actually became my focus once the value of the tool I built was realized, and I worked on this for quite a while.

A couple layoffs and too many re-orgs to count, and I found myself on the Job Posting Experience team. Now I work on the core job posting experience for employers. Everything is thoroughly A/B tested, I spend time in DataDog to detect logging or render issues and determine how often users see a specific experience, and we are currently working on a new architecture/rebuild of the product to eliminate tech debt and Formik. Additionally, Indeed is doing away with engineering specialties meaning we will all be full stack so my title is about to become “Senior Software Engineer”. My team is also working on leveraging AI to extract data points from job descriptions so those fields can be filled in automatically for employers during the posting process, migrating away from deprecated components to prepare for the next major release of our component library, and standing up a new back-end to eliminate the need for local and session storage. Yet again, I have found a dramatic and interesting shift in the kind of work I am doing, and I love it!

In my earlier days at R4, it was just me and the developer that eventually became their architect working on the front-end. The other developer was a co-founder for SnagApple and eventually asked me if I was interested in being their last co-founder. I accepted the offer and immediately began joining their video conferences and working in their code bases.

SnagApple was the brainchild of a top-of-industry real estate agent, and the idea behind the company was to create a system allowing other real estate agents to stand up a website with their branding, messaging services, and rich analytics that would populate their listings with MLS data for their area. Basically, a real estate agent could sign up and immediately have a site with area listings that could generate leads and let them message potential buyers. A lot of the discussion with co-founders was centered around costs, features, design, and a lot of the more business-centric aspects of running the company.

My development responsibilities were to finish building out our front-end while standing up and developing the client backend site. The backend was where the clients could see analytics for their listing, respond to any questions sent by users, change the branding and theme of their site, and more. I assumed the responsibility for building this in its entirety and made all the related technology decisions.

Ultimately, I decided to leave my large amount of equity due to the fact that I lost faith in company and the costs of maintaining our servers was about to impact me a lot more. Some other companies beat us to market with the same idea and AI was beginning to appear to be a more immediate threat to our business model. Additionally, Apple actually threatened to take us to court merely because we had the word “apple” in our name which diverted a lot of time and resources to figuring out how to handle this threat from a company with deep pockets. As much as I wanted this company to really succeed, I had lost too much faith in the company to continue giving it my spare time.

R4 was a young company when I was hired. Their Java backend devs had created their front-ends and even created their own TypeScript based front end framework that worked a lot like Angular and read a lot like Java. During my earlier days at R4, I actually worked in and even contributed to this framework. R4 was growing and wanted to devote more resources to the front-end. Since there was no documentation for their in-house framework and the learning curve was quite steep, the other front-end developer and I sold the company on switching to just using Angular.

In the following months, we migrated existing applications to Angular and made several other architectural decisions to streamline and improve the front-end development process at R4. They eventually saw the need to hire more developers so I became somewhat of a senior/lead developer and my colleague got the title of “architect”. We both had a hand in hiring, onboarding, and mentoring the new developers.

Being that R4 was a startup that was based in Connecticut, they arranged to have a small office in Austin for front-end and dev-ops teams. I worked mostly remotely with occasional visits to our small office and some flights out to Connecticut for big company events. While I enjoyed working for R4 and saw definite potential to grow there, I felt as if I needed better benefits and job security so I ultimately decided to seek employment elsewhere.

Fresh out of MakerSquare, I started working for Kapsch TrafficCom as a front end developer. The Austin office had been creating desktop applications for clients to control and monitor the tolling solutions Kapsch had designed and built for them. The company wanted vastly to improve their front-end experience and begin building web applications for clients instead of the clunky desktop apps they had been building.

Kapsch hired four front end developers in quick succession to begin improving the front-ends of their existing apps while beginning work on the new web applications. I had to learn ActionScript and Flash because Kapsch built their desktop applications using Adobe Flex. There was also some backend work I occasionally had to do using Python. Needless to say, I was not a huge fan of this tech stack and was happy to devote as much time as I could getting the MVP for the first web application shipped.

Being that Kapsch had not built any web applications, my small team of front-end developers got to decide which technologies we used, and we chose Angular.JS which was very popular and had good support at the time. We stood up a new code base using Angular.JS, adapters to make SOAP calls to the backend using JSON instead of XML, and other technologies we deemed best suited for the job. Over the next couple of years, we built complex data visualizations, forms to changes prices at each gantry, screens to monitor the camera feeds from the toll roads, and even a traffic map built using a map API and geo JSON data that resembled how Google Maps shows traffic using data from our roadside sensors to monitor the flow of traffic.

I was trusted with a lot of tech decision making considering it was my first professional developer job. I was also exposed to a lot of different technologies, handling the challenges of version control while working in code bases with a team of developers, and even architecting front-end applications from scratch. In retrospect, I feel as if this was the perfect first job for a developer since it was a very fast-paced environment with very little in the way of restrictions, which allowed me to be exposed to a lot of new things all at once.

For 12 weeks, I attended MakerSquare's full-time software engineering program in Austin, TX. I learned modern web development technologies including JavaScript, HTML, CSS, Node.js, Angular.js, MongoDB, Git, Ruby, Ruby on Rails, Sass, and more. I already knew how to write code, but I felt that attending a boot camp like MakerSquare would give me the experience and knowledge about modern web technologies to hit the ground running in a software engineering role. Boy, was I correct!

IBM Global Services provides IT support for companies that wish to source that work from a third party rather than hiring their own people. In my case, I was a part of the AT&T account and covered the area between Ft. Worth, TX and the Texas/Oklahoma border. I had an office in the large AT&T call center in Wichita Falls, but every AT&T garage, office building, etc fell under my responsibility.

Essentially, if an employee at one of my client sites had a computer or network issue that the help desk could not resolve, a ticket was dispatched to me to resolve the problem within a given time period that was based on the severity of the issue. Obviously, it made sense to solve as many problems as I could remotely since the travel time to some of my sites was considerable and filing expense reports for my mileage was a bit of a hassle. IBM gave us some software to address some things remotely, but I found it very limiting. I began writing scripts to solve many of the more common problems I was encountering, and since I was on an Active Directory network, it was fairly simple to execute these scripts on remote machines unless the client was having network adapter issues or their machine had fallen off the network.

Over time, my collection of scripts grew very large. It reached a point where I had folders with massive amounts of .bat and .vbs files that I had to search through to find what I needed to resolve a ticket. I decided to create a desktop application from my collection, providing me with an organized list of tasks I could perform and an area to add multiple host names or IP addresses to target. Working this way was so fast and efficient that my manager noticed that I was consistently a top performer on the account so he asked me how I was so successful. When I told him about my application, he had me take the steps to publish it within IBM and present it to me team so they could use it as well. I even added an update notification system to keep everyone on the latest version more easily and usage statistics collection so I could show IBM how much it was being used by my colleagues.

I had been studying for my CCNP and MCSA certifications during this time in hopes that obtaining those certifications would take my career further. A funny thing happened, though: I realized that my IT job had become a software job, and I started thinking about how I originally wanted to be a software engineer earlier in life. I began thinking about what it would take to make this career change happen. It was then that I applied and got accepted to MakerSquare to learn the modern web development technologies, so I put in my notice, sold off most of my possessions, and moved to Austin to attend MakerSquare.