Joining Dgraph team

From Dgraph Wiki
Jump to: navigation, search

Dgraph is a distributed, low-latency, high throughput, native graph database. It's written from scratch in Go language, with concurrency and scalability in mind. Also, because Go checks all the boxes that C++ does but is lot more fun.

We call the team minions, based on the movie Despicable me[1]. Note this excerpt from the discuss.dgraph.io thread[2].

They're fun, excited, positive. They make mistakes, but they resolve them within themselves. They're great team players, who work without ego. They're respectful but also willing to make fun of each other. I think minions represent our team culture pretty accurately.

Minions

At Dgraph, we focus on the quality of code, design, and execution. We critique each other's work, which we do via strict code reviews. Without an LGTM, nothing gets checked in. If something which made sense yesterday, no longer makes sense today, we go back and fix it, which means refactoring it, rewriting it or entirely removing it. At Dgraph, logic wins over personalities. We follow Dennis Bakke's distributed decision-making practices[3].

If all this sounds exciting to you and you want to join the Dgraph team, here're a few things you should know.

Growth Strategy

We believe in having a small surgical team of excellent engineers with great pay and equity. In particular, this article by Allan Kelly accurately describes our view on team size and hiring strategy[4].

Interview Process

Technical Quiz

At Dgraph, we don't do the typical two phone screens + five onsite technical interviews popular in many tech companies. We feel such interviewing systems are manually intensive and subjective to the personality, status, and mood of the interviewer. The sort of questions asked favor quick coding of simple questions or class taught algorithms which most professions move away from after graduation. So, fresh graduates tend to do better compared to experienced professional engineers. Also, it's very stressful to candidates. Instead, we follow a different system.

We've designed a technical quiz to judge the technical understanding and skillset of our candidates. This quiz doesn't require any coding and is based on multiple choice questions[5]. The quiz is designed to test both computer science concepts and practical world knowledge. We've seen candidates with distributed systems experience perform better at the quiz than fresh graduates or candidates with only frontend experience. This is in-line with what we aim to achieve with the quiz. Also, because we can go through many questions in the span of an hour, we can test the candidates in various fields and determine their strengths and weaknesses better.

We're planning to use our in-house built, open source system called Gru to run this quiz. Gru is designed to be adaptive, so based on candidates' performance, it would change the questions to maximize their chance of scoring higher. Harder questions carry more score than easier ones.

Warning:There is negative scoring. So, please don't guess the answers.

Phone call

If you do well in the technical quiz, we'll quickly reach out to you and set up a call with you. This call is mainly to get to know you better, understand your motivations of joining Dgraph, understanding your background, and in general, getting a sense for whether you would be a good cultural and technical fit.

If this goes well, we'll invite you to our #Boot Camp program.

Referral

If one of our current team members has previously worked with you and vouches for you, we can directly bring you to our #Boot Camp program.

Contributor

If you're an enthusiastic contributor to Dgraph and have been active on our communication channels, contributing code and helping others; we can directly bring you to our #Boot Camp program.

Boot Camp

Boot camp is a very important part of our interview process. It lasts six weeks and is a way for us to work with you over a period. During this time you'd be working as a team member in full capacity. This is the best way to judge whether we're mutually a great fit or not.

You'll work on a medium complexity problem on Dgraph's core, and you're expected to be able to finish that project gathering all the right resources. It's meant to test both your technical abilities and your level of independence, responsibility, and communication.

During boot camp, you'll be getting paid the full-time rate, based on our open salary formula[6]. Also, you'll be eligible for some of our perks, for, e.g., co-working space and free Amazon Kindle and unlimited books.

I have an existing job, and I can't join your boot camp.

If your company allows taking time off, we will encourage you to do that. Financially, this should be possible given you're getting paid full-time salary by Dgraph Labs. If however, you're still unable to join boot camp for the full duration of 6 weeks, let us know. We understand that this can be a problem for people, and we're willing to work with you to find a solution.

What is the point of the boot camp?

The boot camp would be a way for us to judge your cultural and technical fit based on #Dgraph Core Values.

Is the boot camp remote?

Dgraph's team is distributed. We expect team members to be located in favorable time zones, though, which allow at least 4 hours overlap every day. We don't want our team members to complicate their life by working additional late hours, so this 4-hour overlap should be from 7 am to 7 pm local time. Our team presently works out of Australia(Sydney) and India. To make the overlap happen during the boot camp, you might need to relocate somewhere closer.

After you join

The first thing that you should do once you join the bootcamp is to ask Manish for @dgraph.io email.

Kindle and books

We focus a lot on learning so someone from within the team should be sending you your Kindle and the two books Getting Things Done[7] and The Go Programming Language[8]. We are big fans of David Allen's GTD philosophy and follow it for all our projects and subtasks.

Github

Share you Github profile, so that we can add you to Dgraph organization[9]. It's also mandatory for the team members to sign all their commits. You could use keybase[10] to manage your GPG keys and for tracking other team members. If you wan't an invite, give us a shout. Here is how you could setup[11] GPG signing with your keybase key.

