¿Cómo puedo filtrar los trabajos de ingeniería de software en los que se me pedirá que escriba algoritmos en la entrevista?

Rara vez actúo como "programador" en mi trabajo diario. Dirijo un equipo de ingenieros y me considero un ingeniero. Creo funciones, corrijo errores, trabajo en API, bases de datos, etc., pero rara vez tengo que escribir algoritmos... y cuando lo hago... simplemente busco en Google la mejor manera de hacer algo y esto me ha funcionado durante la ultima decada.

He perdido mucho tiempo siendo entrevistado por personas que quieren que resuelva preguntas de estilo LeetCode y simplemente no me importa entrar en ellas. Soy un ingeniero jefe con un buen currículum y un buen sueldo, y quiero mantener este tipo de puesto a lo largo de mi carrera.

¿Cómo les digo a las empresas que no estoy interesado en manipular algoritmos para entrevistarme con ellas?

Los comentarios no son para una discusión extensa; esta conversación se ha movido a chat .

Respuestas (13)

En primer lugar, es posible que tenga una terminología incorrecta. Cómo veo que las palabras "programador" se usan con más frecuencia para describir una posición en la que se escribe código simple de acuerdo con las especificaciones y API existentes, donde "ingeniero de software" es un trabajo que involucra algoritmos complejos, patrones de diseño, arquitectura y diseño de sistemas. Es posible que desee buscar trabajos de programación en lugar de trabajos de ingeniería de software.

Soy ingeniero jefe con un buen currículum y sueldo, y quiero mantener este tipo de puesto a lo largo de mi carrera.

Creo que esta es la excepción y la mayoría de las empresas esperan que un ingeniero de software líder pueda resolver variaciones simples de un problema de gráfico o búsqueda de lista. Si quieres ser ingeniero líder, creo que deberías acostumbrarte a la idea de aprender algoritmos. No es que se espere que escriba algoritmos complejos todos los días, pero si no puede ver la diferencia entre una solución O(N^2) y una solución O(N), no podrá reconocer un problema cuando tropiece al respecto, por ejemplo, cuando como ingeniero líder está revisando el código de desarrolladores más jóvenes.

Entonces, si se entrevista para un puesto de "ingeniero de software líder", es muy probable que esté perdiendo el tiempo. ¿Ha considerado buscar más roles gerenciales, como gerente de infraestructura o gerente de ingeniería?

Los comentarios no son para una discusión extensa; esta conversación se ha movido a chat .
Creo que esto es muy específico del país. En la mayoría de los países europeos, a la mayoría de las empresas no les importa mucho. Es posible que pueda escribir algoritmos increíblemente eficientes, pero si su código se ve horrible y no se puede mantener, aún así no debería ser contratado. Por lo tanto, muchas empresas le asignan una tarea de codificación en su lugar. Un problema real que tienes que resolver en unos días. No hay necesidad de hacerlo súper eficiente. Pero tiene que ser mantenible y tiene que funcionar bien.
Puedo decir un poco por experiencia personal que, si bien las entrevistas de Google tienen una gran cantidad de algoritmos, se supone que debe ajustarse según la posición, y el énfasis está más en poder descifrar un buen enfoque que en que usted pueda resolverlo de una manera correcta en particular. Sí, algunos entrevistadores no entienden eso bien, por supuesto.
Soy ingeniero de software y ahora arquitecto de software. Trabajé para los bancos más grandes de mi país, para múltiples sucursales gubernamentales, para empresas de logística/transporte, y nunca tuve que escribir un solo "algoritmo" en toda mi carrera.
La mayoría de los trabajos, al menos en mis últimos 10 años como ingeniero de SW en Finlandia, han tenido prácticamente cero algoritmos involucrados. Implementaciones de AWS, interfaz de usuario/interfaz de usuario, API de descanso, consultas de base de datos y actualizaciones y migraciones de modelos, integraciones, investigación de registros, implementación, configuración de Jenkins, pruebas unitarias y de integración, etc. Una gran cantidad de trabajo de software e2e, pero nunca hubo la necesidad de hacer un algoritmo. diseñar o implementar un algoritmo desde cero.

