[45k-50k] [Madrid / Remote] Startup busca Backend Developers

Stricken

#59 Ahora mismo en Personio se utilizan tres lenguajes en el backend: PHP (para el CRM), Kotlin (para algunos microservicios), Ruby (para Payroll).

Pese a que Ruby tiene sus cositas, aún no nos hemos encontrado con nada que no hayamos podido hacer y dudo que eso pudiera ocurrir. Se está hablando de dejar solo Kotlin como lenguaje en el backend en toda la empresa, aunque dudo que eso llegue a pasar.

Si me preguntas a mi, lo que me imagino que podría llegar a pasar es que si alguna vez rompemos el monolito (que de momento no va a ocurrir) seguramente tiraríamos por Kotlin, pero rehacer, lo dudo mucho.

B

.

1 respuesta
Puni

#62 Hablo sin saber, yo trabajo en sistemas. Pero en lo mío gente con 2 años de experiencia cobrando mucho más de 35k tampoco la hay a patadas. Si son 2 años de experiencia en cosas un poco más oscuras o poco comunes puede ser. Yo he estado haciendo entrevistas recientemente y con 5 años de experiencia la mitad de llamadas acaban cuando les dices que por menos de 40 no les envías ni el cv.

wdaoajw

Y devops no buscáis? :D

laZAr0
#46Stricken:

No hemos roto aún el monolito porque no terminamos de ver las ventajas.

Parece un diario de los que encuentra Isaac en el Dead Space sobre el descubrimiento de la Efigie antes de la catástrofe.

ReEpER

#42 nosotros estamos igual y encima se nos piran dos en sept. Uno arquitecto y el otro un senior. Solo le han ofrecido 50% mas de salario xd

Nanna

#44 Prueba a trabajar en cualquier otra cosa por la cuarta parte y me cuentas xd

bLaKnI

#37 Cuenta mas. ¿Que eres capaz de hacer desde 0? CI/CD from scratch? Montado todo en un entorno AWS con todas sus posibilidades (lambdas, elastic containers, etc...?)
¿Y porque usar Jenkins en AWS?

2 respuestas
Mortium

#44 Esos problemas de ojos me suenan... =(

wdaoajw

#68 Jenkins y cloud se usa mucho cuando tienes entornos híbridos onpremise/cloud y de esta forma controlas toda la infraestructura de CI/CD

Así lo tengo yo montado, mientras que tenemos parte en cloud, con lambdas para alguna cosa, la mayoría de ec2 las integramos en nuestro entorno CI que tenemos en una serie de servidores onpremise

1 respuesta
bLaKnI

#70 Porque onpremise tienes una infra Jenkins montada, y en este, puedes configurar las instancias de EC2 de AWS como si estuvieran en el própio perímetro? Entonces el deployment en producción es en los EC2?

1 respuesta
C

#68 uso jenkins desplegado en Kubernetes con escalvos dinámicos levantados como pods de Kubernetes. Los pods del master tienen el
directorio /var/jenkins_home montado para no perder la persistencia.

Para pipelines de Ci/CD su, tanto AWS como Azure tienen sus propias herramientas pero hijo, qué quieres que te diga.... Jenkins >>> all

En cuanto a la infraestuctura, procuramos usar PaaS todo lo que sea posible y definirla mediante código que desplegamos con roles de ansible, así como el propio software.

Lecherito

Jenkins es la mayor basura que se ha creado en mucho tiempo teniendo CodePipelines a mano no se para que quieres esa mierda xD

2 respuestas
C

#73 si te quieres quedar atado a AWS y gitHub si, con codePipelines te basta.

Al final se trata de usar lo que mas sentido tenga y más convenga a tus necesidades y entorno. Yo, en mi empresa, por la variedad de nuestra infraestuctura y versatilidad que te da Jenkins no nos planteamos ni por asomo usar otra cosa. Y nos va de puto lujo con él.

1 1 respuesta
bLaKnI

