See the more recent gist.
The Dell Cloud Manager engineering team is growing. We're looking for seven new software developers at many different experience levels.
In this gist, I want to give you an idea of:
- Who we are looking for
- What we work on
- What your tools, process, and daily work would be like
- What your next step would be to get in touch
Briefly:
- A frontend developer with JavaScript and AngularJS experience
- A Java developer with REST experience and an interest in cloud computing APIs and open source
- A Java developer with REST experience who would specialize in VMware related systems
- Two Java developers with database and web services experience (minimal experience is OK)
- Two senior backend developers with an outstanding background in distributed systems (Java at some point in past)
We're distributed across the world - so one of the main things we prize is good communication.
We value diversity, a nonjudgemental atmosphere, and irreverent but respectful attitudes.
Caring about code quality and tests is important. And we have some nice tools in place to help (more on this later).
Caring about the customer experience and having empathy for users is important.
Cloud computing experience is not required in all cases, but an advantage.
Do you want to work remotely? Our group's headquarters is in Minneapolis, MN, but most of the engineering team works remotely. So that's an option we can discuss. Everyone gets a development laptop (MacBook Pro or Dell+Linux), but remote workers are also sent two widescreen monitors.
Do you live outside the U.S.? That's another thing we can discuss. One of the many advantages of being part of a large company like Dell is that we are set up to hire all over the world if it makes sense. We currently have remote employees in the US, New Zealand, Canada, the UK, and Ireland.
Dell Cloud Manager (DCM) is an application that allows users to deploy and manage applications across different clouds but also weaves in important but often missing things like access controls and budgets.
We're releasing a brand new version of the webapp shortly, a lot of the screenshots you'll find on the DCM website are actually from the old one.
Here's a glimpse of what the new one is like:
It sure is nicer looking but most importantly it's the culmination of significant user research/testing as well as insights gained from talking to our customers.
Developers here get exposed to a wide variety of functionality and challenges. The system auto-scales applications, automates operations on the cloud instances (e.g. user addition), integrates with configuration management systems like Chef and Puppet, and talks to systems like SAML and LDAP. Under the covers we are often optimizing databases and API calls, working on fun concurrency issues, or refactoring things to make testing easier or to bring a new feature online.
The new webapp is built with AngularJS. This makes REST calls to a distributed system of JVMs that forms the core application. Along with responding to on-demand calls (both from Angular and from users integrating via our API), there is also an asynchronous task system that is making calls out to the clouds (and a wide variety of other things).
All communication with the clouds is built around an open source cloud abstraction library called Dasein Cloud. Dasein Cloud is developed collaboratively with outside contributors and is fully open source. It's a powerful library that keeps our core code clean and cloud-agnostic. For more information and to find the code, check out the Dasein Cloud Wiki.
We also recently open-sourced Blockade, a utility for testing network failures and partitions in distributed applications that is built on Docker.
Most people use OSX for development, but we only deploy to Linux. We use recent MacBook Pros with ample RAM. We use git and GitHub for all repositories, the open-source and private ones as well.
You can develop purely locally. The entire distributed system can even be built from scratch and launched via Vagrant with two commands. This is the real system, fully configured. This setup allows you to work on things completely speculatively, attach remote debuggers, and make whatever changes you want without affecting anyone. And since you are using the same build tooling, Chef code, and launch paths as the QA and release processes do, you can have confidence things won't get weird later.
We have a formal QA team, process, and continuous integration setup.
We communicate using Slack mostly, and integrate with a lot of other development and deployment tools (including some custom integrations).
There is an informational side to this, for things like commit and test notifications the messages show up inline:
There's also a control plane side to these integrations where you can tell bots in the room what to do for you. For example we can comment on tickets inline with the chat.
Another nice interactive example is one we're building that will allow us to launch a QA instance of the system from a pull-request (hubot launch PR76) in order to try out the change live.
On that topic, we already make tests run against any PR that is submitted, and Jenkins will annotate the result. This saves the code reviewer time by giving them confidence that things are not hosed before digging in.
I could go on here, but I mainly wanted to give you a sample of the kind of tools and time-saving processes we have built. And we're always looking to do better.
Sound interesting? The next step is to start a conversation. Send an email to [email protected] introducing yourself, tell us what you are interested in, and attach your resume.
Looking forward to hearing from you!
Have minimal experience? Don't be shy about emailing!