Los concertistas de piano aún pueden tocar escalas. Los algoritmos no son algo extraño que solo usan los académicos. Son patrones de diseño mínimos y encapsulados que se usan bastante en la mayoría de los dominios. Sí, ningún cliente acudirá a usted y le dirá: "Por favor, implemente una búsqueda binaria en su próxima versión de software", pero le dirán : "Esta página es demasiado lenta" y una búsqueda binaria resultará ser la mejor manera. arreglarlo.

Si tiene un problema de "esto es demasiado lento" y no puede conectar los puntos para saber que necesita una búsqueda binaria y poder comunicar de manera concisa que eso es lo que necesita, simplemente se lo pasará a otra persona en la empresa. quién puede. Como una de las personas a las que se les suelen asignar los errores "este otro equipo no puede hacer algoritmos", puedo decirles lo molesto que es trabajar con personas que no creen que eso sea parte de su trabajo.

Creo que esta es la respuesta correcta. Solía ​​ODIO las entrevistas de algoritmos, por la misma razón que OP parece hacerlo. Pero luego tuve un trabajo que REALMENTE quería que tenía una etapa de algoritmo muy extensa del proceso de entrevista, así que me agaché y estudié problemas de tipo "leetcode" y ¿sabes qué? Me hizo un desarrollador mucho mejor. Pensar en el Big-O de una pieza de código ahora es solo una segunda naturaleza, y aunque rara vez resolverá los mismos problemas en el mundo real (pocos desarrolladores realmente necesitan ordenar un BST), los trucos que aprenda serán aplicable a todo tipo de problemas del mundo real.
En realidad, esta no es una buena respuesta porque no intenta responder la pregunta real; cómo evitar que las entrevistas parezcan contener preguntas de estilo básico. Ser un líder de equipo se trata más de personas que de algoritmos, en muchos lugares el líder de equipo está flanqueado por un líder técnico por esta misma razón.
Hay una gran diferencia entre conocer las clases de complejidad con experiencia sobre qué usar y dónde versus codificar la ordenación rápida a mano. Un buen ingeniero líder debe saber que para este problema específico, una búsqueda binaria es la solución óptima. Pero un buen ingeniero líder no tiene que implementar el algoritmo en sí mismo. Básicamente, todos los lenguajes modernos tienen las estructuras de datos y los algoritmos para tales cosas, y estos han sido desarrollados, probados y ajustados durante mucho tiempo por muchos expertos que se enfocan solo en eso . Pregunte en crypto.se sobre el cifrado casero y vea cómo reaccionan.
¿Qué son las "escalas"? [Esto no es tanto pedir una aclaración como señalar que tu metáfora/comparación puede no ser tan comúnmente entendida como crees]
Sin embargo, @Val, un ingeniero principal, puede necesitar decidir que la biblioteca simplemente no es suficiente para su problema y que necesita una pequeña modificación, deben ser lo suficientemente competentes para ver eso, y hacerlo ellos mismos o guiar a alguien para que lo modifique correctamente. . No necesitan poder hacerlo sin investigación, pero deben poder hacerlo cuando sea necesario con una cantidad razonable de investigación.
@FrankHopkins: Eso es cierto, pero una pregunta de la entrevista como "aquí hay una hoja de papel en blanco (o un archivo vacío), ahora implemente la ordenación rápida en cinco minutos sin usar referencias externas" fallará a esos candidatos y seleccionará candidatos que eran buenos en haciendo su tarea y buenos para memorizar cosas perfectamente, incluso si no las entienden completamente, pero no muy buenos para encontrar buenas soluciones a los problemas de la vida real.
@Val sí, ese podría ser el caso. Por otra parte, nunca tuve una pregunta de entrevista de este tipo y no las contaría en el caso general de las preguntas a las que se refiere OP (recitar aproximadamente cómo funcionan uno o dos algoritmos de clasificación populares en general y explicarlo, lo tuve y consideraría en el estadio normal ; pero luego volvemos a saber cuál aplicar y por qué, y de todos modos ninguna pregunta individual fallaría a un candidato en una buena configuración de prueba). Tal vez si estuvieran tratando de evitar preguntas algorítmicas "malas"... ;)
@BernhardBarker En realidad, como persona completamente no musical, tengo una idea bastante buena de qué son las escalas. Además, sin embargo, solo por el contexto, es bastante obvio que es algo bastante básico que haces en un piano.
Me encanta esta respuesta, pero creo que plantea la pregunta: ¿cómo se entrevista a los concertistas de piano?
Esto no responde la pregunta. Peor aún, propaga el mito de que las pruebas de pizarra son buenas para medir las habilidades de ingeniería de software.
Saber sobre algoritmos y recordar exactamente cómo implementarlos son dos cosas diferentes. Tome el comentario de Val sobre quicksort. Debería conocer sus ventajas y desventajas, pero es algo que pocos programadores necesitarán implementar en estos días.