#74 Pero el jenkins lo despliegas fisicamente en 1 solo server, no? Y lo administras y automatizas para todo el ciclo CI/CD (no he usado jamás Jenkins)?

#73 CodePipeline de AWS dices?

1 respuesta
C

#75 Si. Bueno, lo despliego como servicio en Kubernetes pero si, puedes desplegarlo en un solo server y definir luego esclavos. Lo que pasa es que en mi caso los esclavos son pods de Kubernetes que se levantan, hacen el trabajo que tengan que hacer, y se tiran. No tenemos servidores esclavos levantados de forma permanente. Es una solución muy limpia y elegante.

Luego puedes definirle los pipelines que necesites de CI/CD. Yo lo tengo configurado para que cuando alguien hace push a un repo Gitlab le lance automáticamente la construcción y el análisis de código, el cual visualizamos en un sonar también desplegado en Kubernetes. Si todo va bien, Jenkins despliega la aplicación de forma automática en los entornos que definamos.

En otros casos llegamos solo al CI y el deployment lo hacemos mediante Jenkins también, pero bajo demanda o programado ciertos días a la semana, lo que necesite el proyecto, vamos.

La creación de la infrastuctura en la nube la tenemos definida como codigo mediante ansible y se lanza mediante Jenkins también.

1 respuesta
bLaKnI

#76 Pero para infra en nube dinámica por codigo, usáis AWS CloudFormation?

Y entonces en vez de un server para Jenkins, tenéis un server con Kubernetes montado, y este gestiona la lógica de levantar o matar esclavos, a conveniencia de las configuraciones y procesos establecidos en el propio kubernetes para vuestra lógica de CI/CD, ¿no?
Entonces el modulo de Jenkins se levanta solamente cuando un developer hace por ejemplo un commit, contemplando el diseño del protocolo de CI que hayas establecido en K8s (y en este "Jenkins-pod" ya está toda la lógica de CI, code-testing, etc... y pipelines)?

1 respuesta
wdaoajw

#71 básicamente lo mismo que castocillo dice. En mi caso, mi empresa tiene un montón de maquinas físicas por el tipo de negocio al que se dedica, por lo que aunque estamos migrando a la nube, las maquinas siempre que se puede se reaprovechan.

Los repos (en mi caso, Gitlab y Svn) detectan un commit y comienzan el ciclo de CI (build, test y analisis). El ciclo de CD tambien esta automatizado en Jenkins pero se lanza a mano por tenerlo todo mas controlado. Y para la gestion de aprovisionamiento uso Ansible tanto en las maquinas fisicas como en las cloud.

#77bLaKnI:

Entonces el modulo de Jenkins se levanta solamente cuando un developer hace por ejemplo un commit,

Esto no es asi, siempre debe haber una instancia de Jenkins funcionando, en este caso el master, si no seria imposible que se enterase de que ha habido un trigger.

#77bLaKnI:

contemplando el diseño del protocolo de CI que hayas establecido en K8s

No, Jenkins gestiona el ciclo de CI/CD, K8s orquesta los recursos de los que Jenkins dispone y los dimensiona dependiendo de la necesidad del momento, si necesita mas instancias las crea, y cuando dejen de ser necesarias las elimina.

1 1 respuesta
bLaKnI

#78 Ansible, para maquinas físicas... que hace: ¿manda un email automáticamente a un proveedor que tenéis con la cantidad de workstations a suplir en la oficina? xD
Y a nivel de cloud, que tenéis? Un VPC en con algún provider? Oracle Cloud? AWS? Google Cloud? Azure?

Esto me ha parecido el broche:
https://www.ansible.com/integrations/cloud/amazon-web-services

aunque ya teniendo una potencia demesurada con el package completo en AWS, para que ANSIBLE entonces? Si tienes algo como
AWS CloudFormation https://aws.amazon.com/es/cloudformation/ ?

1 respuesta
Stricken

