🕝 🕚 🍒 Oferta en Londres en un día: cómo obtenerla y qué hacer después de mudarse 👵🏾 🤯 🥪

Hola Habr!

Tenemos grandes planes para 2020. Tenemos la intención de desarrollar activamente Badoo y Bumble, por lo que estamos ampliando seriamente el equipo técnico. Y hoy anunciamos la contratación masiva de desarrolladores de PHP en nuestra oficina de Londres.

En 2017, probamos un nuevo formato de búsqueda: evento de contratación: traemos desarrolladores geniales a Moscú, realizamos entrevistas en un día e inmediatamente hacemos una oferta a los candidatos adecuados. Todos los gastos para un viaje a la capital, por supuesto, son incurridos.

El formato ha funcionado bien y tenemos muchos puestos vacantes nuevamente, por lo que estamos anunciando un nuevo evento de contratación de PHP.

Las reglas son las mismas: muestre un alto resultado de la prueba antes del 1 de marzo, pase con éxito la entrevista el 21 o 22 de marzo en Moscú, y el mismo día reciba una oferta en la oficina de Badoo London.

UPD: la prueba se ha completado, ¡gracias a todos los participantes! Ya hemos notificado a los finalistas y advertimos que las fechas de la entrevista se posponen indefinidamente para la comodidad y seguridad de los candidatos.

Debajo del corte te diré:

más sobre la prueba;
en qué proyectos estamos involucrados: optimización de fotos, transmisión de video, aprendizaje automático para cartas, transición a nuevas versiones de PHP y mucho más.

Si eres un shnik PHP y quieres mudarte a Londres, ¡bienvenido a kat!

Cómo pasar el examen

La prueba consta de cinco tareas. Se asignan exactamente 90 minutos a la decisión: no funcionará retrasar o pausar el proceso. Antes de comenzar, asegúrese de tener suficiente tiempo.

En tres tareas, debe escribir consultas de código / SQL, y en las dos restantes esperamos ver respuestas detalladas a las preguntas. Prueba publicada en HackerRank. Recomendamos practicar las tareas de prueba de la plataforma para sentirse cómodo con la interfaz.

Las decisiones se toman hasta 2020-03-01 23:59:59 UTC. Según los resultados de la prueba, seleccionaremos aproximadamente 60 candidatos a quienes invitaremos a Moscú para una entrevista.

La compañía cubre todos los gastos de un viaje a Moscú, así como los gastos relacionados con la mudanza a Londres. Ayudamos a obtener visas de trabajo para los miembros de la familia de nuestro nuevo colega, pagar el vuelo, alquilar una casa durante la búsqueda, pagar una bonificación en efectivo por la mudanza y ayudar a mejorar el inglés. Ya puede familiarizarse con el equipo en la etapa de entrevista: los propios desarrolladores realizan entrevistas en el evento de contratación.

Lo que hace el equipo de desarrollo del servidor

Somos responsables del backend de los servicios de citas Badoo and Bumble. Además de deslizar hacia la izquierda y hacia la derecha para encontrar un socio, las aplicaciones tienen transmisión de video, chat con mensajes de audio, búsqueda de personas cercanas, integración con servicios de pago y mucho más. Una interfaz relativamente simple esconde mucha lógica en PHP y Go (y se vuelve más y más).

Nuestro equipo tiene más de 40 personas. El trabajo se puede dividir en dos grandes partes:

nueva funcionalidad en aplicaciones,
proyectos técnicos: mejora de herramientas, optimización, trabajo con deuda técnica.

Hablaré sobre los proyectos más interesantes que hemos implementado en los últimos dos años.

Cool chips en el producto

El mercado de aplicaciones de citas es dinámico y competitivo, por lo tanto, nuestro objetivo principal es el desarrollo del producto: debe seguir siendo interesante y seguro para los usuarios.

Aprendí a ocultar también fotos "personales"