¿Cómo les digo a las empresas que no estoy interesado en manipular algoritmos para entrevistarme con ellas?

Respondiendo a una invitación a tales pruebas con un "no, gracias". Puede intentar proponer un proceso alternativo para ir con el "no", pero eso es un avemaría.

Si eres bueno, eventualmente encontrarás una empresa que esté de acuerdo con tu visión del mundo. De lo contrario, es posible que tenga que comprometerse y hacer las pruebas de escritura del algoritmo o enfrentar el desempleo.

Esta es probablemente la mejor respuesta. Nadie puede obligarte a hacer algo en contra de tu voluntad, así que simplemente recházalo. Por supuesto, las consecuencias de eso son obvias, pero si alguien está tan decidido a pasar quizás de 30 minutos a una hora de su tiempo demostrando las habilidades básicas del trabajo, ese es probablemente el mejor resultado para todos los involucrados.
Todavía es una pérdida de tiempo ir a una entrevista, decir que no y ser expulsado el x% del tiempo.
@ usr1234567 ¿cómo es? Puede haber varias razones por las que alguien rechaza o no le ofrecen un trabajo. "No hablaré de algoritmos. Debo tener un asiento junto a la ventana. Si no tengo al menos tres monitores, me voy. Espero avanzar anualmente". etc. etc. ¿Vas a darles una lista de compras antes de siquiera estar de acuerdo en encontrarte con ellos? Literalmente, el objetivo de una entrevista es averiguar si la empresa quiere contratarte y si quieres trabajar para ellos. Descubrir que no lo hace (incluso por una razón tonta como la de OP) es para lo que la entrevista es literalmente .
La pregunta no menciona específicamente las pruebas (en su propio tiempo). ¿También propondrías decir "no, gracias" si te preguntaran esto en una entrevista en vivo? Si no, ¿qué propondrías?
@BernhardBarker en realidad es muy específico sobre leetcode.com Pero ya sea en vivo o no, si no cree que la prueba es algo que quiere hacer, tiene derecho a decir que no e irse. Hace poca diferencia si está fuera de línea o en línea, ahorre todo lo que pueda de su tiempo.
@TymoteuszPaul Ya sea que se niegue a responder una pregunta de la entrevista o se niegue a completar una prueba, hace una diferencia en términos de cuánto tiempo de todos podría haber perdido, qué tan grosero sería considerado y qué tan probable es que uno queme puentes. No es que esté recomendando responder una pregunta a la que uno se opone firmemente, sino que solo quiero señalar los riesgos de negarse a hacerlo en este caso.
@BernhardBarker Pensé que tenía bastante claro que una línea dura como esa puede conducir al desempleo. Ahora, ya sea que esté de acuerdo o no, tengo mis propias opiniones, pero OP no preguntó si eso tiene sentido o no, solo cómo lograr lo que quiere hacer.
@TymoteuszPaul Parecía que simplemente estabas diciendo que puede que no haya muchas empresas que no hagan esas preguntas o que estén dispuestas a preguntar algo más que pueda llevar a que te contraten, en lugar de decir algo sobre la impresión que tendrías. marcharse negándose a contestar. Todo el asunto de no ser contratado no dice mucho sobre lo que piensan de ti, especialmente considerando que responder "no, gracias" podría verse como si te negaras a continuar con su proceso de entrevista (esencialmente diciendo que no quieres el trabajo) más que ellos te rechacen .
¿Me estoy perdiendo la importancia de quién rechaza a quién? Todavía terminas sin el trabajo, y posiblemente sin ningún trabajo.