Estoy recibiendo muchos privados en los que me decís que la oferta os interesa pero que no tenéis experiencia con Ruby. ¡Ningún problema! Buscamos gente capaz de hacer buen software.

¿Qué entendemos por buen software? Grosso modo, que respete los principios SOLID y esté cubierto por tests.

Tampoco vamos a tirar a nadie por no tener experiencia implementando DDD, aunque sí que es un requisito para estar en la parte alta de la banda salarial.

Mañana o el lunes edito el post con toda la info que he ido poniendo en los hilos y añado también cómo es el proceso. Desde que aplicas hasta que te hacemos una oferta hay unas 6 entrevistas:

  • Telefónica (Con alguien de RRHH)
  • Team Lead (Tech Lead + Uno de nosotros random)
  • Code Review (Tech Lead + El mismo que te hizo la otra)
  • Peer Interview (2 Miembros del equipo random)
  • Values (Con el VP de Payroll)
  • Founder (Con alguno de los 3 fundadores, suele ser con Arseniy (CTO) o Roman(CPO))
1 respuesta
C

#80 pero vais a pagar 45K a gente sin experiencia??

3 respuestas
HeXaN

#81 ¿Si son buenos y cumplen con lo que buscan por qué no? Para eso están las entrevistas.

1
Stricken

#81 Sí. Si eres capaz de hacer buen software el tener experiencia o no con Ruby no será un problema.

Yo cuando entré no tenía experiencia con Ruby, ni los siguientes 3 después de mí.

EDIT: Entendí mal lo de la experiencia.

Aziwar

@bLaKnI nosotros tenemos también Jenkins con agentes dinámicos en instancias spot en AWS. Básicamente es eso, tu controlas "todo", y si un día decides no utilizar AWS para X pipeline sino máquinas locales u otro cloud, cambias el agente del pipeline y listo. Ni si quiera usamos k8s como dicen, los agentes se lanzan directamente en AMIs precocinadas.

Respecto a infrastructura en código, usamos Terraform en vez de CloudFormation. Terraform es más rápido porque resuelve los recursos / dependencias de un modo paralelo, mientras que Cloudformation es secuencial.

1
Lecherito

#81 Lo que cuesta en este mundo es que te llegue alguien espabilado que se sepa manejar con lo que le pongas. Sepa pedir ayuda y sepa trabajar en equipo, que sepa los fundamentos del software mas que saberse absolutamente todo de un lenguaje pero luego le pones otro y no sabe ni donde estan los bucles.

Se aprende rapido

C

#79 Ansible nos permite, por ejemplo, definir roles y playbooks que ejecuten una serie de operaciones en un conjunto de máquinas o hosts definidos dinámicamente por labels que se encuentren en cualquier lado con muchisima facilidad y versatilidad.

La pregunta siempre es la misma ¿por qué Ansible si tienes X herramienta? ¿Por qué Jenkins si tienes otra? Pues porque por nuestro stack tecnológico, basado en IaaS, PaaS de Azure y Aws y máquinas on premise nos parece mucho más útil y versatil usar herramientas que nos den esa flexibilad que las propias nativas que nos ofrece cada proveedor y que al final te ata a su propio stack tecnológico limitado.

Entiendo que para una empresa pequeña que haya nacido en la nube y exclusivamente en una nube pueda ser buena idea usar "Cloud Formation" o "Azure Devops" y demás... pero Ansible, Jenkins, Kubernetes y demás pueden usarse con eficacia con independencia de tu stack tecnologico.

Cada proyecto y empresa tiene necesidades distintas y no hay una que sea "la mejor". Solo elige sabiamente lo mejor para la empresa que te paga.

1
kidandcat

#47 Yo vivo en primera linea de playa en Roquetas

bLaKnI

Esta quedando un thread delicioso. Thanks.

