This post is part of a three-parter:

  1. How The Job Search Went
  2. What Helped The Job Search Work So Well
  3. Differences Between The Two Tech Scenes (you’re reading it!)

Well, this has been a deep and time-shrunk dive into the Chicago tech scene. Here’s some stuff I learned, that can help you a good idea of it.

Size

Well, in San Francisco, there’s no way to get a bird eye’s view of what’s going on, since even your baker has a startup. In Chicago, the scene felt much easier to wrap your head around.

Each time I could identify that I was talking with one of the key people / hubs of the scene, they knew almost all of the other key people I had been talking with. This is very motivating to me, as this rings as opportunity to be a part of a community I can help push forward, at my humble level.

Not many big names

If you’ve been at the housewarming party of your engineer friend in the Bay Area (“Steve here works for Apple, Katie works for Netflix, John works for Google, …”), but come from somewhere else (“What do you mean you work for Apple? THE Apple?”), you’ve got to know what typical “big names” I’m talking about.

While working at Apple in California was quite unoriginal, it ultimately generates a lot of interest for employers in Chicago, where there are not that many tech big names, besides Google, GrubHub, Salesforce and Braintree.

However, the scene is not at all lacking companies with “smaller” names, but which are amazingly exciting to work for and suitable for many tastes and preferences (from the top of my head, thinking about TrunkClub, Polymathic, Kenna Security, Catalytic, Avant, …). So, if you get your kick out of working for a big name, you might find it hard to find here, but if you don’t really care as long as you love your job, it won’t make much of a difference.

More companies that have financial red flags

It’s hard to say on such a small sample, but based on the much larger sample of companies I got to discover in SF, the startup culture in Chicago seemed far less mature and understood among people. Since this makes people less able to pick up on an unhealthy startup structure, I encountered far more unhealthy startups in my small Chicago sample than in my large SF sample.

Some fun horror stories:

  • VC-backed company built some seriously valuable assets in a vertical that has notorious difficulties to innovate, and brags a lot about their opportunities to exit, probably through a purchase. Sounds awesome! Then comes the offer: no equity. Obviously, that surprised me, since their nearby and promising exit should be their #1 argument in their compensation to lure engineers, so I asked why. Answer: because the VCs (all from Chicago) forbade the executives to give any equity to non-executive employees. WHAT?? When I turned down the offer, my email explained in details why it seemed to me like it was dangerous towards the balance that ensures people work and win together, and that I didn’t feel it was very healthy that this is the way VCs sees the team, but also how the board and founders see them, since they accepted those terms; but the executives I was talking with were already aware of how shady that is, and kinda apologetic when they had to explain it.
  • Bootstrapped company (no external investment at all) says that people accept lower salaries to work there, against stock. Except the founder has a very tight grip on the company, and doesn’t seem like being interested to exit at all, ever. With no VC interest to entice him to exit, that’s pretty unlikely to happen, so the stock they put so much forward is pretty much unlikely to be sellable any time soon. Also, no VC means no VC oversight on executives, and it turns out they set up the company in a very shady way: one company is the product company, and all of the employees are located very far away, in order not to pay certain taxes; all Chicago employees actually work for another company, technically a “consulting” company, with the product company as their sole client. I didn’t ask which equity they’re granting, but if it’s the Chicago company’s stock, employees are probably not aware that the stock is very very worthless, since it’s a consulting company, and all the valuable assets are in the other one. Hm…
  • Non-technical founder couldn’t find a technical co-founder, so he had no choice but to outsource to India. Except now that his product is taking off, he has what felt like a pretty palpable disdain for engineers, since he could push his product that far without them. He now has a few engineers in-house, but they’re in a separate, darker room than other employees (no kidding!), and only work on the main product, are not helping the internal teams. Also, the main product’s decisions are still fully owned by the founder, very top-down, so it’s technically not a tech company, even though it poses as one. Also, founder would like the company to grow, but didn’t feel like sharing his equity, so he took on debt instead of VC funding, so it’s technically not a startup, but a slow-growth company pretending to be a startup. In his defense, he does allocate equity to his teams.

Don’t get me wrong, you do hear those kinds of horror stories in San Francisco too. They just seemed to occur particularly often within the week that I was in Chicago discovering companies.

Technologies

Rails was invented in Chicago, so it’s no big surprise that almost all of the monoliths of those companies had been done in Ruby. I think I heard the word “Python” once during the entire interview process (but I seem to hear it less and less in San Francisco as well, except perhaps for mobile application companies, for their server side).

The big surprise came from Go, which was way, way more used than I expected. It seems like people are switching their micro services from Node.js to Go much faster than I had anticipated. It makes a lot of sense, though, Go fares better on basically everything you need for a micro service, performance being at the forefront (compiled, multi-threaded, …). I don’t think anyone mentioned thinking about using Node.js for any new upcoming or recent services, it was either Go if they needed performance, or Ruby/Sinatra if they didn’t (I’m thinking the latter would probably be more likely to be either Ruby/Sinatra or Python/Flask in San Francisco).

Worth noting: one of the very early startups I talked to was out of this mold though, as they had an architecture entirely based on higher-level AWS products: Lambda, API Gateway, DynamoDB. But it’s definitely an exception to the rule, and that’s very much how they market themselves, rightfully so. (I was glad to have to find out more about those technologies, though!)

What else?

Well, there are countless subtle differences I noticed and that I’ll learn to discover more and formalize over the next few months and years. Are you thinking about moving to Chicago and getting into this very lively and interesting tech scene? Get in touch, I can probably help!