Skip to main content

Being a Support Engineer @ 10gen - Part 1

There's a mis-conception around the role of a "Support Engineer". 

As a clue, it's not what Urban Dictionary says -

A person whose job is to answer calls from customers of a small- to large-sized company...... They are teathered to a their desk all day via phone headset........ phone jockeys usually hate their jobs.......they are are paid well enough..........until they completely burn out, and hate everyone.
 and doesn't always involve this -
Image Source:

As you can see here, there's lots of open roles in 10gen and more specifically with 10gen, in Dublin. I thought I'd write this quick blog to explain what Support Engineers actually do and why I joined 10gen as a "Support Engineer".

I could be wrong but didn't Google come up with term "Site Reliability Engineer" to do away with the stigma associated with being a plain sys admin? 

In May 2012, I moved from the Netscaler team @ Citrix, where I was at manager rank and had learned an enormous amount of the previous 2+ years, concentrating on Netscaler (load-balancing, networking, application delivery, application security, being a packet monkey, helping grow the business in EMEA etc etc) and I loved it. However, when the opportunity to join 10gen arose, I couldn't resist and to answer the many folk that have asked me -

"But you have the GSE and all this security experience, why go work on a database?"

I joined 10gen -
  • to be challenged, 
  • to be pushed,
  • to work with Adam again, 

  • to never know what a day will entail, 
  • to truly learn about the top layer of the stack (yeah, I've implemented WAFs and worked closely with the awesome Netscaler engineer team but there was still segregation and I wanted more coding/application knowledge)
  • to understand databases
  • to learn
  • to see what this "big data" thing was all about (I'd already nailed the "cloud" in Citrix, cc @securityninja ;-) )
  • to figure out the "NoSql" way of doing things; to learn MongoDB (obviously) and help make it a success; to work closely with the folk who write the code in a small, exciting start-up where I can actually bring about change
  • to learn
  • to do security, yeah I still get to do it :)
So to answer those who fear becoming a Support Engineer in 10gen will mean they'll be a phone jockey, check out the LinkedIn profiles of the guys in Dublin - 
As I mentioned before, no day is the same, but as a snapshot we answer support issues from the community and commercial cases with community being taken from the official MongoDB User Google Group and Stack Overflow and commercial cases sent directly to us. 10gen is the type of company where if you show interest or knowledge in any topic then you can quickly become the owner of that topic :)  

I've obviously done quite a bit of support work but I've already become involved in areas outside my core role (a defintion which doesn't really exist) such as security, networking, snmp, ssl, organising the weekly lunch (probably the hardest, who knew Sales guys could be so fussy), helping with the Dublin MUG, delivering brown bag sessions locally such as this one, learning to use git properly, looking at source code and mentoring younger team members. Being a young company, it truly is "all hands on deck". Everyone in 10gen does customer support in some form or another - you'll see the President, CTO and CEO answering questions on the official MongoDB User Google Group forum. I think this post sums up the benefits of everyone being involved in support better than I can.

I am definitely outside my comfort circle and there are days when I feel like I know nothing, but I'm not afraid to ask questions and I'm learning, I'm learning a lot from everyone! 

Roles in the Support Team (in NYC, Dublin, Sydney & Palo Alto) are divided across junior and senior ranks, providing an excellent opportunity (imho) at various career stages with a multitude of ways to learn, improve and progress. When I landed in NYC for training, I was astonished by the amount of "brains" but also the amount of fun everyone seemed to be having and at 34, I feel old :(

To learn more about what it's like to work at 10gen, here's a couple of more intersting blogs from some of my colleagues -


Popular posts from this blog

MongoDB Authori(s|z)ation

Introduction Having answered numerous questions on the new and old authori(s|z)ation within MongoDB, I thought I'd write a short blog post explaining how things work as there seems to be some confusion. What's New Prior to version 2.4 , there was a very basic sense of "Role Based Access Controls" (RBAC) within MongoDB as there were only two roles - read readWrite which is quite limited. For example, if the user has "readWrite", that user is essentially "root" and the user can add/remove users as well as inserting data into the database, i.e. there is no role segregation. Version 2.4 added in the following 3 core roles - userAdmin dbAdmin clusterAdmin with a notable extension such that there are now 4 roles that apply across all databases - readAnyDatabase readWriteAnyDatabase userAdminAnyDatabase dbAdminAnyDatabase This increased RBAC is a significant improvement from a security perspective in MongoDB. It is imp

Separate MongoDB Syslog by Facility

In my last post , I showed how you can set up MongoDB v2.2 to syslog its logs off to a remote syslog server. As my `tcpdump` snippets show, the syslog messages hit the syslog server tagged as "", which means that they're assigned to the "user" facility with a severity level of "info". I've received a few questions regarding the possiblity of splitting out syslog messages by facility, however, as everything is currently sent to a "" bucket, so-to-speak, this is not possibility. There is a current feature request for this capability and work will be done on this but if this is important for you, I'd strongly encourage you to vote for this feature. In the meantime, however, (whilst not ideal) you can still do some host filtering with rsyslog as outlined here .