I applied through a recruiter. The process took 3 weeks. I interviewed at Orbital Insight
Interview
I was pulled in by an outside recruiter so first I talked with that person, then I had an introductory call with the head of platform engineering. I then did a 1 hour code screen in Coderpad with a senior engineer. I was quickly invited for a virtual "onsite" where I had 2 more coding interviews and some cross-functional/HR interviews plus the VP of Engineering.
Overall a very positive experience - good talks with everyone, and challenging yet fair coding questions. I particularly enjoyed interviewing with the VP of Engineering who sold me on the company and answered my numerous followup questions afterwards.
Interview questions [1]
Question 1
One of the questions: Given a probability distribution for a set of characters, generate a random stream of characters that adheres to the distribution.
I applied online. I interviewed at Orbital Insight
Interview
The phone screen was a breeze. Standard algorithms and helpful interviewers. The onsite questions were all leetcode hard and very different than the questions one generally encounters during programming interviews. Overall, everything else was fine, nice people and nice facilities.
I applied through a recruiter. The process took 1 week. I interviewed at Orbital Insight (Washington, DC) in Jan 2018
Interview
Initial screening interview by the recruiter. Then a phone interview with the Software Engineering Lead. Interview was mostly about background in programming etc. They assigned a homework problem to test the programming abilities. See details below.]
Caution - these guys decided to move on with other candidates; however, they did not give me the courtesy of feedback.
Interview questions [1]
Question 1
There was a programming (homework) question.
Orbital Insight Interview Problem
Please write a program in Python that reads a text file and outputs the k most
common tokens (contiguous sequences of characters that are neither
whitespace nor “.” [period] nor “,” [comma] nor “-” [hyphen]) in the input.
The consideration of token equality should be case-insensitive; that is, foo FOO
and fOo are all considered the same token. Furthermore, this text has been
machine scanned, so there are a few other common pairs of characters that
can get confused in the scanning process: 0 and O (that’s zero and capital oh),
b and 6, B and 8, and 1, I, and l (that’s numeral 1, capital i, and lowercase L).
You should consider tokens that are equal except for case and these
equivalences to be the same for counting purposes, but you must track all of
the exact variants that are seen.
The value of k (the number of most common tokens you should output) should
be taken as a command-line argument. If it is missing, a default of 10 should
be used. Feel free to read the text from stdin, or to take a filename as a
command-line argument and read the text from that file, or both.
The output should be the various token variations seen (separated by the “|”
[pipe] character) and the count of each token, in descending order of number of
occurrences, with the variations and the count separated by a “@” character.