Community Channels

Create an account on Slack and Discourse as mentioned in Communication_channels if not already. We use these for interacting with the community as well as for general chit chat to discussing implementation details. Someone from the team would add you to the private channels here.

Asana

We started using Asana recently for managing our tasks. Ask minions to invite you to Asana, so that you can get started.

Weekly meeting

We have only one meeting which happens on Friday. The purpose of the meeting is to go through all tasks that were done in the last week and to review and prioritize tasks to be done in the upcoming week in accordance with the GTD philosophy. Ask minions to invite you to this meeting.

Amazon EC2

Some of us use Amazon EC2 instances for development. We can create your account on Amazon and then you should be able to boot up an instance. We have a Dgraph dev Linux AMI in N. California region which can be used to boot up your EC2 instance. It has all the essential tools you would need for development as well has the Freebase film data loaded into Dgraph for testing.

Backing up your code

We have setup hour hourly backup of all the code in our GOPATH to S3 using Duply[12]. You can use this script[13] to do the same.

Dgraph Core Values

Note:As we iterate on our values and get more experience with them, they might change. Consider these v0.1.

Honesty and transparency

  • You're always honest, even if being honest might have negative consequences for you.
  • You understand that there's a zero tolerance policy about dishonesty.
  • You always state your thoughts immediately and with honesty.
  • Don't sugar coat it. But be respectful.
I don't think your idea will work, because of X, Y and Z. Then focus on X, Y and Z.
This is a stupid idea.
That's a good idea. Let's come back to it later.
  • Instead of asking is this something the team should be told, you ask: Is this something the team shouldn't be told?
  • You share early in the decision-making process, to avoid any big revelations later.
  • You do all technical communications in public (category dev or user).

Get things done, make them look nice

  • Make small progress, all the time.
  • You never end a meeting, without clarifying the next action items.
  • You make decisions as soon as you have all the information.
  • You look for ways to unblock yourself, and act -- even if that means you might have to undo what you did later.
  • You persistently push others if you're waiting on them.
  • You never stall.
  • You believe the Devil is in the detail[14].
  • You make it a point to understand the details - considering how, when, whys important.
  • You aspire to be thorough in whatever you do, and question others to understand what they do.
  • You make it look nice.

Focus on self improvement

  • You're conscious of your current level of productivity and happiness and make continual changes to grow.
  • You have higher expectations of yourself than DGraph does of you.
  • You practice activities and develop habits that will improve your mind and your body.

Focus on actionable steps.

  • If you think something doesn't work, be concrete about what exactly doesn't work.
  • Be ready to follow through with concrete suggestions about what could be changed.
  • Be ready to stand your ground, if you truly think something can be done to fix it. Others won't see it as clearly as you do.
  • Alternatively, if you have no concrete suggestions, write down your thoughts on discuss but don't waste team's time reiterating yourself.
  • Experimentations are a great way to try out new things.
  • Ask to be a decision maker.

Be targeted towards clarity

  • You talk, code, design and write in a clear way, instead of being clever.
  • If you think the other person didn't get your point, you ask questions to ensure they do.
  • Similarly, if you didn't exactly understand what the other person means, you ask questions to clarify it.
  • You vocalize your assumptions and ask if they are the right ones.
  • You avoid monologs. You give others time to comprehend and ask questions.
  • You invest in a clean and clear documentation.

Be frugal

  • You're frugal, but not cheap.
  • You innovate to avoid unnecessary costs to the company.
  • You spend money on things only after determining a clear value.
At Dgraph, anyone can be a decision maker. Hence, anyone can make financial decisions on behalf of the company. So, this value makes sense in that context.

Sounds interesting?

Reach out to us at [email protected] with your resume and we will take it forward from there.

References

  1. https://en.wikipedia.org/wiki/Despicable_Me
  2. https://discuss.dgraph.io/t/screening-quiz-commandline-tool-and-server-written-in-go/227/2?u=mrjn
  3. The Decision Maker by Dennis Bakke. Summary on Slideshare
  4. http://allankelly.blogspot.com.au/2015/10/software-has-diseconomies-of-scale-not.html
  5. https://en.wikipedia.org/wiki/Multiple_choice
  6. Open culture at Dgraph
  7. https://www.amazon.com/Getting-Things-Done-Stress-Free-Productivity/dp/0142000280
  8. https://www.amazon.com/Programming-Language-Addison-Wesley-Professional-Computing/dp/0134190440
  9. https://github.com/orgs/dgraph-io/people
  10. https://keybase.io
  11. https://www.ahmadnassri.com/blog/github-gpg-keybase-pgp/
  12. http://duply.net/
  13. https://discuss.dgraph.io/t/doing-backups-to-amazon-s3-buckets/405
  14. https://en.wikipedia.org/wiki/The_devil_is_in_the_detail