¿Cómo es trabajar para Cloudera?

¡Trabajar en Cloudera es genial!

A medida que nos convertimos en una empresa mediana, imagino que diferentes empleados aquí tienen diferentes perspectivas. Así que espero que algunos de mis colegas también compartan sus propios pensamientos. Esta es mi perspectiva como uno de los primeros miembros del equipo de ingeniería, que ahora trabaja principalmente en la programación de sistemas en el lado de código abierto (HDFS).

Cultura de la empresa

La actitud de los fundadores fue una de las cosas que me atrajo aquí, y que desde entonces ha atraído la cultura de la compañía. Los fundadores, y el equipo ejecutivo en general, tienen la capacidad única de ser accesibles a los empleados, honestos y transparentes, y aún así “negocios mezquinos” cuando lo necesitan. Tenemos una reunión quincenal de todas las manos con la oportunidad de preguntarle cualquier cosa al CEO, y él siempre hace todo lo posible para responder abierta y honestamente, sin importar la pregunta.

Si tuviera que elegir una palabra para encarnar la cultura, sería “confianza”. Esto se muestra de muchas maneras: una de nuestras ventajas únicas es un miércoles de trabajo desde casa para todos los ingenieros. Algunos de nosotros elegimos venir a la oficina de todos modos, pero no hay reuniones, y depende de usted trabajar desde donde sea más productivo, ya sea desde la cama en PJ, desde un café o desde la oficina. La gente confía en que usted hace su mierda y que sabe lo que funciona mejor para usted.

No es una cultura “a tope en el asiento”. Muchos de nosotros (incluido yo mismo) llegamos bastante tarde por la mañana y no nos quedamos hasta tarde en la oficina, sino que preferimos trabajar desde casa por la noche. Por lo general, envío mi correo electrónico desde casa por la mañana, me dirijo a la oficina alrededor de las 10:30, me quedo hasta las 7:30 o así, luego me dirijo a casa para cenar, terminando un poco más de trabajo por la noche si no tengo nada planificado. Por lo tanto, es un día completo (que, por supuesto, es más pleno durante los períodos de crisis), pero nada loco y lo suficientemente flexible como para mantenerse bajo estrés.

Otro buen ejemplo es la forma en que se confía en cada empleado que trabaja en código abierto para representar los intereses de la empresa en el público. Muchos ingenieros aquí están orientados a la comunidad, y todos confían en nosotros para mostrarle a la compañía una buena luz y obtener respeto en la comunidad. En el caso en que un empleado bastante nuevo sugirió que deberíamos hacer que la gerencia revise nuestra correspondencia sobre un tema polémico, fue rechazado rápidamente y se reconoció el error.

Tecnología

La tecnología en la que trabajamos es extremadamente difícil de diseñar. Tiene una serie de requisitos únicos en comparación con otros proyectos en los que he trabajado:

Tiene que correr a escala . Tenemos clientes que ejecutan clústeres de Hadoop que constan de miles de nodos (decenas de miles de núcleos, PB de disco). Si comete un error de eficiencia en un componente crítico, eliminará estos clústeres. Si hay una condición de carrera, la golpearás. No puedes esconderte detrás de la probabilidad a esta escala.
Tiene que seguir corriendo . Nuestros clientes ejecutan Hadoop para cargas de trabajo de producción con estrictos SLA. Las compañías más grandes del mundo manejan infraestructura de procesamiento crítica en nuestra tecnología. Si un grupo se cae, es grave.
– Almacenamos datos reales . En ciertos proyectos en los que trabajamos (por ejemplo, HDFS y HBase), somos la última línea de defensa para datos importantes. Si escribimos un error que corrompe accidentalmente los datos, es un problema grave. Por lo tanto, tenemos un requisito de revisión de código bastante fuerte, especialmente en torno a rutas de código críticas en estos componentes de almacenamiento.
Tiene que operar en la naturaleza . Los dos requisitos anteriores son comunes en cualquier gran empresa web como Facebook, Google o Twitter. Pero tienen entornos de despliegue muy bien definidos, y cuando algo comienza a salir mal, puede pasar a una caja y meterla. Cuando descubras el problema, puedes reenviarlo en menos de un día. Por el contrario, nuestro software se publica trimestralmente y esencialmente “encogido”. Para algunos clientes del gobierno, en el pasado hemos publicado código mediante la federación de CD-ROM. Si algo sale mal en uno de estos grupos, no puede ingresar. En algunos casos, ni siquiera pueden copiar y pegar registros. Este es un dolor gigante en el culo . Pero significa que, cada bit de código que escriba, debe pensar en cómo podría fallar en algún centro de datos lejano, cuán claros serán los mensajes de error y con qué facilidad podrá hacer que el cliente vuelva a funcionar y ejecutándose sin volver a implementar el código.

