I really enjoyed playing it too. One of the more fun things was seeing the scoreboard and competing against engineer friends of mine... it's fun to see that there is a better solution, and also fun to see that yours is more efficient. It feels egotistical, but to me it's a form of feedback.
I studied computer science at university, but didn't take a programming job straight away - one of the reasons was that I feared being bored (slow death by cubicle). After dipping into grad school, dropping out, starting a company (where I wrote almost all the code for our product, but did a lot of other things too) and spending several years as a product manager, I switched back to software engineering as a career, and I've never been happier.
While I was working as a PM, I spent a lot of time as a hobbyist programmer, and a lot of time learning about how to engineer good software systems. After leaving that job I spent 6 months or so just building stuff. Games, android apps, whatever I felt like. It was awesome. I turned one of those projects into a consulting gig, then another, then got hired full-time from one of those gigs into a startup where I learned like crazy and sought out as much mentoring as I could get my hands on. I maybe could have done a similar side-step at my previous job, but having talked to some folks about what that would look like, I decided to just jump. It worked out. I hope it does for you too.
I ran into a similar problem a while back (using Heroku) --- after a brief foray into the world of spam filtering, it turned out to be caused by our domain being identified by SpamAssassin (IIRC) as a spam signal. We changed the wording of our emails and moved to a different subdomain and suddenly all the email got through. It was.. interesting to debug.
Agree, I think the tone of this piece is really interesting. It's sadness, laced with evangelism; a hope that the new acquirers will recognise what makes Virgin great, and absorb those qualities rather than replace them. But mostly sadness. Not what you would necessarily expect.
Riot Games - Los Angeles, CA / St. Louis, MO - Onsite - Full-Time - Software Engineer
We make the game League of Legends, which by various metrics is the most played PC game in the world. That means we have some really fun problems that come with operating at scale, worldwide, 24/7.
We're hiring for a bunch of things (http://riotgames.com/careers) in a few locations worldwide, but I wanted to specifically plug my team, Service Availability. We basically manage all the 'behind the scenes' stuff from data centers to backend microservices. It feels like a tech startup within a game company -- many of our engineers have tech-industry backgrounds (Google, Amazon, Netflix, MS etc).
We're solving problems from the infrastructure layer up, making it easy for developers internally to launch and operate services worldwide, regardless of the underlying hardware/cloud. e.g. building a Docker-based cluster, deployment and build tools, microservice frameworks and interoperability standards, monitoring, logging, and other developer-experience type features. We're also working on services that use that stack to deliver awesome new things to players, e.g. the Riot API. We write a lot of Go, which I'm really excited about.
Our culture is also really interesting, especially for a games company. We've got some Fortune awards etc, but the TLDR is: we have work-life balance, we are focused around personal growth, individuals are very empowered to make change and be part of decision making, and we are very feedback-driven. If you like working in a silo we are not the place for you. We value engineering breadth and the ability to level others up.
If you're a gamer with a tech industry background (you don't have to be a massive League of Legends player, but if you hate the game, you probably won't have a great time working here), you like developer platforms, microservices, distributed systems and scaling problems... we should talk. I'm jlees at riotgames dot com, Jellybear ingame, or you can apply via our site.
PS: Working at a games company surrounded by people who love games as much as you do is really freakin' cool.
Just because you are smart enough to compete in an Olympiad doesn't mean you can function practically on a software engineering team. Whiteboard coding helps the interviewer see how you think and function as well as "can you solve this problem"; though I agree that it's not necessarily the best way to evaluate those capabilities, it's the best tool some companies have.
I don't really see that. I think whiteboard coding is one of many ways a team could function and that how a candidate performs on it is not generalizable. For instance, I have never written code, pseudo or otherwise, on a whiteboard outside of an interview in over eight years of writing code full-time. Hell, I used a whiteboard more in my four years as an EE and two years as a SysE than I have as a SysE/SwE.
It depends how you evaluate the exercise -- for example, don't mark the candidate on correct code and syntax, but reasoning ability, communication, and problem solving. Whiteboard code interviews also have the flaw that the type of problem they tend to cover is not one you might run into in daily coding, so the way the candidate thinks and communicates is seen through a very particular lens - but my point is that given an Olympiad-level candidate who can clearly solve those kinds of problems, I think there is still value to be had from watching them solve them.
I prefer whiteboarding systems design/architectural concepts, which is definitely something I do in the course of my regular work.
Oh, I can believe that. But the way said performance is measured -- both types -- is extremely varied. I'd summarize my viewpoint as "whiteboard interviews tell you something about how the candidate thinks and communicates, which you can use to jump into deeper explorations". Just because you know someone is smart enough to solve a problem doesn't mean it's not valuable to see how they do it.
When I was resume screening at Google, we cared about school in terms of interpreting GPA, since 4.0 isn't equal everywhere -- and we got a LOT of resumes. Once the person got to interview stage, the school was irrelevant beyond the name-brand factor it may have had with a specific interviewer.
Dwarf Fortress, as an example, has Armok Vision [0] that uses DFHack [1] which reads the data structures directly from the Dwarf Fortress process to provide an API layer to other tools and scripts. Armok Vision provides a 3D visualization to the 2D of Dwarf Fortress (in a separate process, by reading memory through Dfhack). It's pretty rad.
There's also the 2.5D "Text will be Text" plugin that actually alters how Dwarf Fortress renders tiles, stacking 2D planes so you can see more than 1 Z layer at a time [2].
Startups (depending on the size) are both wonderful and terrible places for a new bootcamp grad. There is a lot to learn, and learn quickly, which is something any bootcamp grad has had to master -- but there is often a dearth of mentoring and, as time goes on, patience for junior mistakes. Larger startups are much better than small ones, in my experience working both on the startup and bootcamp (instructor, mentor) sides of the table -- especially larger startups who have already hired from that bootcamp, or a similar one, before. Then you have the alumni-mentor train going, and life is great.