Algunos usuarios envían fotos de chat de naturaleza erótica, incluso si el interlocutor no solicitó tales regalos.

La tarea que teníamos que resolver era enseñar a la aplicación a distinguir las fotos "privadas" (18+) de las comunes y mostrarlas chateadas en el chat, permitiendo al destinatario decidir por sí mismo si quiere verlas en su totalidad.

Junto con el equipo de I + D, creamos un servicio en Go con una red neuronal que puede reconocer fotos "privadas". Si la probabilidad de que la foto sea erótica es superior al umbral establecido, se coloca una bandera especial en el mensaje y el cliente maneja esta situación en consecuencia: muestra un trozo borroso que pregunta si el destinatario quiere ver qué hay dentro.

Realizamos todas las tareas a través de pruebas A / B y también cubrimos cuidadosamente los puntos clave de la nueva funcionalidad con estadísticas. Entonces, descubrimos que se envían alrededor de 200,000 por día de fotos "privadas". Y también, que a menudo estas fotos todavía se ven y no se quejan del remitente.

Se agregaron mensajes de chat de audio y video

En los últimos dos años, hemos elaborado funciones para mensajeros avanzados y les hemos dado a los usuarios la oportunidad de intercambiar mensajes multimedia. La implementación de esta opción en el lado del servidor fue bastante simple debido a la arquitectura flexible de la API móvil y su propia CDN.

Al diseñar mensajes multimedia en el chat, transferimos la carga del archivo desde la API principal cliente-servidor a los servicios HTTP separados ubicados dentro de la CDN. Utilizamos un único repositorio, por lo que desde el punto de vista del soporte de código, esta solución no causó ningún problema. Pero permitió utilizar herramientas optimizadas para la naturaleza de la carga:

la API móvil (protocolo binario) se agudiza mediante el intercambio de comandos cortos y en el pico pasa por sí misma más de 100,000 solicitudes por segundo;
CDN está optimizado para trabajar con multimedia y es capaz de entregar 200,000 fotos por segundo ( hablamos de las optimizaciones de CDN en detalle en la conferencia del día de actividad).

Desde el punto de vista de CDN, el tipo de archivo descargado no importa mucho, y ya teníamos conversión de video. Solo pudimos procesar correctamente los nuevos tipos (audio y video) en el protocolo de la API móvil.

Aprendí a construir modelos ML sin I + D

En 2018, creamos nuestro propio marco para automatizar la capacitación de modelos en nuestros datos. Ahora, cualquier desarrollador de backend puede crear de forma independiente un modelo adaptado para su aplicación, sin atraer colegas de I + D.

Este marco es capaz de recopilar cientos de métricas, tanto universales (género, edad, actividad en la aplicación) como específicas, significativas para cada modelo específico. Los algoritmos para construir modelos ML están configurados de manera flexible, y los gráficos de los resultados están disponibles para análisis "listos para usar". En la salida, el marco proporciona un modelo de trabajo que responde lo suficientemente rápido (dentro de 10-100 ms) para que se pueda llamar desde PHP directamente en las solicitudes del usuario sin sacrificar la experiencia de usuario.

El año pasado, integramos el marco en varias partes de nuestra aplicación: sistemas antispam, calificación de la aplicación y algunos otros. Mail ML es una de las aplicaciones más exitosas: el modelo predice la probabilidad de un clic en el enlace del correo electrónico para un usuario específico. El modelo aprende de los datos de otros usuarios, de forma similar al destinatario del correo electrónico con atributos "importantes", y el marco calcula automáticamente la "importancia".

Después de evaluar los resultados, dejamos de enviar correos electrónicos con la menor posibilidad de hacer clic en los enlaces. Debido a esto nosotros:

mayor lealtad de los usuarios, lo que resultó en mejores métricas de actividad en el servicio: a la gente no le gustan las cartas "sin esperanza";
Aumento de la tasa de buzón de entrada en los anuncios de correo clave: servicios de correo electrónico como remitentes con un CTR alto.

