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.
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.
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.
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.
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.
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.
I was hesitant to join a game company for pretty much all these reasons, but there are some exceptions out there. I'm working on some interesting reusable platform-level technology that wouldn't be out of place at somewhere like Google (in fact one of the projects I work on is very similar to something Google has since open-sourced). The pay is Silicon Valley level, and the company is financially stable so the risk of "Urgent company all-hands: you're all laid off" is very low. The scale we operate at is challenging and the culture is strongly geared towards empowering us to grow rather than burn out or become cogs in a machine. It's not perfect, but it's not EA either. :)
I didn't know I would enjoy lifting until I tried Crossfit. Now, Crossfit has many good points and just as many detractors - as with anything, the quality of the gym/instruction can vary a lot. But the main thing it did for me was get me through that intimidating "I don't know what on earth I'm doing here" moment, into a regular group that met 3x/week with built-in accountability and programming to take a lot of the mental friction out of exercise. If you want to get strong, that's not the main goal of Crossfit, but if you want to get fit it works well - and for me, it got me a lot more comfortable with a world of strength training - a vocabulary I was totally unfamiliar with, and frankly intimidated by.
Per the original article, minimizing the frictions that make it less likely you'll do something was really important for me. Not every exercise works for everyone - I found that I prefer a group, or solitary, environment and that mainstream busy gyms don't work well for me. Since I can't afford 1:1 coaching, I do the group stuff, but I'm picky about my gym and coach.
When I moved, I did seek out a local weightlifting gym and met with a coach occasionally, but finding a local gym with even a proper squat rack (not a smith machine) was a challenge. I enjoyed doing the Starting Strength program, though dealing with setbacks from illness, travel etc got annoying (I felt like I was always retreading the same ground) and I missed doing more rounded cardio/plyo/flexibility work, so I've since gone back to Crossfit for a while to get my base fitness back up again.
I did the same for my classes last year - beginner/intermediate Python, SQL, web development at a part-time night school for adults. Wrote a long detailed tutorial and let the students self-pace, with a bit of an intro at the start of most classes. Then the TA and I jumped in to help when students needed it, mostly by looking over their shoulders - I like the post-it idea.
A couple of issues with this approach:
- Make sure your material is good. Bugs in the material led to me repeating myself 1:1 a lot, and having to pause the class occasionally. Which leads to:
- Pausing the class is hard! People are at different stages of the material, so it's hard to find a good stopping point, though I did it a few times when something was either not resonating, or folks were going too fast and I sensed they were copy-pasting rather than fully understanding the point.
- The solution to this is to have 'core' material and then 'extra credit' stuff, but people feel behind if they haven't done all the material; nobody's happy only doing the core. In general, fear of "not keeping up" was a big issue in my class.
- Finally, some folks do learn differently, and you have to account for that. I spent a lot of time 1:1 with a couple particular students who weren't getting the tutorial format. Another felt like class was just "doing homework" and dropped out. I got around this by sending videos in a flipped-classroom approach between classes, but my students didn't have a lot of spare time and I couldn't rely on them doing anything outside class.
Hmm, I think you may find different responses based on experience level with something like ML in particular. I'm a product focused engineer (former PM) with a master's degree and an unfinished PhD in machine learning. I've also been a mentor at a 12-week boot camp where students did machine learning projects, so I totally get the "it's sexy but nobody actually bothers to understand it" argument. But with my experience level (several years real world experience and a Big Name) I think I've had more interest due to my specific background, not less.
Implementing a Go player using neural networks and reinforcement learning is really fun and taught me a lot about how said techniques work. I only covered the (much easier) 9x9 board, but would recommend it as an exercise to those interested :)
I think with a certain definition of training the argument works, but it's not clear if this is actually the definition they had in mind.
If you have the choice between hiring two people for an engineering position, one of whom can write code and one who can't, you'll probably want to pick the one who can rather than training up the one who can't. If your hiring efforts are lackluster, perhaps you can only attract the latter category of people, so you spend a lot on training people to simply do the jobs they're hired for. It's a bit like the Silicon Valley "senior engineers are impossible to find" argument right now. Nobody wants to take the burden of training a junior engineer into a senior engineer if they can hire someone who's already made their mistakes somewhere else. (Not a mindset I particularly agree with, since it implies a failure-intolerant atmosphere, but you get the gist.)
On the flip side, once someone is in a position that they are qualified to do, training for growth and development is a must-have -- 31 hours seems low to me. I definitely spent more than that in learning/development programs at Google, and I don't think that culturally they have an anti-training mindset, but I could be being too generous -- the quote on the site certainly reads exactly like your interpretation.
"The best choice" is a woolly phrase. Best for whom? Stopping all development to totally rewrite the core game engine is best from a technical perspective, but that's not necessarily the optimal solution for player enjoyment -- and would have impact on other things, e.g. the competitive aspect of the game.
Continuing to develop while totally rewriting the core leads to wasted effort and a "running to keep up" effect, though allows for a strong technical foundation, provided you actually finish it. Incrementally rewriting the codebase takes longer, but is easier to do in flight, and easy to test in a modular fashion -- and that's already happening.