Entrevistas – Contratando a un desarrollador iOS

­

Para empezar vamos a hablar de las cosas más importantes a la hora de entrevistar a un candidato. Primero que todo la parte técnica por un lado es importante y segundo es importante tambien tener en cuenta la parte personal.

 

Lo personal

Hablando del tema si el candidato encaja con el equipo es importante ver su metodología de trabajo, su actitud, su trabajo en equipo, una de las cosas es preguntar es que tan grandes han sido los equipos con los que has trabajado para saber si cuenta con dificultades para relacionarse, es verdad que hay gente que por años solo ha trabajado por su cuenta. En ese caso hay que ver otras cosas para saber si en verdad va a poder trabajar en equipo.

En el mundo de iOS es facil encontrar gente que no ha trabajado en equipos grandes y a la hora de compartir codigo se nota bastante. Algo que se ve bastante en la gente sin experiencia es que todo el tiempo quieren hacer las cosas perfecto, que si está bien pero también hay que mirar otros puntos de vista, entonces si es importante tener esto en cuenta y hacer preguntas donde la persona muestre como ha trabajado, que herramientas ha utilizado y que haría si alguien le pide un cambio o que haria cuando tiene presion para terminar algún desarrollo.

Esto es importante de identificar porque mucha gente con esto se molesta y no se siente cómodo. Entonces hay que encontrar un balance entre hacer todo perfecto y bien como dice la teoría y un poco lo que marca el business, la aplicación, las necesidades que tienen. Muchas veces hay que ir al App Store rápido para probar un feature con público real y al desarrollador se le pide ejecutarlo rápido, a veces hay que saltarse algunas metodologías, depende mucho del negocio porque de que sirve una aplicación que es perfecta, tiene un código perfecto y nadie usa. También mucha gente le da muchos nervios en las entrevistas pero al final son muy buenos cuando están sin la presion.

Continuando con las características personales a considerar en una entrevista, son las herramientas que han utilizado, que procesos, que metodologías, si Agile, Waterfall, esto depende del tipo de empresas en que ha estado y también de la ciudad, por ejemplo; en Londres todo es Agiles, SCRUM y TDD. También es importante que tenga la capacidad de cambio, que reconozca y se adapte ya que cada empresa tiene su metodología y su forma de trabajar.

Otra pregunta que es buena preguntar y que es algo crítico es cuando se pregunta sobre el Code Reviews y el Pair Programming, si al responder dices que no te gusta y te cierras, eso es algo que te puede descalificar inmediatamente y para decir la verdad muchas veces no se hacen o se utilizan, pero responder en una manera cerrada es un indicador de que la persona es muy individualista y sería difícil trabajar con ella, ya que no le gusta compartir o tener a alguien a su lado.

 

La parte tecnica

Pasando a la parte técnica, depende de la empresa pero se suele tener una parte de conversación con preguntas y una parte de código. La primera parte es muy importante y es la parte teórica que no solamente es de iOS sino también en conceptos genéricos, por ejemplo: Design patterns donde no tienes que ser un especialista con saber 4 o 5 Composicion, Dependency Injection, Builder, Lazy initialization, es decir los comunes y que se usan al día al día.

Una segunda cosa es buenas prácticas no solo en iOS sino también en programación en general como clean code para implementar tu código en una forma en que la gente lo entienda, entonces hay que conocerlo aunque sea y  tener claro que es. También hay que ver prácticas de SOLID principles, etc.

Una vez que se terminan estas preguntas que son muy genéricas y que no están tan enfocadas en iOS sino en cosas generales de programación, viene el apartado de bloques básicos de una aplicación iOS como el networking, UI, almacenamiento, controllers, etc. Cuando se hace una entrevista hay que tratar de no dar mucha informacion, para que las personas se expliquen y digan lo que saben del tema.

UI