Simplemente rechácelos si se presentan

Si las empresas usan esto o no, sería difícil determinarlo de manera consistente a partir de la aplicación. En mi organización actual, no me hicieron preguntas algorítmicas. Actualmente estamos haciendo preguntas algorítmicas a los entrevistados porque el ingeniero que realiza las entrevistas ha cambiado.

En otras empresas para las que me he entrevistado, tienen una entrevista de estilo LeetCode que se debe hacer a menos que lo recomienden. Salté directamente a la ronda final como referencia.

En otra organización gubernamental con la que me entrevisté, tienen LeetCode como una de varias opciones que puede usar como prueba de competencia. No se mencionó como parte del proceso de contratación y parecía inusual que el gobierno lo hiciera.

Realmente no puedes predecir.

Si realmente quiere evitar esas cosas, cultive relaciones con los reclutadores que inevitablemente aparecen en su LinkedIn. Descubrí que pueden decirte muchísimo sobre cómo irán las cosas.

Obtenga un reclutador de ejecutivos y concéntrese en trabajos de gestión. Dile al reclutador lo que estás buscando.

Las firmas de consultoría de búsqueda de ejecutivos se utilizan normalmente para puestos ejecutivos de alto nivel y directores de juntas. Las asignaciones son generalmente para puestos en los que el mejor candidato es más difícil de encontrar y más difícil de persuadir para hacer un movimiento, y donde el impacto potencial del éxito o el fracaso es mayor. Los reclutadores contingentes se utilizan con mayor frecuencia para puestos de nivel medio o puestos en los que hay una gran cantidad de candidatos calificados. Tres cosas que los candidatos deben saber sobre los reclutadores ejecutivos, Forbes

No asuma que un consultor de búsqueda de ejecutivos retenido lo comercializará con múltiples empleadores para obtener la mejor oferta... Ningún candidato que haya sido presentado por una empresa cliente debe ser referido a un cliente diferente hasta que el cliente original haya cerrado al candidato. Dado que los reclutadores de contingencia no se retienen, comercializan candidatos para múltiples empleadores al mismo tiempo. Lo hacen para maximizar las posibilidades de una colocación y recibir un pago. Sin embargo, solo comercializan los llamados MPC (candidatos más colocables) y se centran en roles de nivel inferior. Cómo llegar a conocer a un reclutador ejecutivo retenido

No es fácil conseguir un Reclutador Ejecutivo, pero puede ser algo a lo que desee apuntar eventualmente.

Gire su carrera hacia la gestión.

Al leer la pregunta, tuve la impresión de que no tiene mucho interés en la ingeniería de software (de la cual los algoritmos son una parte importante), pero el título del trabajo, el salario y el currículum son importantes para usted. Afortunadamente para usted, la industria del software está llena de trabajos de gestión que se benefician de la experiencia en ingeniería pero que no implican la programación real, como gerente de producto, gerente de línea, propietario de producto, maestro de scrum, etc. Debido al estado de gestión, a menudo se les paga mejor que a la ingeniería roles, y no está compitiendo contra personas que tienen un interés real en su profesión más allá de lo que es obligatorio. Otro beneficio es que en las empresas que no tienen una I+D seria, las carreras de ingeniería son muy limitadas y la gestión ofrece más opciones.