Lanzamiento de video streaming

Siempre estamos buscando nuevas oportunidades de desarrollo. Cuando la transmisión de video comenzó a ganar impulso, decidimos integrarlo en nuestra aplicación. Predecir el éxito del proyecto no fue fácil, por lo tanto, para reducir los costos, no nos lanzamos de lleno al desarrollo de nuestra solución, sino que encontramos una empresa que proporcionara la plataforma y el SDK con la funcionalidad que necesitábamos.

Se nos exigió construir lógica de características, interacción cliente-servidor, implementar opciones para enviar y pagar regalos, proporcionar moderación rápida de contenido (tanto la transmisión de video como los comentarios) y cubrir todo con métricas. Hemos reunido un equipo multifuncional de diferentes departamentos y divisiones: desarrollo de clientes, desarrollo de servidores, facturación, plataforma, back office, análisis de BI, diseño y gestión de productos. Todos se establecieron en un espacio de oficina, y el trabajo comenzó a hervir.

Determinamos la funcionalidad de la primera versión (MVP), y un mes después lanzamos una característica en un país tras otro. Durante varias semanas lo implementamos en diferentes países, y hoy la transmisión de video está disponible en todas partes.

Difundir mensajes de usuario en el Arbat

Fue una promoción muy inusual: todo el mes de octubre, los usuarios de Badoo enviaron mensajes a una gran cartelera de video ubicada en Novy Arbat en Moscú. En un mes, nos enviaron 23,000 mensajes, de los cuales 12,000 fueron moderados con éxito y llegaron a la pantalla.

Una cartelera es un televisor tan inteligente con un navegador y nuestro cliente JavaScript en su interior. Se mostraron comerciales de cinco minutos en la pantalla, en cada uno de los cuales se nos dieron tres minutos.

Por supuesto, todos los usuarios querían ver el mensaje enviado en la pantalla con sus propios ojos. Para hacer esto posible, tuvimos que responder la pregunta cuando cada uno de los mensajes aparece allí.

Deberíamos informar al usuario sobre el momento de mostrar después de la moderación. Técnicamente, en este punto, el mensaje cayó en nuestro horario interno con un tiempo de inicio claro para el programa y una duración que se calculó dinámicamente: de 30 segundos a cinco minutos (dependiendo del número de remitentes).

La dificultad era que el proveedor, por su parte, no proporcionaba la capacidad de controlar y rastrear el tiempo del comercial, por lo que era necesario sincronizar astutamente nuestro horario con el horario del proveedor, monitorear y ajustar constantemente si fuera necesario. Nos ayudó que nos dimos cuenta (¡el registro es nuestro todo!) Que unas pocas decenas de segundos antes de que se mostrara el siguiente video, el televisor inteligente vuelve a cargar la página. Era imposible concentrarse en este momento, pero en él se notaban cambios en el horario, que a veces llegaban a 15-30 segundos. Configuramos el monitoreo de turnos de nuestro lado y en los momentos de operación comenzamos a solicitar la hora del programa más cercano al proveedor.

En el proceso de configuración de este sistema, nuestro ingeniero, que trabajaba en un café frente a la cartelera, comió una cantidad impresionante de cruasanes y bebió muchas tazas de café, pero gracias a él la transmisión de mensajes de los usuarios se realizó sin problemas y no hubo incidentes graves.

Proyectos técnicos

A pesar del gran volumen de trabajo de comestibles, dedicamos mucho tiempo a proyectos técnicos. La mayoría de ellos se relacionan con el rendimiento de nuestras aplicaciones, así como con el desarrollo y la mejora de herramientas internas.

Proyecto Liveprof Open Source

