←back to thread

Ask HN: Who is hiring? (May 2018)

587 points whoishiring | 1 comments | 01 May 18 15:02 UTC | HN request time: 0s | source

Please state the job location and include the keywords REMOTE, INTERNS and/or VISA when the corresponding sort of candidate is welcome. When remote work is not an option, include ONSITE.

Please only post if you personally are part of the hiring company—no recruiting firms or job boards. Only one post per month, please. If it isn't a household name, explain what your company does.

Commenters: please don't reply to job posts to complain about something. It's off topic here.

Readers: please only email submitters if you personally are interested in the job—no recruiters or sales calls.

You can also use kristopolous' console script to search the thread: https://news.ycombinator.com/item?id=10313519.

Show context
eslaught ◴[01 May 18 21:11 UTC] No.16971694[source]▶
SLAC Computer Science Research Dept. | Software Engineer | Menlo Park, CA | Full-time, Relocation Available

As part of a collaboration between the Computer Science Research Dept. at SLAC and the LCLS-II project, we're looking for a full-time engineer to help us build a high-performance monitoring system that will be used every single day once the machine comes up. This is a mission-critical system. The monitoring system will ingest between 100s of GB/s to 1 TB/s of data and be responsible for rendering it to the user in a way that will enable the science users to drive their experiments. Performance is obviously a goal here, but so are maintainability and extensibility. Building a system with low technical debt is a must for this project.

That project will be about 50% of your time; the other 50% will be more flexible and may involve engineering work on the next-generation runtime system Legion, which is a major project within our group. (http://legion.stanford.edu/)

Everything we do is open source.

We expect the monitoring system to be built primarily in Python and C++ on Linux using some combination of UI technologies (Qt), fault-tolerant storage technologies (Redis), high-performance compute (MPI or Legion), and high-performance networking (to interface with the data acquisition system).

For more information about the department, see:

https://www6.slac.stanford.edu/news/2016-05-26-slac%E2%80%99...

For more information on LCLS-II, see:

https://portal.slac.stanford.edu/sites/lcls_public/lcls_ii/P...

We're working to put the official job ad out now. Please contact eslaught@slac.stanford.edu if you are interested (subject line "AMI Project") and I will forward the link when it is ready.

replies(2): >>16973658 #>>17022366 #
iandanforth ◴[02 May 18 02:44 UTC] No.16973658[source]▶
Would you consider Rust or Go implementations?
replies(1): >>17002468 #
1. eslaught ◴[05 May 18 16:23 UTC] No.17002468[source]▶
One constraint is that the scientists would like this system to be something they can maintain on their own, and that (for better or worse) means using languages they are comfortable with. Python is obviously popular in science, and C++ seems to be the current de facto "fast" language of choice. It's likely we'll develop two versions of the system, of which one can be more "researchy" and therefore able to take on more technical risk. However, we'll still want to be strategic about what that risk is so that if the research side of the project is successful it could in theory become the production system.