Proceso con buenas intenciones pero con problemas serios en (a) la comunicación de los requerimientos y (b) la honestidad del feedback final. El primero de screening es normal, y generalmente bastante buena onda. El segundo paso es un ejercicio tecnico y aqui es donde yo personalmente tuve problemas. El plazo para realizarlo es de 3 dias pero pueden considerar extensiones de tiempo si es necesario y bien comunicado. La cantidad de consignas son realizables dentro de esos 3 dias, especialmente si uno elige su propio framework o libreria en la que tiene mucha experiencia. Sin embargo, con la COMUNICACION de las consignas empieza el primer gran problema: Presentacion de las consignas: 1) Una parte de las consignas esta escrita en el README.md del repositorio que te comparten (en ingles) 2) La otra parte esta escrita en un email que te envian para confirmar que recibiste el ejercicio (en español). La redaccion de las consignas: Al principio parece bastante claro cuales son los requerimientos, o por lo menos, parece bastante claro cuales son los principales y cuales son los detalles. El problema es que hay algunos que se han escrito de una forma muy ambigua, y que en el documento no tiene la jerarquia que deberia tener, son un apartado ultra secundario al final del documento. Ademas hay un punto en especifico que dice: "these record may become millions in the future". Ellos proveen una lista de 30 elementos nomas, si la lista fuera de 200 claramente necesitaria paginacion. Que quiere decir que se vuelvan millones? El mejor manejo para un gran volumen de datos son filtros, no paginacion, y los filtros no fueron un requisito explicito. La segunda parte de mi problema, y la mas grande, es la evaluacion del ejercicio: Si bien nadie se toma bien el rechazo, yo ya he hecho tantas entrevistas que no me afecta ser rechazado, lo que no puedo permitir es que me den un feedback negativo falso y deshonesto. En este caso parte de la respuesta fue: "durante la revisión surgieron algunos puntos importantes relacionados con arquitectura, modelado de datos, escalabilidad y completitud de la solución. .... la separación de responsabilidades entre capas y modelos, la cobertura de testing y algunas decisiones de diseño que podrían dificultar el mantenimiento y la evolución de la aplicación a futuro" No hubo un solo artefacto en mi codigo que tuviera mas de una responsabilidad. Los componentes solamente se encargaban de renderizar, tenia un servicio para Data fetching y otro para hacer transformacion y manejo de datos daba soporte a los componentes, ningun componente hacia data-fetching de forma directa. Hasta las partes que sugerian cierta complejidad algoritmica se les aplico un design-pattern acorde. Si confieso que de mi parte hubo un solo error que fue no haber agregado i18n, y aunque el ejercicio lo requería, nos tenemos que remontar al problema de la comunicacion de las consignas en el apartado anterior. SI me hubieran rechazado solo por eso, lo tomaria sin quejas. Escribo este review para que quien vaya a hacer el proceso de seleccion cubra los puntos que yo no cubri, y tambien porque creo que los feedback deshonestos son muy peligrosos para la industria. No podes venir con que hay problemas de escalabilidad o arquitectura en un ejercicio de 3 dias, y que encima, tiene comentarios y separaciones claras en cada archivo del codigo.