Durante mucho tiempo hemos tenido la oportunidad de habilitar XHProf en producción para una solicitud específica, pero esto no siempre es suficiente. Las solicitudes son diferentes, pero para un trabajo sistemático sobre el rendimiento, quiero ver el panorama general de todas las solicitudes. Por lo tanto, nació una idea así: inicie XHProf automáticamente en una pequeña parte de las consultas y agregue los resultados. Así es como apareció el proyecto Liveprof , que pusimos en acceso abierto.

En el proceso de procesamiento de la solicitud, existe una lógica que, en función de las probabilidades y el método API, decide si iniciar XHProf. Los resultados de la creación de perfiles se escriben en el disco y luego se envían a un servidor separado, donde se colocan en forma bruta en MySQL.

Una vez al día, se ejecuta un script que agrega los resultados para cada marca, plataforma y método API. Por lo tanto, podemos ver los resultados de la creación de perfiles para solicitudes específicas de Badoo iOS (tanto en forma de árbol como en forma de gráfico de llama), podemos ver qué porcentaje del clúster se necesita para llamar a una función individual (por ejemplo, cuánto cuesta recopilar una URL para una foto), y recientemente agregué el resultado de esta información directamente a PhpStorm.

Migrar a PHP 7.4

Las nuevas versiones de PHP están satisfechas con la mejora del rendimiento. Durante las últimas dos transiciones (de 7.0 a 7.2 y de 7.2 a 7.4), nuestro departamento fue responsable.

La transición comienza mucho antes del lanzamiento oficial. Primero, ejecutamos manualmente las pruebas con la nueva versión y ... enfrentamos una gran cantidad de problemas. Algunos de ellos se resuelven fácilmente, mientras que otros requieren algo de tiempo.

Cuando la mayoría de los problemas se han resuelto, cambiamos a la nueva versión en el entorno del desarrollador, durante algún tiempo supervisamos los registros de errores y recopilamos comentarios de los desarrolladores y los ingenieros de control de calidad. En el momento del lanzamiento oficial de la versión estable, estamos listos para probar la producción: primero la ejecutamos en una máquina y la distribuimos gradualmente en las demás.

Pero después de que la nueva versión se distribuye en todos los servidores, la transición no termina: continuamos verificando la sintaxis con ambas versiones de PHP (nueva y anterior). Por lo tanto, estamos convencidos de que los desarrolladores no comenzaron a usar la nueva sintaxis y que podemos cambiar a la versión anterior en cualquier momento si surgen problemas inesperados en la nueva. Por ejemplo, antes de las vacaciones de Año Nuevo, descubrimos un pequeño problema con una pérdida de memoria en PHP 7.4, decidimos no arriesgarnos y volvimos a la versión anterior antes de las vacaciones. Después de las vacaciones, después de haber solucionado el problema, volvimos a lanzar la versión 7.4 y aún la usamos.

Ir a la agregación de solicitudes

Con la actualización de PHP, nuestra lucha por el rendimiento no termina ahí. Tenemos un marco poderoso que hace mucho trabajo al principio: desde la inicialización hasta varias verificaciones requeridas para cada solicitud.

Decidimos realizar un experimento simple. Seleccionamos una parte de los comandos para los cuales la respuesta del servidor no es crítica (por ejemplo, enviar estadísticas del cliente o elegir la opción "No" en el juego de deslizamiento), y escribimos un servicio en Go que acepta dichas solicitudes, las guarda y luego las envía en un paquete al servidor ( para cada usuario). Por lo tanto, podemos ahorrar fácilmente al inicializar la aplicación sin tener que volver a escribir el código principal.

El experimento resultó exitoso: de acuerdo con nuestras estimaciones, podemos ahorrar un pequeño porcentaje de la CPU (que en nuestro caso es más de diez servidores) sin reescribir el código principal, pero a costa de complicar la operación y la lógica del trabajo. Para completar la imagen, decidimos esperar los resultados de los experimentos con precarga PHP 7.4 y RoadRunner para elegir la solución óptima de acuerdo con la proporción de ganancias y la complejidad de la implementación.