Yo por mi parte, he sido (y soy en corazón) developer, desde que tengo memoria...
El tiempo y los años, me han llevado a la presente situación como CTO (sector financiero siempre, y empresa grande). El tema es que se me presenta una posibilidad nueva: hacer de CTO, pero en una startup que lo tiene todo por definir tecnológicamente (sector financiero también)...
Como CTO, me he encargado de las transformaciones digitales de allí donde he estado. Pero estas, han sido transformaciones de infraestructuras y migración de entornos, así como luego cambiando a rol de CIO, redefinición de procesos y modelo de negocio. Pero no hablamos de empresas de desarrollo ni programación. Con lo que el concepto CI/CD + DevOps tal como lo entendemos, no existe ni ha existido.
El "problema", es que en una startup como la que tengo en el horizonte, la función como CTO, esta por lo que veo, muy altamente dedicada a ello (CI/CD + DevOps puro). Y tengo que ponerme las pilas.
El tema, es que migraríamos todo el stack tecnológico presente (usuarios, active directory, fileservers, correo... etc. Lo que conforma la empresa como tal) a un nuevo entorno, y mentalmente, hubiera tirado por la vía clara: proveedor que acompañe bien, y hacer un proyecto full-VPC. Como hasta el presente.
Pero no puedo dejar de lado todo el entorno de desarrollo, y no vale en levantarles instancias de servidores en Windows 2016, y dejarselas con permisos administradores para que las alteren al gusto...
Así que tengo que mezclarlo TODO.
Al ser startup pequeña, como CTO, haría un poco de todo veo... Pero quizas sería interesante el proponer de buscar un perfil DevOps específico, con el que hacer tandem.
Lo que pasa es que no soy capaz de ver la dierencia o línia separatoria entre un CTO y un DevOps en una startup primeriza con un planteamiento de resoruceing-as-a-service según perfilado de codigo, como lo que comentábais ahora con AWS CloudFormation o Terraform. Esto ultimo, se carga literalmente la figura del CTO... o no, si este ultimo se encarga solamente de la infraestructura de la empresa, y la parte de infra que sostiene la línia de trabajo/developping, se plantea con budgets variables dinámicos, y se deja en manos de un head-developer con perfil alto DevOps...

¿que me decís?

2 respuestas
kidandcat

En una startup, una persona que tenga únicamente el rol de DevOps no pega ni con cola, entonces eso de startup tiene lo que de caballo. Como dices, no puedes diferenciar la linea porque en una startup como CTO te toca comerte esa parte, lo suyo sería que compartieras el rol de DevOps con algún otro técnico, ya sea developer, o el que pueda dedicarle tiempo y tenga conocimientos.

O podéis subcontratar a un DevOps para lo mismo, para distribuir la carga entre tu y él, pero tenerlo en plantilla no lo veo.

1 respuesta
C

#88 #89 lo primero que tienes que tener en cuenta es que "DevOps" no debe ser considerado un "perfil profesional", ni en una startup ni en una empresa grande, sino más bien una filosofía de trabajo en la cual todo el mundo en el proyecto está sensibilizado con la operación, despliegue y calidad del producto.

Ya pasaron los tiempos en el que el developer acababa su desarrollo, se lavaba las manos y que venga luego el release engineer a desplegar, construir y testear mi producto. Y luego mas tarde que venga el equipo de operaciones y defina opere mi software según unas especificaciones que ha definido Dios sabe quién.

Ahora los equipos han de tener visibilidad de toda la cadena, desde que se pica código hasta que se despliega y han de estar sensibilizados con cada una de las fases por las que va a pasar el software en toda la cadena de CI/CD y en la operación del mismo.

Tu labor como CTO debe ser la de instaurar y evangelizar esa filosofía y de tener a gente que sepa provisionar ese stack tecnológico para llevar a cabo todo el proceso de CI/CD, monotorización y operación y que, además, tengan las dotes de comunicación necesarias como para hacer partícipes tanto a la gente de desarrollo como a la de operaciones de todo el ciclo de vida del software. Eso es a lo que se le llama hoy en día un "DevOps".