La ingeniería de software se ocupa principalmente de la complejidad, no de los algoritmos.
Bien, actualicé la redacción.
Ahora que lo pienso, la gestión está solo un nivel más arriba en el juego: en lugar de lidiar con la complejidad, se trata de organizar a otros para que enfrenten la complejidad. Pero no estoy seguro si esto es de lo que se trata la pregunta.
@ojs Pero creo que es una buena respuesta. Como ingeniero, me parece bien que los gerentes no sean técnicos. Las habilidades que necesitan para mantener a todos en la dirección correcta y tratar de alcanzar hitos, con la cantidad justa de relleno en las estimaciones pero no demasiado, definitivamente no es mi conjunto de habilidades. Pero si me encuentro con alguien que dice ser un "ingeniero líder" en un equipo de software y dice "Yo no hago algoritmos", me preocupo. No son competentes como ingenieros y se deleitan en su ignorancia, pero de alguna manera están en una posición en la que se supone que son responsables de la calidad técnica. No.
@PeterMortensen hay ambas partes, y algunos trabajos se inclinan más en una y otros más en la otra, un ingeniero de software completo puede manejar ambos. Si desea excluir por completo un lado, debe buscar específicamente trabajos que coincidan. A veces eso funciona a través de la descripción del trabajo, pero algunas empresas simplemente quieren ingenieros que vean un problema algorítmico cuando lo encuentren y que también puedan lidiar con dependencias complejas y similares.
Un consejo sólido, crear árboles binarios y pegar código en Python, o jugar con el desmontaje de C++ en un fin de semana lluvioso es prácticamente un callejón sin salida en cierta etapa de la vida, la administración es solo una progresión natural de cualquier carrera tecnológica.
En realidad, pasar tiempo "preparando árboles binarios y pegando código en python" es un callejón sin salida. La idea es que un ingeniero capacitado debería poder hacer estas cosas sin esfuerzo cuando sea necesario y lograr cosas más difíciles cuando tenga tiempo. En las entrevistas de trabajo, el entrevistado generalmente no tiene tiempo.

Puede consultar http://they.whiteboarded.me/ que tiene la lista de empresas con entrevistas de pizarra.

Ese es un recurso interesante (y presumiblemente útil para aquellos a quienes les molesta este tipo de cosas, aunque sin muchas más presentaciones, las posibilidades de encontrar una compañía determinada allí son escasas). Sin embargo, no estoy seguro de que se ajuste al 100% a la pregunta del OP, ya que no mencionan que se oponen a la pizarra, como tal. Pero relacionado, ciertamente.
Su lista de empresas de pizarras incluye una gran cantidad de empresas excelentes. Tal vez los candidatos deberían admitir que así son las cosas y seguirle el juego.
@QuoraFeans sí, me gusta esa lista, pero contrariamente a las intenciones del autor, considero que es una señal positiva que una empresa haga algunas pruebas de pizarra. Todavía se pueden hacer mal, pero por mi parte los encuentro útiles en las entrevistas, porque como entrevistado también me dicen algo sobre los entrevistadores.

Cuando encuentre una empresa con la que le gustaría entrevistarse, puede ir a Glassdoor y buscar la empresa. Desde la página de la empresa, puede ver las reseñas enviadas por los usuarios, los salarios y las preguntas de la entrevista. Aquí hay un ejemplo de preguntas de entrevista de Google .

Si ha habido muchas preguntas de entrevista enviadas por usuarios para la empresa, entonces puede tener una buena idea de qué tipo de preguntas se harán, incluidos los tipos de problemas de codificación que deben resolverse. Obviamente, si se trata de una empresa más pequeña con pocos envíos de usuarios, es posible que esto no le ayude.