Foto optimizacion

La actividad del usuario depende directamente de algunos proyectos técnicos. Por ejemplo, cuanto más rápido mostramos las fotos, más activamente se desliza la gente, más coincidencias, más parejas nuevas se forman, etc.

En octubre de 2018, una de nuestras marcas, Bumble, decidió ingresar al mercado indio. Como no sabíamos nada sobre la velocidad de Internet local, decidimos realizar una serie de experimentos con la calidad y el tamaño de las fotografías.

Lanzamos todos los experimentos técnicos bajo pruebas A / B. Esto le permite ver no solo la diferencia en el comportamiento y la actividad de los diferentes grupos, sino también las estadísticas sobre el funcionamiento de la aplicación en el cliente, desglosadas por opciones. Estábamos interesados en tiempo para descargar imágenes y tiempo para decodificar y mostrar.

Infraestructura, además de los servidores de almacenamiento, asignamos un grupo de cachés de fotos: estos son los servidores que almacenan las imágenes más utilizadas. Dado que hay una gran cantidad de teléfonos inteligentes con diferentes pantallas en el mundo, almacenamos fotos en varios tamaños básicos y las convertimos sobre la marcha al tamaño y formato solicitado por el cliente.

La tarea que queríamos resolver era elegir el formato óptimo (JPEG, WebP, PJPEG), el tamaño y la calidad de la imagen. En teoría, el formato WebP debería ser el mejor, pero es el más costoso en términos de conversión sobre la marcha: en lugar de ahorrar tráfico, debe comprar más servidores de caché de fotos. Junto con esto, decidimos probar cómo los CDN en la región ayudarán a mejorar UX.

Varios de nuestros ingenieros fueron enviados allí para lanzar un proyecto en India. Por lo tanto, no solo teníamos números secos, sino también personas que podían probar la aplicación en diferentes operadores en el acto, comparar su trabajo con el trabajo de otras aplicaciones, etc.

Los resultados de los experimentos nos permitieron elegir las mejores opciones para la calidad y el tamaño de las fotografías. Por ejemplo, vimos que la lógica de precargar fotos en el cliente juega un papel importante en la actividad del usuario. Y a pesar del hecho de que las fotos en WebP se descargan más rápido, el efecto positivo solo se notó en los navegadores móviles. La misma historia con CDN: probamos tres servicios externos de CDN y, a pesar de la aceleración de la entrega de contenido, no vimos ningún cambio positivo en la actividad. Como resultado, activamos WebP para navegadores móviles y ahorramos energía, dejando a todos los demás clientes en formato JPEG.

Streaming de video propio

Como mencioné anteriormente, la primera versión de transmisión de video se lanzó mediante un servicio externo. El experimento se consideró exitoso, y comenzamos a preparar software e infraestructura para el lanzamiento en nuestros centros de datos.

Con la ayuda del transcodificador listo para usar (para exprimir la transmisión de video del usuario) y los servidores Edge (para distribuir la transmisión al usuario) tuvimos que construir un sistema similar a una solución externa en caja. Y, por supuesto, mucho debía finalizarse con un "archivo" sobre la marcha.

Por ejemplo, inicialmente cada servidor Edge se conectaba a cada servidor transcodificador, lo que complicaba el escalado y aumentaba el tráfico interno. Escribimos el equilibrio de clientes de tal manera que los clientes de una transmisión van al menor número de servidores Edge, teniendo en cuenta la popularidad de cada transmisión en particular.

Otro ejemplo, cuando teníamos que ser rápidos, es la lógica de cambiar la calidad de una transmisión en WebRTC: debido al uso de dos opciones de calidad, el algoritmo estándar fue demolido y funcionó solo para disminuir la tasa de bits. Tuve que profundizar y editar el algoritmo utilizado dentro de la biblioteca WebRTC.