También admitimos muchas versiones subyacentes diferentes. Aprendí más sobre la implementación de JVM y el kernel de Linux trabajando en Cloudera de lo que originalmente hubiera imaginado. La mayoría de las nuevas versiones de RHEL generan al menos un informe de error de nuestro equipo debido a problemas de producción encontrados por nuestro QA o nuestros clientes. (Oh, ¿su demonio de autenticación no es seguro para hilos? ¿Oh, la desfragmentación transparente de página grande mata el rendimiento? ¿Olvidó poner el sync_file_range #defines en los archivos de encabezado? JDK <6u31 no analiza correctamente los cachés de tickets de Kerberos producidos por Kerberos 1.8 o posterior? )

Tiene que operar con código de confrontación en la misma máquina . Hadoop es, en esencia, un sistema para ejecutar el código de otras personas. Desafortunadamente, las otras personas no siempre son amables contigo. Escribirán bucles infinitos. Escribirán bombas tenedor. Escribirán pings de inundación. Prácticamente cualquier tipo de ataque DoS que puedas imaginar, un cliente escribirá accidentalmente y luego se desplegará en 1000 nodos a la vez. Este es un entorno muy diferente al que ve con la mayoría del desarrollo de software. No solo estás a la defensiva contra tu propio código: estás a la defensiva contra otras personas.

Además de todo lo anterior, muchas de las cosas subyacentes son simplemente difíciles . Supongo que la mayoría de los lectores han realizado programación concurrente con múltiples hilos en un solo nodo. La programación distribuida es la misma, excepto que sus relojes no están sincronizados, los nodos se bloquean y los nodos a veces piensan que otros nodos se bloquean cuando, de hecho, se han vuelto locos y están haciendo todo lo posible para romper todas sus suposiciones.

Los varios párrafos anteriores pueden sonar un poco como una queja. Trabajar en esta tecnología puede ser frustrante a veces, pero siempre es un desafío. Si solo desea codificar otra aplicación social en una plataforma bien definida, en un entorno en el que pueda ver todos sus registros e impulsar una nueva versión en 5 minutos cuando la arruine, no trabaje para nosotros. Si desea ser desafiado a escribir el código más robusto que pueda, que funcione en escenarios muy difíciles, puede que le guste aquí.

Personas
Si eres como la mayoría de los estadounidenses, pasas la mayor parte de tus horas de vigilia en el trabajo y, por lo tanto, pasas más tiempo con tus compañeros de equipo que incluso tus amigos y familiares más cercanos. Entonces, será mejor que te gusten. Por suerte lo hago.

Las personas aquí son genuinamente amigables, sociales, curiosas y siempre están aprendiendo. Tenemos una hora feliz bastante regular, juegos de video programados regularmente (nuestro CTO participa), y muchos de nosotros pasamos el rato juntos fuera del trabajo (juegos de béisbol, comer fuera, caminar, esquiar, acampar, etc.). He invitado a muchos de mis amigos no tecnológicos a unirse a mí en eventos mayormente de Clouderan y he recibido comentarios de varias personas: “ya sabes, ¡para ingenieros, de alguna manera logras contratar personas realmente NORMALES!” Claro, saldremos de vez en cuando y tendremos argumentos apasionados sobre el bloqueo frente a la E / S sin bloqueo. Pero también actuaremos como seres humanos normales de manera bastante regular.

Ventajas
Ofrecemos una muy buena variedad de ventajas:
– Oficina de San Francisco (además de Palo Alto: usted trabaja desde lo que sea más conveniente para usted)
– Almuerzo gratis todos los días (a veces atendido, a veces orden de un restaurante)
– Aperitivos, café, etc. (¿pero quién no, en estos días?)
– monitor de 30 ”
– salario competitivo, beneficios y equidad

Por supuesto, la respuesta estaría incompleta sin un poco de la típica postura de inicio: estamos años por delante de la competencia en lo que probablemente sea el área de software empresarial de más rápido crecimiento. Estamos creciendo a un ritmo asombroso, tanto nuestros empleados cuentan como nuestros ingresos anuales. Se siente un poco como un cohete, y no es demasiado tarde para subir. ¡Envíame un mensaje si estás interesado!

Oh Dios mío, no puedo dejar pasar esta oportunidad de pontificar. Además, es algo que hacer mientras el 95% del equipo de ingeniería está en un estreno gratuito de la nueva película de Batman. Mi perspectiva va a tener algo en común con la de Todd: nos unimos a Cloudera muy cerca el uno del otro, cuando la empresa era legítimamente una nueva empresa. Fue una maravilla entonces, dejé la escuela de posgrado para correr este riesgo, y no me he arrepentido desde entonces, y es una maravilla ahora.

Optimizo aproximadamente tres cosas: trabajar con personas que te gustan, trabajar en problemas que son interesantes y relevantes, y trabajar en las condiciones que disfrutas. (Aunque si estás leyendo, Rob, también optimizo para paquetes de compensación gigantescos). Cloudera cumple los requisitos para mí, aquí hay algunas de las razones por las cuales.

Cliente primero, luego tecnología

Es emocionante trabajar en Cloudera porque, creo, tomamos el impacto en el mundo real de la tecnología que estamos construyendo más en serio que el promedio. Lo que quiero decir con esto es que nosotros, junto con muchas otras compañías, estamos participando en una revolución técnica basada en un cambio de perspectiva sobre cómo se deben construir los sistemas de datos a gran escala. Yo (con soltura) llamo a esto “la segunda buena idea en sistemas de datos”; el primero es bases de datos relacionales.

Sin embargo, estar a la vanguardia significa que tiene la obligación de hacer que las nuevas ideas sean accesibles para todos los demás.

Lo que creo que hemos entendido, para nuestra ventaja, desde los primeros días es que la construcción de la tecnología es solo una pequeña parte (¡si es vital!) Del problema, y ​​nos hemos centrado en comprender cómo los clientes quieren usar esta tecnología y cómo podemos explicar a los clientes en qué podemos ayudarlos. Esta filosofía informa cada decisión que se toma sobre los productos y servicios de Cloudera: ¿cómo podemos hacer que esto sea más útil para el cliente y cómo podemos ayudarlo a comprender mejor el poder de estos nuevos sistemas?

Eso condujo, muy pronto, al establecimiento de nuestra división de soporte y servicios, así como a nuestro equipo de capacitación. Creo que nuestro equipo de ingeniería aquí en Cloudera es sobresaliente y con razón recibe mucha atención, pero nuestras organizaciones de capacitación y soporte también son de primera clase. Esto se debe a que invertimos desde el principio en la contratación de personas que pudieran ayudar a educar a los clientes y que pudieran interpretar y priorizar las necesidades de esos clientes. Como compañía, estamos escribiendo libros, estamos capacitando a personas en todo el mundo y estamos hablando en todo tipo de conferencias diferentes. Es genial ser parte de ese proceso de educación mutua, y está estrechamente entretejido en lo que nos preocupa todos los días.

La ingeniería ahora es aproximadamente un tercio de lo que hacemos como empresa. El resultado es una dedicación casi fanática a las necesidades del cliente y eso ayuda a que el trabajo que hago (que hoy en día a menudo tiene más investigación, el próximo lanzamiento pero una sensación) se sienta más arraigado, y como si estuviera construyendo sistemas que las personas querer y usaré.

Si usted es un ingeniero directo como yo, podría concluir que esto es al revés, y que me gustaría trabajar en algún lugar donde primero desarrollemos tecnología sofisticada, y luego intente resolver los problemas que resuelve. Veo la atracción de preocuparme solo por la tecnología, pero eso me parece miope y es probable que finalmente sea insatisfactorio. Hay una sensación real en Cloudera de que estamos en las primeras etapas de la construcción de algo significativo y duradero. Además, los problemas en este espacio que los clientes quieren que resuelva son bastante desafiantes: tengo la suerte de tener lo mejor de ambos mundos.

Seleccione por personalidad y habilidades

Cuando entrevistamos a personas, aplicamos lo que (desde el principio) llamamos una ‘política de no imbéciles’. Es extremadamente importante que le gusten las personas con las que trabaja, como dice Todd. Rechazamos a algunas personas brillantes porque nos preocupaba que sería difícil trabajar con ellas. Continuaremos haciendolo así. Como resultado, constantemente me sorprende lo mucho que me gustan tanto las personas con las que trabajo como todas las personas que conozco socialmente que trabajan para la empresa. Largo que eso continúe.

(Sin embargo, déjenme ser claro: no estamos contratando personas que no sean ingenieros realmente emocionantes, ya sean nuevos graduados talentosos o veteranos de 30 años. Una consecuencia de la política de “no imbéciles” es que cuando estas personas se unen , quieren compartir su conocimiento y experiencia. Efecto neto: aprendo muchísimo y también enseño mucho).

Pero la tecnología es muy, muy interesante.

Todd hizo un buen trabajo al explicar por qué los desafíos técnicos son dignos. Creo que una vez que el polvo se haya asentado, miraremos hacia atrás y veremos que estábamos trabajando en una de las tecnologías de software más emocionantes, disruptivas y potentes de la época. Y me encanta, porque soy un tipo teórico de sistemas distribuidos por educación y un tipo práctico de sistemas distribuidos por capacitación. Puedo ver muy claramente que las ideas sobre las que leo en los documentos son prácticamente relevantes para los sistemas que estoy construyendo, y tengo la oportunidad de aplicar esas ideas todos los días (y proponer algunas propias).

Eventualmente, estas ideas se comercializarán, quedarán consagradas en un software estandarizado y la sensación de descubrimiento y exploración pasará. La ventana está abierta ahora, y lo estará por algunos años. Hay una gran oportunidad para hacer una gran contribución. Por lo que veo hasta ahora, esas oportunidades son poco frecuentes en la carrera de uno.

Sí, es un excelente lugar para trabajar.

No necesito agregar mucho a lo que dijo Todd, pero enfatizaré que la confianza y la transparencia que se muestra a los empleados individuales es una parte fundamental para hacer de Cloudera un lugar agradable para trabajar. Me queda organizar mi propio tiempo, progresar en las cosas que tengo que hacer y pedir ayuda a cualquier persona de la empresa cuando la necesite. Eso es muy refrescante.