Never never never store any personal data in your corporate email/google drive/password managers. Never put personal projects on your work computers. Always download all paychecks, benefits docs, policy docs, HR communications, PDFs of performance reviews, offer letters, promotion announcements, pay adjustment announcements, RSU documents, etc, to your personal drives as soon as they become available. You never know when your access to the corporate VPN or your corporate email will disappear. This will also help in case you have any litigation with your employer; you will have the docs. This is true for ALL EMPLOYERS. Also, you never know when your badge no longer works, so don’t leave anything personally important in an office. Never store personal files on a work computer as usually the IT department can see them, steal them or wipe them remotely without your knowledge.
I or people I have known have been burned by every one of these pieces of advice over the past 38 years of my career.
Including yesterday, when my employer laid off 1300 people.
I have written before about trying to get jobs in major league baseball front offices (Houston Astros – 2019, Los Angeles Dodgers – 2015, Kansas City Royals – 2014, New York Yankees – 2014), and had kind of given up after Houston told me that they could not pay me what I thought I was worth. However, Teamworks Online, which is the website that many major league baseball teams use, sent me an email notification about a job opening that said “Developer, Baseball Informatics – Pittburgh Pirates”. So, I submitted my custom-tailored baseball resume. At the time, I was rather frustrated with my lack of progress working towards a promotion at Indeed, and thought maybe a change of pace would be good. Plus, given how close the pandemic was still, I thought that they hopefully would let me work remotely.
I applied via the teamwork site. Initially, I received an automated email stating that I would not be considered for the position. However, a couple of weeks later, a fellow with the title “Director, Baseball Informatics” from the Pirates reached out to me:
Thanks for applying to our open developer role. I believe you may have received an email that you were no longer in consideration. However, that was sent in error so I wanted to reach out to see if you still had interest in the role and if so if you’d be able to have a brief phone call this week to discuss.
This was right up against the holidays, so I responded with a good time to call, and wished him Happy Holidays. He called me the next morning. We talked about my time on Usenet in rec.sport.baseball, my time in Project Scoresheet, and in Retrosheet, and the fact that I knew somebody in the Cleveland Guardians front office, etc. I also talked about my technical experience, of course, with my mixture of front-end, middleware, and backend development. I also talked about the technical screen I did for the Astros in 2019, and pointed him to the two coding projects I did, an inning simulator, and a web page the graph pitch locations and velocities over home plate using data provided by PitchFX(you can see this in the above-mentioned Houston Astros article).
And, of course, they provided their own homework assignment. They wanted me to design a “draft board” application that allowed employees of the organization to see data about potential draftees real time during a potential major league baseball draft. They wanted it to be “highly-available” and robust in a hostile network environment.
Looking back, I did do the assignment as presented. They wanted a lot of front-end features, talking about things like “Zoom functionality on the lists of digital magnets so users can see more or less of a list at once” or “A select group of users (admins) need to be able to re-rank players within a list and move/remove players from lists. These changes need to update on general users’ computers in near real-time.”
I know I wasn’t going to compete with a strong front-end developer on these kinds of features, so I concentrated on requirements like “During the draft itself, MLB provides an API that you can use to query drafted players. The app needs tocommunicate which players have been drafted in near real-time while the draft is happening.” and “This application needs to be highly available and able to handle significant service outages.”
I had significant experience developing APIs at Indeed; that is, the interfaces that user-facing applications use to get data to present to the user. And I had significant experience in making sure that the servers for that data were robust in the face of a hostile environment, or a experienced a significant load. And I could talk intelligently about security.
So my presentation was all about how this potential application would get all of the data it needed to make the application work. I talked about implementing a GraphQL service, using Amazon Web Services, monitoring with Datadog, and logging, with horizontal and vertical scalability, etc. (Sorry about all of this technobabble, but this is how I know how to implement something like this).
When I logged into the Zoom call, the director I had been talking to was there. He had three developers from his team, all of whom had been their a long time. I spent the first part of the call answering questions from them.
Then it was time to do my presentation. I spent about 45 minutes talking about the project and all of various facets that I felt needed to be developed and addressed. At the end of this discussion, I answered quite a few questions about this approach. At the end, I answered a couple more general questions, and then the call was over.
A few days, later, I heard back:
Thanks again for your time with us in this process. The panel was impressed with your technical depth and we all appreciated the time you took with the project and visualizing your thoughts and ability to walk us through it. While you were one of three strong candidates, we’ve decided to pursue another candidate for the role.
Specifically, one thing we wrestled with is how the skillset of each candidate fit with where we are as a group. The general feeling here was that your very strong middle tier skillset would be a better fit if perhaps we were a bit larger and had the ability to be more segmented in our work. Obviously, you have a number of strong skills and experience that would also be beneficial but wanted to give you some of that feedback.
I’m happy to jump on a call to discuss further but wanted to get this to you as soon as possible.
Thanks again and best of luck!
I was not terribly surprised, but I thought that this was a pretty positive rejection. I wrote back:
First of all, please thank everybody for their time. This was a fun thought exercise for me; I really enjoyed developing it.
The feedback in this email is greatly appreciated, and it is sufficient to explain your thinking. I wish you and your team (and the Pirates as a whole) great success in the future.
The Pirates are absolutely notorious as being the most miserly baseball team. The consistently have the lowest payroll. They receive a lot of revenue sharing as a result.
And it shows on the field. They last won a World Series in 1979. They went to the playoffs three consecutive years in the early 90s when they had Barry Bonds. But once he left, they did not go to the playoffs again until 2018. They had a brief stretch when they had used their advanced analytics to hire a great catcher, and had some good young players. But they never advanced past the first round.
I haven’t written in a while; life happens. I do have a few more interviews to write about since I wrote last. But that’s not what I am writing about today.
Today, January 24, 2024, is my 2,380th day at Indeed; I started here April 25, 2016. This is now officially the longest I have ever been at one employer. I worked at Claris from June 14, 1988 through March 15, 1996, which is 2,379 days.
So, what makes Indeed special enough that I have stayed for almost 8 years? Claris was a fantastic place to work; the only reason I left is that I was not acquiring new skills and I had limited opportunities for growth.
That has certainly never been the case at Indeed. I was initially hired to work on the web front end of http://www.indeed.com, despite only knowing enough Java to pass a summer course in 1997, and having never worked on a web-based product. For at least two years, I came home every night with my head spinning; I learned more during that time that at any time since college and my first two years afterwards (including my first couple of years at Claris). That team also had the iOS Job Search app in its portfolio, so I was able to expand my iOS skills at the same time. The iOS app exposed me to a new-to-me way of writing apps, using webviews to reflect Indeed pages for most of the work. I also had to learn how to write code on both the client-side and server-side for web-based APIs.
That learning continues. I worked on a team that developed a large Federated GraphQL server with a lot in individual smaller GraphQL servers connected to it. The best layman’s description is that we used a new technology to enable various teams at Indeed to put their data into a central place where all of Indeed’s software can get to it in one place. I also implemented a couple of those smaller servers. And in 2022, I joined the team that took over the iOS Job Search project. iOS has changed a lot since 2016-2017, and it has been a delight to hone my skills in Swift and SwiftUI.
Another really great thing about Indeed is that Engineering basically runs itself. Most of the time, the smallish teams decide what they are going to work on based on business goals, and decide when to work on it. Engineers have a level of autonomy unmatched by any other place I have worked.
I also really love what we do as a business. To this day, when we hire somebody, they get an Indeed tee-shirt that says, “I help people get jobs.” in Indeed blue. And everybody here takes that seriously. Management fully embraces that the job seeker comes first, and any change that hurts the job seeker experience is not made.
But the single biggest reason I stay is the people. People at Indeed are smart and friendly. Managers care about the employees more than just about any other place I have been. I feel like I can trust every single person I work with to do the right thing most of the time, and they trust me to do the same.
Indeed is not perfect. When I joined, we were a largish medium-sized company, with somewhere around a 1000 people. I was connected to every single person in the company through at most two, sometimes three other people. Engineering had a large role is defining the business goals. Most of the engineers fit into two medium-sized buildings in Austin.
We hit a huge growth spurt almost immediately after I joined. We grew so fast that we ran out of parking; Indeed subsidized Lyft rides for us, and required us to take Lyft one day/week. There were people, especially managers, that I had no idea who they were or what they did. We had to evolve our business strategy and management style to turn ourselves into a big company, which is fundamentally different. Individual employees have a lot less direct impact on the company, and that can be frustrating.
That being said, we were going like gangbusters until the pandemic hit.
On February 28th, 2020, the CEO sent out an email informing us that Indeed’s leadership team, in partnership with the Indeed data scientists and medical consultants, had determined that there was no way to safely work in an office environment, nor was it safe to travel. We were told we had to start working at home starting March 10, and we had the following week to get everything we needed to do that out of the office. March 12 is the day the NBA suspended its season, NCAA cancelled March Madness, and Major League Baseball cancelled the rest of Spring Training. Indeed had a two week head start.
While that was a pretty ringing endorsement of the leadership, the pandemic hit Indeed’s business very hard, like it did everybody else. We weathered that. In late 2021, with the economy recovering, Indeed started hiring very aggressively. I was doing as many interviews/week as I could do and stay sane, and the interview team would have been happy if I did more.
That all stopped in late 2022. And in March of 2023, Indeed, like many other tech companies, had layoffs.
It’s always hard for everybody when layoffs happen. Obviously, the people being laid off have it the worst. I know; I have been there. Some good friends were let go that day. Most them have moved on, and are back to something resembling normal, but I am sure that there are some who are still struggling.
But for those of us who are left, we all have some form of survivor’s guilt. There were quite a few reorganizations that made getting things done quite a bit more difficult.
But the biggest impact is trust. There is much more open hostility to the leadership team and to management in general. There is open anger and fear on internal chat groups. There is a lingering sense of doom that this could happen again.
I am reasonably confident that Indeed will get through this. My current job is great; my teammates are amazing. I am approaching 60 years old, and I don’t feel that my age is a hindrance at all; indeed, my decades-long variety of experience in software comes in handy quite often.
So, I hope to work at Indeed until I retire from software in a few years.
As well documented in this blog, I have applied for many jobs doing baseball statistics analysis, primarily by applying to teams directly. One day, I saw an add for https://www.sports-reference.com.
The first site from their panoply of sports encyclopedia sites was https://www.baseball-reference.com, which is an incredible, indispensable source of baseball statistics, with cross-references and links everywhere and the ability to do very specific searches.
It was originally powered by the online database by Sean Lahman. When I was in a serious fantasy league founded by one the Baseball Prospectus guys, I would download the Lahman database every year, and spend a lot of time rationalizing my own data with it, developing projections, and mapping out my draft strategy.
In 1994, I wanted to do what Sean Lahman and Sean Forman did, but I did not have the time. Of course, I also wanted to develop an automated auction site, but one of my former coworkers beat me to that.
Anyway, I got an immediate rejection letter from Sean Forman himself.
The only reason I bring it up is that I saw this excellent article on Sports-Reference today:
I am going to take a few moments and discuss backing up your computer data. This is something that all experts say everybody should do, but it has not necessarily been easy throughout the years that computers have become ubiquitous.
My first job was working on the Apple IIGS. The first few weeks, I did my work with only floppy disks. My first hard drive was called a “Sider” (get it? Apple Sider? Those 1980’s people were so clever). This thing was loud; it sounded like an airplane when it was running, and it make loud, clunking sounds when you actually read or wrote to it. The linked article said that the capacity was 10 MB, but I thought my first one was 5 MB. And only 3.8 was usable. We were using ProDOS, the file system that GS/OS ran on, but this hard drive had non-removeable partitions for DOS 3.3 (the Apple OS; not the IBM/MS OS), Pascal, and CP/M. You could make those partitions small, but they still took up a lot of space you could not get back.
The worst things about these drives is that their failure rate was pretty high. Mine failed early in my tenure at StyleWare, since it was a hand-me down from somebody who had gotten a bigger more modern drive. I did not yet have a huge amount of source code written, but what I did have was on a floppy disk. We did not yet have file servers on our AppleTalk network, and even if we had had them, the IIGS would not have been able to write to them. I got that drive replaced with a CMS 20 MB drive that was faster, bigger, and quieter.
One January day, Apple sent us a new version of GS/OS (I think they sent us a 15-pack of sets of floppies). While exploring what in the new OS, I found a command-line utility to back up a hard drive to a set of floppy disks. Sweet!
We had hundreds of 3.5″ floppy disks sitting in our storeroom. At one point, it was cheaper to buy them ourselves and send them to the manufacturer producing our packages than it was for the manufacturer to buy them. This changed at some point, so we had a ton of them left. So, I grabbed a bunch, and started the backup.
46 floppy swaps later, my drive was fully backed up, and I took those disks home. The next day, I ran an incremental backup that produced 1 floppy, and I took it home as well.
The next day after that, I arrived at work to chaos. Somebody had broken into our office the previous night. They stole the computers off the desks of four of us, including mine, and they trashed our offices while they were at it. The front door deadbolt had been pushed through the aluminum door frame. It was a big mess.
But they also stole my hard drive. Boss man got on the phone and ordered new machines for everybody, but they were going to take at least 1 day, if not 2, to get there. Two of the other developers started packing boxes to help out our shipping backlog. The other one that was not me wasn’t feeling well anyway, and had called in sick.
I had worked two summers previously doing data entry. For those people too young to know, there was vast system of papers and cards and the like that the industry wanted computerized, and they hired people to take this data off of the paper and type them into databases. I had done that with an private jet airplane broker a couple of summers earlier. Now, I looked around, and saw that we had hundreds, if not thousands, of registration cards that had not been processed. So that is what I did that day.
The next day, we got our new machines, with new 60 MB hard drives (wow!). One of the developers had no backup of his source code at all. He reverse engineered source code from compiled object files on an as-needed basis. The other two affected developers had both old electronic versions of their source plus more recent printouts. They had to type in the changes from their printouts.
I had my 47 disk backup. I ran the restore program, and a couple of hours later, I was back up and running.
After Claris bought StyleWare and I moved to the Mac, I setup a product called Retrospect Remote to back up our source code database, using a tape drive. This lasted a couple of years, but the support of the tape drive was a problem, and if you don’t have a drive, you can’t restore.
We really did not have backups at work at that point.
I finally bought my own personal computer in 1990, and used a lot of hand-copying to floppy disc to back up my own data, as the backup software available for Mac was very expensive. In 1994, I replaced my trusty Mac IIci with a PowerBook Duo 250 with a Duo Dock. The Duo Dock had an 80 MB drive in it. I was using this drive as a backup, but before long, I was also using it as a primary drive, as the Duo itself had a small drive in it.
I was trying to move everything around and set up a more reliable and easier backup scheme, but I got the sequence wrong, and I formatted the Dock’s drive with no backup. I lost all of my financial databases and spreadsheets, source code for earlier projects, and some personal writing projects, both prose and music.
I started being much more disciplined about backing things up and having backup strategies after that.
Fast-forward to 2010: I had Dropbox, and I used it to backup my most critical financial files. I had an external drive that I backed my home directory, or at least, most of it, as the drive was smaller than my home directory. I bought a RAID array to backup everything to using Apple’s Time Machine.
I made the mistake of encrypting the RAID array, however, and when one of the drives failed, I lost the backups completely, so I had a few weeks while I had no full backup while I replaced the drive, rebuilt the array, and then backed everything up to it again.
Not something you see everyday…
On Labor Day weekend in 2010, there was a huge wildfire in Bastrop, TX. We weren’t near Bastrop, which got most of the national coverage, but we had a fire of our own in Steiner Ranch in Austin. We had about 30 minutes to evacuate the house. I grabbed a laptop and my external drive, and we left for a few days, not knowing what was going to happen to our house. When we returned, the house was fine. However, this scared me, as there were 24 houses lost in Steiner Ranch that day. If our house had burned, a LOT of my data would have gone with it.
So I started looking for online backup. I settled on CrashPlan, which I had heard about on a podcast. I got it installed and started my first backup. At the time, I had AT&T U-verse, which had an upload speed of 12 Mps. This was going to take a while…
It took months before I had a complete backup. And along the way, it had some problems. It is a Java program, which means the amount of RAM it can use is set beforehand. Well, that setting was too low for my dataset, and I had to Google around until I found the answer to how to increase the RAM. You have to launch a hidden console, and type commands. Don’t know why this is not just part of the settings for the application.
In 2015, Apple introduced Apple Music. One of the features is that you could combine it with iTunes Match and have one big library with everything you already had in the Music app combined with everything you add with Apple Music. This was exactly what I was hoping for, and when it worked, it’s fantastic.
Unfortunately, there were some serious problems. Jim Dalrymple, a famous tech-blogger about all things Apple, had major problems and wrote this article that went viral (“Apple Music is a nightmare and I’m done with it“). Famously, the people at Apple contacted him and managed to salvage most of the lost tracks.
That’s nice when you are a media mogul. I discovered that iTunes had deleted about 2500 tracks. Now, I had the original CDs as backups for most of them, but they were in storage.
Crash Plan did not help me because it had not finished my first backup yet. Time Machine had already deleted the backups with the known good copies of the missing tracks. Fortunately, I had hard drives archived in my safe deposit box. After writing a lot of hacky shell scripts, I managed to restore my music library. I think.
I finally got tired of Crash Plan’s problems, and tried out Backblaze. They were expensive, but were highly recommended. By this time, I had abandoned U-Verse, and had Time Warner Cable/Spectrum/Charter internet, and my speeds were much better. Crash Plan was still very slow.
I installed the trial of Backblaze, and it backed up everything in about 3 days.
Wow.
There were some gotchas. The default plan only keeps deleted files for six months; you have to pay to keep older versions. Of course as time goes on, that bill grows….
But this is an amazing product.
Now, I use iCloud for critical/recent files, Time Machine backup to a local disk and to a remote server in my house, archive hard drives that I rsync to and throw in my safe deposit box every few months, and Backblaze.
So, when I got this email, I was very excited:
Hope all is well! I have an awesome opportunity in that I think might be a great fit for your background. Backblaze is a world leader in computer backup and cloud storage and they are aggressively hiring a strong Senior Software Engineer who has strong backend coding experience in java. They are located in San Mateo, CA but are also looking to hire 100% employees.
Check it out and let me know your thoughts. Thanks and I look forward to hearing back!
(I assumed correctly that she meant “100% remote employees”).
I responded very quickly:
I would be interested in looking a job description. I am a Backblaze customer and am impressed with the product.
She responded, asked for a resume, and we set up time for a phone call. In that call, I told her that I was basically happy at Indeed, but was very impressed with Backblaze’s technology, and was intrigued by working there.
I then got to talk to a phone screener at Backblaze. They gave me a homework assignment. I had to sign an NDA that I would not disclose details of that homework assignment publicly, but I can say that it was a simple program to use Backblaze’s B2 API to do a simple operation over multiple files. It was a lot of fun to do! I got it done in a few hours and sent it in.
They first had me interview for a position for their Mac client. However, when I found out what the architecture of the Mac client was, I was not super-impressed. The core engine seemed awesome, but the the basic user-interface code seemed very dated.
So, they set me up to interview for a server position. They worked with me to spread the sessions out over a couple of weeks.
The sessions themselves were interesting. The most challenging for me personally was the session testing my knowledge of concurrent programming. I had fun, but it’s definitely not my strong muscle.
After I went through the entire interview, the recruiter contacted me, and said that they would not make me an offer.
I have been thinking a lot as to why that might be. There could be multiple reasons:
My programming skills just weren’t good enough. I already mentioned the concurrent programming session, where I know that my skills aren’t as developed as I would like, but it could be that I did not do well on other sessions and did not realize it.
A lot of people asked why I wanted to leave Indeed. I responded that I was happy there, but I was really intrigued by Backblaze. Plus, with the VP I talked to, I mentioned my dissatisfaction with the fact that I hadn’t had a raise since I had been there.
For whatever reason, they did not hire me. I learned stuff during the interview, and generally had a good time, but it’s always disappointing when somebody tells you “No”.
Recruited by Tech 