Además, la señalización de WebRTC, de forma predeterminada, pasa demasiada información sobre los hosts en la red al cliente. La solución fue un servidor proxy en Go, que le da al cliente solo lo que necesita saber, y además recopila mucha información útil sobre los clientes conectados.

Desde el inicio de la investigación hasta la implementación completa, el proyecto tomó más de seis meses, pero como resultado, pudimos reducir significativamente los costos al abandonar los servicios externos.

Optimización del rendimiento

Este no es un proyecto único para nuestro equipo, es un área importante a la que también prestamos mucha atención. Nuestro principal clúster que atiende solicitudes de aplicaciones consta de cientos de servidores y, por lo tanto, es rentable para nosotros invertir tiempo en el trabajo para optimizar la aplicación: cada porcentaje ganado nos cuesta varios servidores físicos.

Supervisamos constantemente la carga total en nuestro clúster y la carga para cada llamada API específica. Si se supera un cierto umbral, comenzamos a buscar y optimizar cuellos de botella. Cuanto mayor es el exceso, más personas se involucran. Este enfoque está totalmente justificado: en los últimos dos años, la tasa de crecimiento del clúster ha sido la mitad de la tasa de crecimiento de la audiencia de nuestros servicios.

Compartimos activamente el conocimiento adquirido durante el trabajo de optimización en conferencias y reuniones. Se pueden encontrar más detalles sobre nuestros proyectos y estudios en los artículos e informes de Pasha Murzakov:

Control sobre código antiguo y no utilizado

Tenemos un desarrollo bastante intenso, y el ritmo de lanzamiento de tareas y experimentos de productos también está creciendo a medida que crece la empresa. Bajo tales condiciones, la base del código se vuelve más compleja y menos controlada. La situación se ve exacerbada por varias plataformas y usuarios con versiones anteriores de aplicaciones y sistemas operativos.

Intentamos mantener nuestra base de código "limpia" para mantener un alto ritmo de trabajo:

crear automáticamente tareas para eliminar el código después de completar el experimento del producto;
seguimiento automatizado de versiones antiguas de aplicaciones y sistemas operativos y las ramas de código utilizadas en ellas;
Herramientas introducidas para buscar automáticamente el código no utilizado.

Puede obtener más información sobre nuestros resultados en Badoo PHP Meetup , que se realizará este sábado 15 de febrero.

Por supuesto, estos no son todos los proyectos de los que quiero hablar. En los últimos dos años, hemos luchado con spammers y pargos, hemos visto nuestro plugin para PhpStorm, probamos varios repositorios KV (y elegimos Aerospike), experimentamos mucho, compartimos conocimientos en artículos, conferencias y no solo.

Pero si decide que solo estamos trabajando, entonces esto no es así. Cada equipo tiene su propio presupuesto de trabajo en equipo. Nuestros colegas visitaron Amsterdam, Edimburgo, Praga y otras ciudades. Y el año pasado organizamos una reunión general del departamento en Croacia:

y también sabemos cómo hacer photoshop.

Al mudarnos a Londres y a la oficina en Soho ya dijimos, por lo tanto, no nos detendremos en los detalles de este artículo, solo mostraremos un par de fotos.

Foto grande

El evento de contratación es la forma más fácil y rápida de unirse a nuestro equipo. Aceptamos respuestas a la prueba hasta el 1 de marzo inclusive. Luego, nos tomaremos una semana para analizar los resultados y llamar a quienes hicieron frente a las tareas.

Si desea ponerse a trabajar para nosotros en Londres, pero no quiere tomar el examen, hay otra opción: simplemente responder a las vacantes en nuestro sitio web , esta oportunidad siempre está disponible.

Si tiene alguna pregunta, no dude en hacerla en los comentarios o enviarme mensajes privados.

Buena suerte

Oferta en Londres en un día: cómo obtenerla y qué hacer después de mudarse