Compensation and BenefitsReact UI implementation;AWS implementation; AWS architecture design, including deployments.
Development Generally
Our compensation plans are rooted in transparency. Instead of a one-size-fits-none approach, compensation is tailored to your needs. If you get health care benefits from a spouse and don't need them, we'll find ways to redirect resources to other parts of your overall compensation.
Principal Software Engineer
- US $100k-$150k total compensation package (salary and benefits).
- An aggressive profit-sharing schedule.
- Paid vacation and sick leave.
Senior Software Engineer
- US $40k-$60k total compensation package (salary and benefits).
- Performance based incentives.
- Paid vacation and sick leave.
Developer
- US $25-$45 per hour.
- Minimum monthly guarantees available.
All Positions
- Flexible work hours.
- Paid training and professional development.
Ideally, we are looking for a candidate with the following skillsets capable of filling each major area of responsibility.
Ongoing work falls into these major areas of responsibilities or skillsets:
Candidates with all of the minimum skillsets will qualify as a Principal Software Engineer. We are also willing to break the position into a small team consisting of candidates with some, but not all, skillsets. These candidates would qualify for Senior Software Engineer or Developer positions.
All positions are location independent and you will have regular video-based and Slack contact with your colleagues.
All positions are location independent and you will have regular video-based and Slack contact with your colleagues.
Development Generally
Developers in any environment need to be able to handle tasks like this:
- Keep code in source control, we use Git on Bitbucket
- Use Git branches effectively for multi-developer progress
- Commit code frequently with descriptive merge messages
- Manage merges and tags for production releases
- Document changes between versions
- Develop unit tests that include catching edge cases
- Work with peers to perform code reviews
- Work with task tracking software (like Jira) and help evaluate and plan schedule by estimating how long tasks might take
- Regularly communicate progress
- Give directed technical feedback about pros and cons of feature plans rather than blindly just doing whatever gets assigned
- Think carefully about backward compatibility and future extensibility
- Whenever possible, develop for scale (and provide clarity as to why when there is a risk)
- Bonus Points: experience with or understanding of nonprofit performing arts secto
React
Object-oriented programming is a must. We have also enforced the use of Typescript on our React work, so that is an important standard to maintain. We have created a custom template for Create React App, without ejecting, that we should both use and improve upon over time.
A React developer will need to be able to understand:
A React developer will need to be able to understand:
- Functional components, hooks (including how to create your own), and a good grasp of props vs state.
- Implementing UI using the React Material UI framework, both components and styling.
- Using local or exported interfaces to define object typing.
- Using newest features of JS, like arrow functions, spread operator, when to use a Set instead of Array, and so on.
- The difference between controlled and uncontrolled components (especially because we aim for uncontrolled form fields backed by React Hook Forms).
Bonus points if you have these skills under your belt but if not, you'll be able to develop them on-the-job:
- Strongly typing data types via Typescript, not just slapping "any" down wherever.
- Working with Yarn/Lerna for monorepo development and shared libraries
- Netlify deployment
- Writing Jest unit tests
- Helpful because we use them a lot already:
- RxJS observables to deal with asynchronous data
- Auth0 for authentication
- Axios or Fetch for REST APIs
- GraphQL (ok, not used much now, but might)
- Yup for form validation
- Experience with and/or understanding of PHP object-oriented code development and the WordPress platform.
AWS Implementation
We have focused on AWS services that are pay-for-usage rather than reserved. That means Lambda functions and DynamoDB instead of EC2 instances and SQL. We have stuck to NodeJS for Lambdas so we at least have similarity between the React and AWS work.
An AWS developer should understand:
- Using Serverless Framework to define our deployments
- Leveraging a common library of functionality for Lambda functions
- Writing Lambda functions in NodeJS
- Using Axios for REST APIs and GraphQL (maybe) for interoperability
- Using SNS messaging for asynchronous communication between microservices
- Interacting between services via the AWS SDK
Bonus points if you have these skills under your belt but if not, you'll be able to develop them on-the-job:
- Developing functions in a way to manage effective separation of concerns and build up a growing library of re-usable microservices that can be completely independent of one another project by project.
AWS Architecture
We currently build around the core services of API Gateway, Lambda, DynamoDB, and SNS. A developer responsible for the growing architecture needs to be able to think about:
- How data will be managed at a macro level
- How to define the boundaries of various independent microservices
- How to project data between microservices to avoid artificial "joins" that cause bottlenecks
- When functionality is app or client specific such that it should exist in a custom microservice that links "generic" microservices together (what we have been terming a "router" service)
- How to define what is searchable and what data should appear in search results to accommodate application needs
- How to organize services designed to communicate with third-party systems, like Mailchimp, SendGrid, Auth0, or Salesforce
- Our generic microservices are built from a serverless template, so how might this improve and grow over time, lowering maintenance costs
- Think about scale and performance with an eye toward recognizing when we might need to consider reserved resources (maybe never, but still...)
- Handle deployments across multiple stages and separating dev/staging/production, which we are currently handling with Organizations for separation and Seed for automated deployment (similar to Netlify, but for AWS)
- Consider future needs and plan for that development (For example, we secure our generic microservices using API keys, but this would be better handled with the more complex VPCs - figuring out to move from one to the other is an eventual task)