Entonces una de las preguntas que más se hacen con el tema UI es que cuando estás haciendo performing de operaciones que toman mucho tiempo. Que implicaciones o que pasa con UI? es algo importante y sencillo que todo el mundo lo debería saber, la respuesta es simple el UI siempre debería estar libre para que se pueda interactuar con él a no ser que se esté haciendo una transacción, pagos, etc. Segundo de la parte de UI es como la haces, qué diferencias hay en hacer el UI programático o hacerlo con storyboards o xibs, y preguntar cuando se usaría una y cuando la otra porque eso demuestra que conoce un poco los tres y cuando usar uno u otro, otra cosa que es importante es que la personal esta abierta ya que no hay una solución especifica perfecta, todas son buena y todas son malas, siempre hay una caso para cada cosa.

Networking

Con respecto al tema networking una de las preguntas de entrada es preguntar que frameworks conocen y la razon porque usar uno u otro, entonces con esa pregunta pueden explicar y saber que conocimientos generales tienen de networking. Un tema relacionado con networking es el de concurrency, esto es importante preguntarlo ya que no mucha gente sabe cuales son las formas de hacer concurrency. En este caso una pregunta simple y directa para saber que sabe la personal del tema es. ¿De qué manera puedes hacer con concurrency en iOS? Y con que te respondan y te hablen de GCD y operation queues, cuando utilizarias uno u el otro es casi que suficiente para entender si el entrevistado conoce las herramientas. Lo gracioso es que muchas veces la gente se enrreda y no entiende como funciona.

Almacenamiento

En el tema de almacenamiento la primera pregunta sería ¿Qué tipos de almacenamiento conocen? NSUserDefaults, CoreData, NSCoding, Keychain, etc. Hablando ya de CoreData en especifico hay un tópico interesante que normalmente el 90% de la gente que se le pregunta no sabe. Que es el tema de concurrency en CoreData. Si vas a ir a una entrevista es importante conocerlo y saber como se maneja. Por otra parte es verdad que hay aplicaciones que no van a necesitar CoreData pero aun asi es fundamental conocerlo ya que es una herramienta fundamental a la hora de construir una aplicación, porque tarde o temprano si es una aplicación avanzada va a necesitar almacenamiento de datos y saber lo que te ofrecen iOS nativamente es fundamental.

Arquitecturas

Otras pregunta clásica es la de arquitecturas. Cuando a la gente le preguntas sobre arquitecturas con que te respondan y sepan 3 o 4 y sepan que hacen, como diferenciarles, ventajas y desventajas de usar una u otra, eso es lo fundamental. Es importante que muestren flexibilidad ya que dependiendo de la aplicación todas son buenas.

Coding test

Finalmente llega la etapa del coding test, esta parte es importante porque mucha gente lo hace bien en la parte teórica pero al momento de aplicar sus conocimientos fallan bastante. En las entrevistas que hemos hecho últimamente el 95% de las personas no lo hacen bien y algo que sorprende es que el 80% tiene una entrevista teórica buena, pero al cambio en el test escrito al escribir un pedazo de código que haga x o y es horrible.

Entonces no solo es importante saber la teoría sino practicarla, otra cosa a tomar en cuenta es cuando estas en una entrevista te dan una hora o media hora y no hay que ponerse hacer cosas extras que no se necesitan hacer, hay que hacer las cosas principales y lo que sabes.

Lo que se busca conocer es como el entrevistado ejecuta una tarea básica en un tiempo limitado, la idea es que te muestren una arquitectura simple donde te muestren que pueden hacer la tarea. Por otra parte lo que se busca es que no hayan red flags como force unwraps o pasear datos en el app delegate. También es importante recordar que aunque el tiempo sea limitado y la tarea sea sencilla siempre se debe tratar de hacer las cosas bien hechas. Tratar de seguir las practicas que utilizas normalmente. Y aunque el ejercicio no se acabe o no se muestren los datos que se deben mostrar, si encuentra una buena arquitectura con dos o tres capas básicas el controller, data source y parseo es suficiente para ver como la persona trabaja, es mejor no cometer errores graves que tratar de brillar y al final no salir con nada.

 

Deja un comentario