jlees

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).

Engineering blog: https://engineering.riotgames.com/

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.

Probably via this mention: https://twitter.com/imdsm/status/708286213975908352

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.

Amazon now offers Elasticsearch as a service; it was a great help for us quickly setting up ELK to test.

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.

As she's a she, check out Hackbright Academy. Disclaimer: I used to teach there.

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.

This doesn't feel like particularly new research - my PhD supervisor did work in the area of argumentative zoning nearly 10 years ago: http://www.cl.cam.ac.uk/~sht25/Project_Index/Citraz_Index.ht...

I initially started my PhD research looking at sentiment analysis on citations, but I found it wasn't a particularly interesting field. As the linked article says, negativity is pretty rare, and it's also something that human annotators disagree about a lot, as it can be expressed in some very subtle ways. The formality of paper publication has a lot to do about it; there are avenues for critical feedback and conflict well before the paper gets published.

I found that looking at how people talk about each other had a much richer depth of expression, although even more nuanced and harder to get annotators to agree about :)

To address the point of "game developers don't know backends, and backend developers don't know how to build for games"... I want to think aloud about the question "how do you hire engineers who can work on the backend of a large video game?".

One issue parts of the games industry struggle with is simply coding competency. There's a tendency to hire newer grads and folks who will work for lower salaries, because people always want to make games. (And why not? Making games is awesome.) This leads to turnover, poorly thought out (or over-engineered) designs, lack of "common sense" things like load testing before launch (remember the industry standards you learned at college? if your college was anything like mine, you didn't), language soup, etc. And in my experience, the best backend systems are built by those with at least a bit of that experience already - rather than gameplay programmers trying to teach themselves what the CAP theorem is. But what senior engineer wants to work with legacy spaghetti code, or unlaunched promises (and the threat of future layoffs), when they could work at Facebook or Google or whoever?

At a previous large tech company I worked at, we built a games team internally to work on large scale platform stuff (pretty similar to what PlayFab is doing but aligned with said company's products). It was really cool - we got folks who were solid engineers but also ex-games industry, or avid gamers, themselves, advertising team openings via the videogames@ internal mailing list. We tried to combine the culture/fun of the games industry without the baggage and conditions.

But platform isn't content, and I recently joined a similar kind of team in an actual games company (which operates much more like a tech company than most, since our game is operated as a live service rather than a one-off downloadable release). Being able to work alongside artists, designers, narrative writers, sound engineers, event producers etc creates a really creative environment, and though I'm working on MySQL performance tuning and internal monitoring data pipelines, I get to hang out and talk about the new champion releases with folks at lunch. A nice balance, but for those who can't afford their own platform team, or don't have the carrots to lure us in, PlayFab seem like a neat alternative. :)

This is cool, and interesting in a couple of ways. The declarations are preliminary, meaning (I presume) that students may change their minds; according to some studies (e.g. [1]), women tend to transfer out of CS at a higher rate than men. Some anecdotal reasons behind this include a hostile atmosphere/alienation [2], sexism from students and teachers, unequal backgrounds due to pre-college factors [3] and so on (of course, there are plenty of non-gender related reasons why someone might switch majors).

The flip side is, these are upperclassmen, which I understand to mean they probably have been taking CS classes for some time already at Stanford. Most of these factors would have been encountered already if they are indeed present at all, which is cheering in its own way.

[1] http://www.academia.edu/5317313/STEM_Switching_Examining_Dep...

[2] http://www.telegraph.co.uk/women/womens-business/11182833/Ho...

[3] http://www.npr.org/sections/money/2014/10/21/357629765/when-...

I'm not sure it's made life easier for him yet. He walked 3.5 metres, but how frustrating would it be to lose the use of your legs and then be tantalized by something sort-of-like walking again, but within very controlled situations? But the promise of what's to come is fantastic - my dad's a lifelong paraplegic due to polio and although this tech is too late for him, it's wonderful to think others may have a chance.

This reminded me of the Biosphere 2 experiment, which I saw a fascinating talk on. I think it was basically the same as this TED talk: https://www.ted.com/talks/jane_poynter_life_in_biosphere_2

Eight scientists lived in a closed biosphere to simulate what a potential colonization scenario might be like (among other things). The first experiment lasted 2 years, and encountered environmental issues, but also some psychological upsets - the crew split into two factions who became bitter enemies, among other things.

I think outside of the day-to-day (you need to know Python, here's how to get Vagrant running, this is how you submit a code review) there can also be a gap in cultural onboarding. For example, someone moving from a large tech company to a startup has certain norms and expectations that they may slowly re-evaluate (if they actually do) over a number of weeks or months, potentially harming the product and even their own career -- for example, "that's not in my job description" doesn't fly at a startup but can be a protective reflex at a large company. (One may argue someone with this attitude may not be hired at a startup in the first place, but sometimes the attitudes and expectations aren't so upfront and clear-cut, and are hard to test for at interview!)

Would love to find some examples of great cultural onboarding where it's not just the "what" of the work that a new hire learns, but also the why and how, to avoid implicit assumptions and biases from day one...

I think there's also a spot for board games as a social outlet that requires less commitment than D&D and is more accessible than videogaming; several years ago I used to get together with friends and bring videogame consoles, more recently it's board games (and they're super easy to play with new acquaintances too). I hate to say it but games like Cards against Humanity are, in a way, the Minecraft of board games; it starts with "party" games and before you know it you're playing BSG :)

Although you can end up with fun situations like the C compiler backdoor: http://scienceblogs.com/goodmath/2007/04/15/strange-loops-de...

This is also a pretty accessible quick intro to complexity and data structures, nicely done. Definitely the sort of thing I would include as further reading in a beginner course -- some beginners love to understand "why" and this post answers pretty much all the "why" possible.

I think another part of it was the effort required to try out new titles; I got very attached to the Dizzy series because I had to save up my pocket money and actually go to the computer shop to buy the tape. And that shop certainly didn't stock 15,000 different games :) Kind of the same way music discovery used to be, only with demo tapes instead of the radio. (I still wonder if the demoscene could come back somehow.)

With the barrier to entry being that of downloading a Minecraft mod or free app, it's harder to get anywhere near as attached, in my opinion; but I don't have kids, so I wonder what they do spend their hard-earned pocket money on instead?

For a similar nostalgia trip I recommend reading Only You Can Save Mankind by Terry Pratchett.