En general, estoy de acuerdo con la respuesta de Helena y asumiría que la mayoría de las empresas decentes esperan cierto nivel de experiencia en algoritmos de las personas que desean desempeñar un papel principal en ingeniería de software. Sin embargo, puede haber algunas excepciones en las que el proyecto requiere principalmente lidiar con los detalles esenciales de la gestión de dependencias y componentes, el rol se inclina hacia la dirección gerencial, el negocio se dirige hacia aplicaciones muy livianas sin ninguna complejidad algorítmica o la empresa no ser 'decente' en el sentido de que entendieron su terminología tan mal como la tuya actual^^. Al menos según su descripción, parece más un líder de equipo que también se desarrolla con un enfoque en el diseño de API y software algorítmicamente sencillo (no hay nada malo en eso, elegir la tecnología adecuada también es una parte interesante del trabajo, simplemente no todo lo que esperaría de un ingeniero de software principal). Entonces, para mí, pareces ser un desarrollador de gestión de equipos. Tal vez también sea particularmente bueno para elegir marcos o diseñar API, entonces podría concentrarse en eso.

Algunas cosas que buscaría en las descripciones de trabajo para conseguir un trabajo adecuado y aumentar la posibilidad de no enfrentar (demasiadas) preguntas algorítmicas serían estas:

  • un enfoque en bibliotecas, marcos y palabras de moda tecnológicas
  • una mención de las responsabilidades de liderazgo de equipo (gestión personal)
  • un enfoque en el diseño de API
  • un enfoque en aplicaciones web ligeras
  • un enfoque en tecnología/arquitectura de infraestructura
  • una cultura emprendedora y de autoaprendizaje*

Entonces, en principio, para trabajos que se inclinan hacia "hacia arriba" hacia el diseño de la capa exterior de las aplicaciones y cómo funcionan juntas sin tener en cuenta la complejidad algorítmica o para trabajos que se inclinan "hacia un lado", por ejemplo, en el dominio empresarial o en el equipo o la infraestructura. gestión. A veces puede haber roles principalmente para diseñar API o "principales" que discuten con personas que conocen el dominio comercial cómo debería funcionar un software a nivel comercial y de API, los detalles luego serán diseñados por ingenieros de software.

* ¿Por qué una cultura de startup/autoaprendizaje? Porque, cliché, sí, pero lo he visto con frecuencia, a menudo no saben correctamente lo que hacen (técnicamente), a menudo contratan a quién pueden conseguir y quién puede implementar cosas rápidamente sin preocuparse mucho por el rendimiento algorítmico. A veces fallan después de un tiempo, a veces tienen éxito y luego pueden necesitar limpiar el desorden una vez que crecen exponencialmente y sus soluciones algorítmicamente ingenuas a pequeña escala ya no escalan, pero aún pueden proporcionar un buen trabajo durante años. A veces, eso no es un problema en absoluto porque su mercado objetivo no necesita un rendimiento algorítmico, solo alguien que escribe algún programa con una interfaz de usuario agradable para ese área de nicho que nadie se ocupó todavía.

Postúlese únicamente a puestos senior , principales o principales y en su currículum indique que es lo que está buscando y, como suele ser veraz, exprese su experiencia en el currículum y en la carta de presentación y correspondencia por correo electrónico como tal.

Al menos en mi cuello del bosque, Junior a "Sin prefijo" recibe estas preguntas. Mayores y superiores, no.

¿Cómo les digo a las empresas que no estoy interesado en manipular algoritmos para entrevistarme con ellas?

