ismarc
Joined 17 years ago
Joined 17 years ago
We work on a wide variety of projects with a heavy emphasis on automation, and are striving to increase engineer self-service capabilities. Experience with any specific items in our stack are not required, we expect only that you're a generalist enthusiastic about learning (with our full support of course). There is no on-call aspect to this position, and we have a strong emphasis on sustainable working hours (9-5, five days a week, with meeting-free Focus Friday to work on pet projects).
A quick list of some of our stack: Containers, Ansible, Jenkins, Cloud IaaS (AWS, GCP, Azure etc), Slack, Node.js, github.com, Bash
TO APPLY
Attempt to solve our engineering puzzle (we promise it's fun, submissions go directly to engineering, and it's how all three of us came to work here) at https://www.conjur.org/careers/puzzle/.
A list of the keywords that an automated scanner would search your resume for: https://www.conjur.org/job-openings/infrastructure-engineer/
----
LEARN MORE
- https://conjur.org (our secret service, LGPLv3)
- https://www.conjur.org/careers/ (about our team, open positions)
- https://www.conjur.org/blog/ (our blog, which talks more about who we are and what we do)
ABOUT US
We work on a wide variety of projects with a heavy emphasis on automation, and are striving to increase engineer self-service capabilities. Experience with any specific items in our stack are not required, we expect only that you're a generalist enthusiastic about learning (with our full support of course). There is no on-call aspect to this position, and we have a strong emphasis on sustainable working hours (9-5, five days a week, with meeting-free Focus Friday to work on pet projects).
A quick list of some of our stack: Containers, Ansible, Jenkins, Cloud IaaS (AWS, GCP, Azure etc), Slack, Node.js, github.com, Bash
TO APPLY
Attempt to solve our engineering puzzle (we promise it's fun, submissions go directly to engineering, and it's how all three of us came to work here) at https://www.conjur.org/careers/puzzle/.
A list of the keywords that an automated scanner would search your resume for: https://www.conjur.org/job-openings/infrastructure-engineer/
----
LEARN MORE
- https://conjur.org (our secret service, LGPLv3)
- https://www.conjur.org/careers/ (about our team, open positions)
- https://www.conjur.org/blog/ (our blog, which talks more about who we are and what we do)
ABOUT US
We're a busy team, thanks to the increasing success of our product: the Conjur appliance secures the entire software development and deployment lifecycle for companies who want to ship features as fast as possible without increasing their risk of security breaches.
We are looking for experienced software engineers to join our team. Conjur engineers work on a wide variety of projects, from integrations with some of today's most popular DevOps tools to moonshot projects that seek to revolutionize the way engineering teams factor in security when deploying applications.
We know that if you're a professional engineer, experience with specific tools or languages can usually be picked up quickly. That being said, Conjur engineers are using the following tools on a more-or-less daily basis:
* Ruby, Rails, Golang, Postgres, and JS
* Docker, Git, and Jenkins
* Kubernetes, OpenShift, Cloud Foundry
* Puppet, Chef, Ansible
FOR MORE INFORMATION
https://conjur.org (our secret service, AGPLv3) https://www.conjur.org/careers/engineering.html (about our team, and our DevOps puzzle!) https://conjur.org/blog (our blog, which talks more about who we are and what we do)
They get, at worst, normal minimum wage.
Not going to post the whole job description here, it's available at http://www.invodo.com/careers/test-automation-engineer/. We're looking for a developer with a strong testing/QA background or a QA engineer with strong development background. If you have questions, or are interested but don't think you meet all the requirements, drop me a line as well.
Reachable at [email protected]
Someone elsewhere in the thread said that the poor aren't good with managing money. From my experience, it's the opposite. Imagine you're behind on every bill, with less money coming in than it costs to have electricity, get to and from work, eat and pay rent. You literally rotate which bills get paid based on what will be shut off next. If someone gives you $100, you could pay more of the bills, or put it in savings, or spend it on entertainment/something fun. In 3 months, no matter what happens, you'll be back in the same state you are now. Spending it on entertainment to feel like a person isn't a bad decision at that point. It's just not one that those who live privileged lives would make
Using this type of setup, we had 100% availability for our customers over a period of 2 years (up until a couple of weeks ago where the flash 12 upgrade caused a small amount of our customers to be impacted). This includes the large outage in US East 1 from the electrical storm, as well as several other EBS related outages. Overall costs are cheaper than setting up our own geo-diverse set of datacenters (or racks in datacenters) thanks to heavy use of reserved instances. We keep looking at the costs and as soon as it makes sense, we'll switch over, but will still use several of the features of AWS (peak load growth, RDS, Route 53).
The short answer is to design your entire system so that any component can randomly be shot in the face, from a single server to the eastern seaboard falling into the ocean to the United States immediately going the way of Mad Max. Design failure into the system and you get to sleep at night a lot more.
Does mental health services suck pretty much everywhere? Yes. But nothing she went through was inhumane (I've been through similar scenarios in less pleasant medical facilities) and all of it is geared to try and help.
What bugged me was the intervals were off. It's hard to describe, but, for those not familiar with how the notes are laid out, 60Hz is quarter step below B, 120 is quarter step below B, 240 is quarter step below B, and so on. However, as you get higher, the frequency difference gets larger (B is actually 61.75ish Hz and B flat is 58.25ish Hz, next higher is 123.5ish Hz and 116.5ish Hz, and so on). Things were translated ~1/4 octave higher, which completely threw everything off because the 60Hz sound no longer fell evenly between two notes or even directly on a note, it was an 1/8th step away. This meant that as the notes got further away from 60Hz (higher or lower), the distance to the note got larger. So while everything was still evenly in tune, my guidepost began to really suck.
Long story short: I have no idea why it did what it did, but it was freaky. However, it was probably the most amenable side-effect I had from the medication.
I really don't understand why so much of the programming classes, tutorials, guides and common wisdom aren't 'data first' style design.