Recientemente, debido a mi trabajo, seleccion茅 pasantes en nuestra empresa. Todos los que recuerden c贸mo es ser un interno / junior deben recordar lo dif铆cil que es quedarse atrapado en un lugar m谩s o menos normal sin experiencia, donde gastar谩n recursos en su capacitaci贸n. Debido al hecho de que el flujo de desarrolladores principiantes es muy grande, el empleador tiene la oportunidad de elegir entre este flujo, si no el mejor, y al menos hombres inteligentes y prometedores que valen la pena dedicar tiempo a la capacitaci贸n para luego emplearlos.
Cada empresa tiene su propia metodolog铆a para encontrar dichos candidatos. Hoy, nos adherimos a lo siguiente: damos una peque帽a tarea de prueba (aproximadamente una hora de trabajo, para un desarrollador experimentado), para la cual el conocimiento de java-core es suficiente y solicitamos ponerlo en un github. No limitamos el tiempo de ejecuci贸n. Luego, cumpliendo cualitativamente la tarea, los solicitantes son invitados a una entrevista.
Una tarea generalmente contiene una implementaci贸n de m茅todos CRUD en un archivo a trav茅s de un
men煤 de consola con una o dos entidades m谩s la validaci贸n de algunos campos. Como ejemplo, dar茅 una situaci贸n cl谩sica con un usuario que necesita implementar la validaci贸n de correo electr贸nico y tel茅fono de acuerdo con una plantilla dada y para esto poder ingresar de 1 a 3 tel茅fonos. Hay muchas respuestas y hay muy pocos lugares; en consecuencia, la selecci贸n es bastante estricta.
Comenzando a verificar todas las tareas seguidas, result贸 que toma aproximadamente 30 minutos probar el rendimiento con el lanzamiento y la retroalimentaci贸n de cada tarea, tuve que revisar la metodolog铆a de verificaci贸n y derivar criterios para filtrar r谩pidamente el c贸digo de alta calidad insuficiente. Por ejemplo, al abrir una soluci贸n en un github, veo que todo el c贸digo se concentra en varias clases e incluso se acumula en un paquete: una falla r谩pida (驴qu茅 pasa con los principios de OOP?).
Muchos pueden encontrar este enfoque injusto, para decir que el problema est谩 resuelto, el c贸digo funciona, pero la vida del interno y el joven es dura y despiadada.
En este sentido, ofrezco mi lista de recomendaciones para completar la tarea de prueba
- Su decisi贸n debe funcionar de acuerdo con los TdR
Siga cuidadosamente los requisitos establecidos en las condiciones para resolver el problema. No piense en sus campos en las entidades, no cambie las condiciones de validaci贸n, etc. Y as铆 sucesivamente. Esto muestra cu谩n atento est谩s a los detalles, lo cual es muy importante para el desarrollador. - Verifique cuidadosamente la tarea completada
Realizada la tarea, verifique el rendimiento. Primero, la funcionalidad principal descrita en los ToR, luego adicional. Intente "interrumpir" su aplicaci贸n: verifique o ingrese la aplicaci贸n adecuadamente a la tarea, si ingresa datos no v谩lidos, los datos son lo m谩s similares posible. Recuerda arreglar todo lo que encuentres. - Codificaci贸n
Todos los archivos deben estar en la misma codificaci贸n, en mi opini贸n en UTF-8. Configure su IDE para esto. Recuerde, si tiene Windows, entonces el revisor puede tener Linux, y las sentadillas adicionales con codificaci贸n son una p茅rdida de tiempo para el revisor. - No te comprometas en una confirmaci贸n
Debe comprometerse a medida que resuelve su problema, agregar descripciones claras a las confirmaciones. Si sabes ingl茅s, es mejor en ingl茅s. Esto indica indirectamente que no solo fusion贸 la soluci贸n de otra persona del git, sino que escribi贸 el c贸digo usted mismo. - Intenta no fusionar las decisiones de otras personas
Dado que reclama el m谩ximo para junio, la mayor铆a de las veces todav铆a no tiene suficiente experiencia para usar el c贸digo de otra persona. Las condiciones de la tarea pueden variar ligeramente, y cuando simplemente copia la soluci贸n de otra persona, puede que ya sea un poco inconsistente con la tarea actual. Y la tarea debe completarse exactamente con la tarea (ver P1). - Agregar archivo L茅ame
Agregue el archivo readme.md a la ra铆z del proyecto. Describa brevemente su aplicaci贸n, establezca explicaciones adicionales para el lanzamiento, si es necesario. Si ya tiene otras tareas completadas, agregue el archivo L茅ame all铆 tambi茅n. Por ejemplo, si estoy interesado en un candidato, puedo ver su otro c贸digo. Y si no va aqu铆, tambi茅n puede adjuntar este c贸digo a su curr铆culum. - Haz un men煤 conveniente
La aplicaci贸n debe ser f谩cil de usar. Recuerde que el tiempo para la verificaci贸n a menudo es limitado, as铆 que precargue la aplicaci贸n con datos, agregue un m茅todo para mostrar todas las entidades (que est谩 all铆 en las condiciones). La navegaci贸n por el men煤 debe ser conveniente, por ejemplo, usando n煤meros. Y a veces lo implementan de tal manera que para eliminar una entidad, debe ingresar "Eliminar" en la consola. Sin embargo, uno no puede exagerar e ir m谩s all谩 del alcance de los conocimientos tradicionales. - Haz lo mejor que tus habilidades te permitan.
Como ha decidido llevar a cabo la tarea de prueba, aborde su soluci贸n con el m谩ximo rendimiento. Incluso si la tarea parece trivial y simple, no necesita abordar su soluci贸n formalmente y escribir c贸digo en su rodilla. Y si no va a esta empresa, tendr谩 una soluci贸n completa en el github, que es pr谩ctica. - No olvides los principios de OOP
Deje que le parezca una tarea peque帽a, no lo olvide: la tarea es una prueba y Java es principalmente un lenguaje orientado a objetos. Y analizar谩n no solo la operatividad de la aplicaci贸n, sino tambi茅n el c贸digo. La calidad del c贸digo es una parte muy importante de la soluci贸n . No escriba el c贸digo de espagueti. Pon todo en clases, paquetes. Cree interfaces cuando sea necesario, realice transferencias a ENUM , si es necesario. - Intenta usar patrones de dise帽o
Una aplicaci贸n exitosa de al menos un patr贸n de dise帽o mostrar谩 que tiene un concepto sobre los patrones de dise帽o (o no). Justo antes de aplicar este o aquel patr贸n, descubra cu谩l es la idea, c贸mo deber铆a funcionar y por qu茅 se invent贸. Si veo patrones en el c贸digo, en la entrevista puedo hacer una pregunta sobre el patr贸n aplicado. - Usa recursos
Todos los mensajes que se muestran al usuario se toman mejor en los recursos y se toman desde all铆. Esto le mostrar谩 al revisor que usted sabe c贸mo trabajar con recursos y entender para qu茅 se utilizan. Los mensajes se muestran mejor en ingl茅s. - Recuerde redefinir d贸nde es igual a hashcode
- Use funciones java8 + como expresiones lambda, secuencias
No olvide que con mayor frecuencia las colecciones son m谩s convenientes que una matriz. Si la elecci贸n ha ca铆do a favor de las colecciones, utilice las colecciones correctas. Debe estar listo en la entrevista para justificar su elecci贸n a favor de una colecci贸n o matriz particular. - Pruebas
Si puede, escriba pruebas, pero ya son cinco con algunas ventajas. A menudo, se entiende que cualquier buen c贸digo generalmente se cubre en las pruebas. Aunque para la tarea dada en el ejemplo, la ausencia de pruebas no ser谩 una desventaja, ya que esta es una aplicaci贸n de consola simple para conocer Java Core.
Resumen
Una gran mitad de los solicitantes env铆an una soluci贸n al problema sin errores y un c贸digo s贸lido: unidades que pasan por la selecci贸n natural y entran en la siguiente ronda. Todos los artistas reciben comentarios. Aquellos que escribieron un c贸digo s贸lido que lleg贸 a lanzarse, una retroalimentaci贸n personal, aquellos que enviaron espagueti escrito sobre sus rodillas, son m谩s generalizados.
PD: Espero que mi consejo los ayude, queridos solicitantes, a realizar mejor sus tareas de prueba y es menos probable que lloren a los probadores con l谩grimas de sangre. 隆Buena suerte en tu b煤squeda y un buen punto de partida!