Una alternativa es tener tu propia cartera de software de código abierto en plataformas como github o gitlab (o en tu VPS alquilado). Contribuya a proyectos de código abierto existentes (como GCC o FLTK o RefPerSys o Frama-C o zsh o miles de otros). Una vez que seas tan famoso como Linus Torvalds o Guido Von Rossum o Xavier Leroy , estarás bien pagado y tendrás oportunidades de trabajo. Tenga en cuenta que la mayoría de los desarrolladores de GCC o del kernel de Linuxse les paga por su trabajo (ver LWN sobre esto, y tal vez escribir allí...). Una vez que hayas diseñado e implementado un lenguaje de programación que tenga unos pocos usuarios (esto es muy difícil como explica Simon Peyton-Jones ) podrías tener interesantes oportunidades laborales.

Otra alternativa es tener al menos un blog público donde expliques algunas vistas arquitectónicas del software que has desarrollado (o liderado técnicamente). Asegúrese de obtener un permiso previo para eso.

Una tercera posibilidad es tener una puntuación alta en plataformas como StackOverflow . Estar por encima del 1% superior allí.

Una cuarta alternativa es haber escrito y publicado algún libro técnico sobre tu tema de excelencia (o al menos borradores de informes públicos, como este ).

Una quinta alternativa es hacer un doctorado y/o publicar artículos académicos -con revisión por pares- en, por ejemplo, conferencias ACM . Relacionado es que le paguen (a tiempo parcial) para dar alguna enseñanza sobre desarrollo y programación de software y administrar y asesorar a los pasantes.

Otra alternativa es dar charlas de forma voluntaria (y no remunerada) sobre programación y desarrollo de software (como esta que di en francés). Incluso podrían ser videos en youtube sobre programación y desarrollo de software (una vez que se hayan visto miles de veces, por ejemplo, este ).

Tenga en cuenta el principio de Peter . Lea El mes del hombre mítico o, mejor aún, escriba un libro mejor.

No dude en ponerse en contacto conmigo por correo electrónico a basile@starynkevitch.net(casa, cerca de París en Francia) o basile.starynkevitch@cea.fr(trabajo, en CEA, LISTA )

+1, consejo perfecto para alguien cuyo enfoque ha sido "Simplemente busco en Google la mejor manera de hacer algo y esto me ha funcionado durante la última década".

Casi siempre he ido a través de un reclutador y un reclutador sabrá cómo son las entrevistas. Primero, lo sabrán por experiencia, segundo, le preguntarán al gerente de contratación y tercero, informarán a cualquier otro entrevistado que hayan enviado. (He tenido reclutadores literalmente tratando de darme las preguntas de prueba que escucharon de los candidatos que han enviado anteriormente).

Así que simplemente dígale al reclutador que no se moleste en presentarlo para esas entrevistas, si realmente no quiere hacerlas.

Una alternativa podría ser tener un currículum muy pulido. Uno que muestra lo bueno que eres.

Si es posible, también proporcióneles suficiente código para que tengan una idea de cómo escribe el código, corrige errores, trabaja en API o con bases de datos (por ejemplo: un repositorio personal de Github, no relacionado con la empresa actual ).

Y si se le presenta una pregunta al estilo de LeetCode, simplemente enfréntela como parte de la corrección de un error que encontró y que debe corregirse. Esto puede mostrarles que sí conoces los conceptos básicos.

Tenga en cuenta : ¡usar Google para refrescar algunas cosas que olvidó no está mal! (A menos que su código sea 100% StackOverflow copiar-pegar-pegar).
Un ejemplo: tuve una entrevista en la que olvidé cómo conectarme a una base de datos en PHP (mi corazón estaba acelerado y dormí mal ese día).
Me actualicé con algunos ejemplos y escribí lo mío, sin copiar y pegar .
El objetivo era escribir una base de datos + script PHP para almacenar y obtener la información necesaria para un restaurante, en base a un texto descriptivo escrito.


Pero, si realmente no está interesado en resolver esos problemas "falsos", entonces puede intentar negociar un método alternativo para que evalúen sus habilidades y ver cómo va.

Solo tenga en cuenta que esto puede dar una visión menos que óptima de sus habilidades de codificación a la persona que lo entrevista (ciertamente tendría mis dudas sobre sus habilidades de codificación).