No existe una receta sobre cómo debe responder las preguntas de la entrevista de codificación de ciencia de datos. No hay un enfoque que siempre funcione. Sin embargo, existen algunos principios rectores que, en la mayoría de los casos, lo ayudarán a responder mejor las preguntas de codificación.

Estas pautas se forman sobre la experiencia de ir a las entrevistas y responder las preguntas de codificación. Dividimos estas pautas en cuatro secciones. Puede usar estas pautas como una lista de verificación, especialmente si no tiene tanta experiencia con preguntas de la entrevista de codificación de ciencia de datos. Más adelante, por supuesto, podrá encontrar su propio enfoque, tal vez ignorar algunos puntos o incluso incluir algo que funcione mejor para usted.

Pero independientemente de su experiencia, si sigue esta lista de verificación, aumentará sus posibilidades de dar una gran respuesta a una pregunta de codificación.

La lista de verificación de cuatro partes

 
Las cuatro partes de esta lista de verificación son:

1. Análisis de preguntas
2. Enfoque de la solución
3. escribir un código
4. Revisando su código

Ahora que tiene el esquema de la lista de verificación, examinaremos cada sección y explicaremos los puntos de la lista de verificación que contiene.

1. Análisis de preguntas

 
La parte de análisis de preguntas de la lista de verificación trata de tomarse unos minutos y pensar detenidamente en la pregunta que acaba de recibir. Como verá cuando se trata de problemas comerciales reales, siempre es mejor pensar primero en el problema y “perder” algo de tiempo para verlo desde todas las perspectivas. Recuerde, ¡pensar nunca es una pérdida de tiempo!

Estos pocos minutos darán sus frutos más tarde. Si se lanza inmediatamente a escribir la solución, es muy probable que tenga que empezar de cero una vez que se haya dado cuenta de que su enfoque no conduce a la solución deseada. O que constantemente tienes que cambiar y reescribir tu código.

Los puntos que te ayudarán a practicar el pensamiento sobre el problema son:

1. entender la pregunta
2. Analice las tablas y los datos con los que está trabajando.
3. Piensa en el resultado del código.

I. entender la pregunta

Para asegurarse de que entiende la pregunta, tendrá que leerla con mucho cuidado. Léelo despacio. Y léalo 2 o 3 veces para asegurarse de que no se perdió nada. Esto se aplica a todos preguntas de la entrevista de ciencia de datos, no importa lo fáciles o difíciles que sean. El punto es que no sabrás si la pregunta que tienes es difícil o fácil. Algunas de las preguntas pueden parecer engañosamente simples, pero tienen un truco que está ahí exactamente para eliminar a aquellos candidatos que no son lo suficientemente completos y tienden a ser superficiales.

Si la pregunta no está escrita, siéntase libre de pedirle al entrevistador que la repita si no entendió algo. En este caso, también es recomendable, una vez que entiendas la pregunta, repetirla al entrevistador. De esa manera, te asegurarás de que lo hiciste todo bien y permitirás que el entrevistador se corrija en caso de que no te haya dado toda la información necesaria.

ii. Analice las tablas y los datos con los que está trabajando

Una vez que entiendas la pregunta, el siguiente paso lógico es analizar las tablas que te dan. Esto significa que debe analizar cuántas tablas hay y cómo están conectadas entre sí (clave externa y clave principal).

También querrá ver qué datos hay en estas tablas. Es decir, qué columnas hay en cada tabla. Qué tipo de datos hay en cada columna. Esto es importante porque su código dependerá de si está manejando datos de cadena, enteros, dinero o cualquier otro tipo de datos. Tal vez incluso necesite convertir un tipo de datos a otro para obtener el resultado deseado.

Además del tipo de datos, también es importante comprender cómo se organizan, ordenan y granulan los datos. Es decir, ¿hay valores duplicados en la tabla? ¿Se presentan los datos a, digamos, nivel de cliente, nivel de transacción, etc.?

iii. Piense en el resultado del código

Antes de comenzar a codificar, debe saber cómo desea que se vea su resultado. Esto, por supuesto, también depende de la pregunta que quieras responder.

Pero pensando en los medios literarios del resultado, será solo un valor en una línea o una tabla con varias columnas. Si se trata de una tabla, nuevamente debe pensar en cómo se agregarán y ordenarán sus datos, cuántas columnas debe mostrar, etc.

 
Análisis de preguntas: ejemplo

Para mostrarle cómo se debe aplicar esta primera sección de la lista de verificación, usaremos la pregunta de codificación de Dropbox. La pregunta va así:

“Escribe una consulta que calcule la diferencia entre los salarios más altos encontrados en los departamentos de marketing e ingeniería. Salida sólo la diferencia en los salarios.

Enlace a la pregunta: https://platform.stratascratch.com/coding/10308-salaries-differences

Si lee atentamente la pregunta, se dará cuenta de que debe encontrar el salario más alto. Está bien, pero no el salario más alto en todos los departamentos, sino solo en dos departamentos: marketing e ingeniería. Una vez que encuentre el salario más alto en estos dos departamentos, debe calcular la diferencia entre ellos.

Ahora que comprende la pregunta, puede analizar las tablas y los datos en ellas. Las tablas con las que trabajará son db_employee y db_dept. La tabla db_employee contiene datos sobre los empleados de la empresa. Tiene cinco columnas:

Verá, las columnas de nombre son del tipo de datos varchar, mientras que el salario es un número entero. Podría ser importante saber que no hay decimales en los valores de los salarios. Si usa la opción de vista previa que tiene disponible aquí, verá que estos datos son únicos: cada empleado tiene solo un valor de salario asignado. Además, una cosa importante a saber; también podrían ser datos históricos en los que tendrá todos los salarios anteriores a lo largo de los años para cada empleado. Hay una columna department_id, que es una clave externa que vincula esta tabla con la tabla db_dept:

Sólo dos columnas en esta tabla. Es solo una lista de departamentos, sin duplicados, con seis departamentos que se muestran en la tabla.

Bien, has analizado los datos. Ahora, regrese a la pregunta y lea la segunda oración. Sí, esta es una instrucción sobre cuál debe ser su solución. No necesita mostrar el salario más alto de un departamento en una columna, luego el salario más alto del otro en la segunda columna y luego la diferencia entre ellos en la tercera columna. No, la salida será solo la diferencia:

No hubo instrucciones sobre el nombre que debería tener esta columna de salida. Así que no será un error lo que sea que lo llames o si no lo nombras en absoluto. Lo importante es que obtengas este resultado y nada más.

Con eso, tienes las bases para escribir un código de calidad. Ahora es el momento de la estrategia: ¿cómo escribirás un código?
 

2. Enfoque de la solución

 
Antes de comenzar a escribir un código, también es importante que tenga una idea clara de cómo se verá su código. La codificación solo debe traducir su idea (¡clara!) de la solución al lenguaje de programación.

Cuando piense en cómo debe abordar su solución (o escribir un código), considere lo siguiente:

1. ¿Hay varias formas de escribir un código?
2. Indique sus suposiciones
3. Divide tu solución en pasos
4. Empezar a codificar

I. ¿Hay varias formas de escribir un código?

Al pensar en la solución, lo primero que viene a la mente a veces es la mejor solución. Y a veces no lo es. ¿Como podrias saber? Una vez que tienes la primera idea, el truco es pensar si hay alguna otra forma de resolver el problema. En lenguajes de programación, la mayoría de las veces, hay varias soluciones posibles.

Tenga esto en cuenta. Hay varias razones por las que esto es importante. Primero, podría haber algún truco o función simple que resuelva fácilmente algo que piensa resolver con un código largo, por ejemplo, usando funciones de ventana o CTE en lugar de escribir un código con interminables subconsultas.

Elija siempre lo que sea más fácil de escribir, con la menor cantidad de líneas de código posible. Cuando estás en la entrevista, también tienes que administrar el tiempo a tu disposición. Esta es una de las formas.
Por supuesto, si hay varias soluciones más o menos igualmente complejas, piense en cómo funcionará el código. En grandes cantidades de datos, diferentes códigos pueden requerir mucho más tiempo y memoria que otros.

En resumen, debe pensar en la eficiencia del código de dos maneras. Uno es la eficiencia personal, o qué tan rápido puede escribir un código. El segundo es la eficiencia del código o qué tan rápido el código realizará lo que desea.

ii. Indique sus suposiciones

Expresar sus suposiciones es importante por varias razones. La primera es decirlas en voz alta y escribirlas, lo que te ayudará a ver posibles problemas con tu enfoque.

La segunda razón importante es que invita a su entrevistador a comunicarse con usted e incluso ofrecerle ayuda, lo que suele hacer. Si no saben lo que quieres hacer y por qué, no pueden ayudarte. Como ya mencionamos, suele haber varias soluciones que devuelven el mismo resultado. Comunicar sus suposiciones le permite al entrevistador guiarlo en la dirección correcta según el enfoque que elija. O incluso alejarlo de suposiciones completamente incorrectas que estropearán su solución.

La tercera razón es que, a veces, la pregunta podría configurarse intencionalmente para que sea vaga. Estas preguntas no tienen que ver con la solución correcta sino con cómo piensas. Entonces, si establece sus suposiciones, le mostrará al entrevistador cómo piensa, lo que generalmente les interesa mucho.

La cuarta y última razón para establecer sus suposiciones es que incluso si obtiene la respuesta completamente incorrecta pero correcta dentro de las suposiciones que estableció, es probable que aún obtenga algunos puntos por eso. El pensamiento, en este caso, gira en torno a estas líneas: OK, tal vez el candidato entendió completamente mal lo que se le preguntó, pero la solución es correcta dentro del contexto de lo que entendió.

Todo esto conduce a asegurarse de dar la respuesta correcta a una pregunta de la entrevista.

iii. Divide tu solución en pasos

Este también es un punto útil que le facilitará tener una idea clara de la solución y, más adelante, escribir un código limpio.

Descomponer, en este caso, significa escribir. Sí, anote todos los pasos y funciones clave de su solución. Piense si debe unir tablas, cuántas tablas y qué unión usará. ¿Deberías escribir una subconsulta o un CTE? Escriba su elección. Piense en qué funciones agregadas tendrá que usar, si tendrá que convertir tipos de datos, si los datos se ordenarán de una manera específica, si se filtrarán y agruparán, etc.

Todos estos son pasos distintos, así que anótelos, así como las principales palabras clave que usará en cada paso.

IV. Empezar a codificar

Este es un punto de emergencia, en cierto modo. Si pensó en su enfoque de la solución, pero simplemente no puede ver la solución completa ante sus ojos, entonces simplemente debe comenzar a escribir un código.

El pensamiento detrás de esto es que incluso si proporciona una solución incompleta, seguramente vale más que no escribir una sola línea de código. Además, algunas preguntas pueden ser realmente difíciles, y es difícil incluso para los más experimentados ver la solución completa de inmediato. Comience a codificar y existe la posibilidad de que se le ocurra una idea en el camino. Y si no, de nuevo, al menos tienes algo que mostrar.

Una razón adicional que debe tener en cuenta: algunas preguntas ni siquiera están destinadas a ser respondidas. Algunos de ellos son simplemente (¡e intencionalmente!) demasiado difíciles de resolver en el tiempo que se le da en la entrevista. Nadie los resuelve por completo. La solución parcial es la mejor que alguien obtendrá. Por lo tanto, se le marcará qué tan lejos llegó en comparación con las otras soluciones incompletas.

 
Enfoque de la solución: ejemplo

Ahora que sabe cómo debe pensar acerca de su enfoque de solución, usemos una pregunta de la entrevista para demostrar cómo funciona en la práctica. Usaremos la pregunta de la entrevista de codificación de Amazon:

“Encuentre el costo total de los pedidos de cada cliente. Muestra la identificación del cliente, el nombre y el costo total del pedido. Ordene los registros por el nombre del cliente en orden alfabético”.

Enlace a la pregunta: https://platform.stratascratch.com/coding/10183-total-cost-of-orders

Tendremos que usar datos de dos tablas, clientes de mesa y pedidos de mesa con esta pregunta. Podemos escribir un código con subconsultas para superar este problema. Sin embargo, probablemente sepa que si la consulta y la subconsulta usan datos de varias tablas, entonces la solución también podría escribirse usando JOIN. Teniendo en cuenta el consejo de escribir la menor cantidad de líneas de código posible, es mejor usar JOIN.

¿Cuáles son los supuestos de esta solución? Una suposición podría ser que puede haber clientes que no tengan pedidos. Esto significa que podría haber clientes en la mesa que no aparecerán en la mesa de pedidos. La segunda suposición es que no mostraremos los clientes con cero pedidos ya que la pregunta no lo decía explícitamente.

Ahora, esto ya nos lleva a un desglose de la solución. Tenemos que generar dos columnas ya existentes, por lo que seguramente usaremos SELECT. Necesitamos encontrar el total de los pedidos de cada cliente. Tendremos que sumarlo usando la función agregada SUM(). OK, las mesas tienen que estar unidas. Lo haremos usando la palabra clave JOIN. ¿Por qué no se une algún otro? Debido a que nuestra suposición dice que solo queremos clientes que tengan al menos un pedido. Usar JOIN nos dará exactamente eso: unirá dos tablas y encontrará solo los valores (clientes) que están en ambas tablas. ¿Qué sigue? He usado la función de agregado, así que tendré que usar GROUP BY. Y el resultado debe ordenarse alfabéticamente, así que usaré ORDER BY y ASC.

El desglose de la solución resultante podría verse así:

• SELECCIONAR
• SUMA (total_order_cost)
• ÚNETE
• GRUPO POR
• PEDIDO POR ASC

En su caso, esto no es una emergencia ya que entendió todo, por lo que puede pasar a la siguiente sección de la lista de verificación. O también puedes encontrar los más comunes SQL JOIN preguntas de la entrevista aquí.

3. Escribir un código

 
Después de evaluar la pregunta y diseñar la estrategia para su código, es hora de que comience a escribirlo.

1. Apégate a un dialecto elegido
2. Ir línea por línea al codificar
3. Habla mientras codificas
4. Hazlo legible
5. Sea consistente con las convenciones elegidas

I. Apégate a un dialecto elegido

Esto es especialmente importante si está en la entrevista de codificación SQL. Como ya sabe, existe un estándar ANSI/ISO SQL y hay muchos dialectos de SQL. Prácticamente todos los RDBMS usan su propio dialecto SQL. Por supuesto, no puedes conocerlos todos. Y la empresa para la que está entrevistando probablemente esté usando uno de esos dialectos.

Si al entrevistador no le importa qué dialecto usas, elige el que te resulte más cómodo. No intente atraer al entrevistador eligiendo el dialecto SQL que usa si no es muy bueno con la codificación en ese dialecto. Es mejor elegir el dialecto que mejor conoce y resolver el problema que usar otro dialecto del que no se sienta tan seguro. Si eliges el último, lo más probable es que estés más nervioso de lo necesario. Además, no estar tan familiarizado con el dialecto SQL en particular podría hacer que arruine la solución.

Una vez que elija el dialecto SQL, apéguese a él. Por ejemplo, si elige escribir en PostgreSQL, no lo mezcle con T-SQL.

ii. Ir línea por línea

Tener un desglose claro de la solución lo ayudará a verificar este punto casi desapercibido. Como ya tiene las funciones y las secciones de su código descritas, solo necesita mantener la calma y escribir un código siguiendo sistemáticamente el esquema de la solución. El código no es más que una versión en lenguaje de programación de tus pensamientos. Si sus pensamientos y el esquema de su solución son claros, su código también lo será.

Si comienza a saltar de una línea a otra, se confundirá a usted mismo y al entrevistador. Lo que probablemente conducirá a no escribir el código correcto.

iii. Habla mientras codificas

Mientras escribe su código línea por línea, también debe hablar sobre lo que está haciendo. Esto es importante porque cuando dices en voz alta lo que estás haciendo, es más fácil para ti ver si estás haciendo algo mal. Todo puede sonar genial en tu cabeza. Pero cuando lo expresas, ¡las ideas no tan geniales realmente sobresalen! Esto le da la oportunidad de corregir el código a medida que avanza. De lo contrario, podría terminar su código, sin siquiera darse cuenta de que hizo algo mal.

Una de las razones por las que es importante explicar cada línea a medida que la escribe es que nuevamente invita al entrevistador a participar en su solución. Les permite entender lo que estás haciendo y darte algunos consejos. Si solo escribe un código y se reserva lo que está haciendo, es probable que el entrevistador también se cierre y simplemente espere a que termine el código para informarle cómo lo hizo.

IV. Hazlo legible

Tener un código bien estructurado es un placer verlo simplemente desde el punto de vista estético. No solo eso, sino que hace que sea más fácil para usted y para el entrevistador leer su código.

Lo principal que hace que su código sea legible se menciona en uno de los puntos anteriores: escríbalo lo más simple posible. Sin embargo, algunas soluciones no pueden ser simples. E incluso unas pocas líneas de código podrían ser una pesadilla para leer si no hace un esfuerzo para que sea legible.

Uno de los consejos a tener en cuenta es usar espacio, tabulador e ingresar. ¡Y utilízalo mucho! Estas claves están ahí para separar su código en secciones, lo que facilita la comprensión de lo que hace el código. Piense en ello como cualquier cosa que diga o escriba. Espacio, tabulador e intro harán que su código tenga comas, oraciones y párrafos.

Si es posible, use alias para las tablas. Pero trate de que se expliquen por sí mismos. Evite usar alias de una sola letra, pero tampoco haga alias demasiado detallados y descriptivos. Lo mismo ocurre con los nombres de las variables.

Si bien SQL no distingue entre mayúsculas y minúsculas, siempre es mejor escribir las palabras clave de SQL en mayúsculas. Esto también hará que sobresalgan en el código, especialmente si todos los nombres de columnas y tablas están escritos en minúsculas.

Mira nuestra publicación “Mejores prácticas para escribir consultas SQL: cómo estructurar su código” que se enfoca en cómo se pueden mejorar sus consultas SQL, en particular cuando se trata de rendimiento y legibilidad.

v. Sea coherente con las convenciones elegidas

No hay reglas que te obliguen a escribir en mayúsculas o minúsculas; no hay una convención de nomenclatura prescrita, por lo que depende de usted y de cómo le guste. Pero hagas lo que hagas, sé coherente con ello.

Si desea escribir todos los nombres de las columnas nuevas en minúsculas y separar las palabras con guiones bajos, hágalo y manténgalo así. Nombrar una columna de salario_por_empleado se ve bastante bien. Pero trate de evitar nombrar una columna de salario_por_empleado, la otra SalaryPerDepartment, la tercera 'Total Salary' y la cuarta MAX_sALAryPerdeparment. Te harás daño al intentar leer el código, especialmente con el último.

Lo mismo ocurre al escribir nombres de tablas, usar alias, etc. Mantener la coherencia también aumentará la legibilidad de su código.

Hablando de consistencia, le mostraremos cómo funciona esta sección de lista de verificación en la práctica.

 
Escribir un código – Ejemplo

Aquí hay una pregunta de codificación de Facebook:

“Facebook envía mensajes de texto SMS cuando los usuarios intentan 2FA (autenticación de 2 factores) en la plataforma para iniciar sesión. Para poder iniciar sesión con éxito en 2FA, deben confirmar que recibieron el mensaje de texto SMS. Los textos de confirmación solo son válidos en la fecha en que fueron enviados. Desafortunadamente, hubo un problema de ETL con la base de datos donde se insertaron solicitudes de amistad y registros de confirmación no válidos en los registros, que se almacenan en la tabla 'fb_sms_sends'. Estos tipos de mensajes no deben estar en la tabla. Afortunadamente, la tabla 'fb_confirmers' contiene registros de confirmación válidos, por lo que puede usar esta tabla para identificar los mensajes de texto SMS que fueron confirmados por el usuario.

Calcule el porcentaje de mensajes de texto SMS confirmados para el 4 de agosto de 2020".

Enlace a la pregunta: https://platform.stratascratch.com/coding/10291-sms-confirmations-from-users

Si escribe un código como este, cubrirá todo lo que mencionamos en esta sección de la lista de verificación:

SELECT cust_id, SUM(total_order_cost) AS revenue
FROM orders
WHERE EXTRACT('MONTH' FROM order_date :: TIMESTAMP) = 3 AND EXTRACT('YEAR' FROM order_date :: TIMESTAMP) = 2019
GROUP BY cust_id
ORDER BY revenue DESC

Imaginemos que Facebook usa SQL Server, pero deja que usted elija en qué dialecto SQL escribirá su código. No está familiarizado con T-SQL, por lo que decide escribir en PostgreSQL.

Por ejemplo, EXTRACT() y dos puntos dobles (::) son funciones típicas de PostgreSQL. El primero extrae la parte de la fecha del tipo de datos datetime. ¡No existe en T-SQL! Entonces, si le dice al entrevistador que está escribiendo en T-SQL y luego usa esta función, estaría cometiendo un error. En T-SQL, debe usar la función DATEPART(). Y debes saber que esta función en PostgreSQL se llama DATE_PART(). Un guión bajo podría significar una diferencia entre que su código funcione y no funcione.

De manera similar, los dos puntos dobles (::) en PostgreSQL se usan para la conversión de tipos de datos. En T-SQL no funciona; tendrá que usar CAST() o CONVERT().

Tener un desglose de la solución para este código le facilitará escribirlo línea por línea. Es fácil, en realidad. Primero, debe seleccionar algunos datos de una tabla, filtrarlos, agruparlos y finalmente ordenarlos. No escriba primero la cláusula WHERE, luego vaya a la declaración SELECT, luego a la conversión de tipo de datos o cualquier otra forma extraña de abordar su código.

Mientras codifica, podría hablarle al entrevistador de esta manera: Estoy seleccionando la columna cust_id usando la función SUM() para calcular los ingresos de los pedidos de mesa. Luego estoy usando la cláusula WHERE para filtrar datos según el mes y el año de la columna order_date. Después de eso, estoy agrupando datos a nivel de cliente y ordenando el resultado en orden descendente.

Verá que hay una sangría en este código, hay una nueva línea para cada parte clave del código y las convenciones de nomenclatura son consistentes. ¿Quieres ver cómo se vería el código si no siguiéramos esto? Aquí está:

SELECCIONE cust_id,SUM(total_order_cost) COMO INGRESOS DE PEDIDOS WHERE EXTRACT('MES' FROM order_date :: TIMESTAMP) = 3 AND EXTRACT('YEAR' FROM order_date :: TIMESTAMP) = 2019 GROUP BY cust_id order BY Revenue DESC

¡Buena suerte con la lectura!

4. Revisión de su código

 
Una vez que haya escrito el código, es hora de que lo revise antes de que se convierta en su respuesta final. Si ha seguido todos los elementos de una lista de verificación hasta el momento, le resultará fácil revisarla.

Revisar su código es, en cierto modo, compararlo con algunos puntos de su lista de verificación:

1. Consulta cuánto tiempo te queda
2. Compruébelo con la salida requerida
3. Compruébelo con las suposiciones establecidas.
4. Comprueba su legibilidad
5. Guíe al entrevistador a través de la solución.
6. Optimiza tu código

I. Compruebe cuánto tiempo le queda

Todos los demás puntos en esta parte de la lista de verificación dependen de este. Si no te queda tiempo, entonces no puedes hacer nada. Hiciste lo que hiciste, y tu código es la respuesta que tienes, te guste o no.

La administración del tiempo es importante, por lo que debe dejar tiempo intencionalmente para revisar un código. Idealmente, tendrá tiempo para realizar las siguientes tres comprobaciones.

ii. Verifique el código contra la salida requerida

Debe volver a su pregunta y ver si su código realmente devuelve lo que se requiere. ¿Olvidaste incluir algunas columnas obligatorias? ¿Realmente ordenaste el resultado como se solicitó? Esas y otras preguntas similares son las que debes hacerte.

Si tienes tiempo, corrige los errores que cometiste. Si no hay tiempo, deja el código como está, pero escribe lo que hiciste mal.

iii. Verifique el código contra las suposiciones establecidas

Escribiste tu código basado en algunas suposiciones. Regrese a su lista de suposiciones y verifique si las siguió.

Sería perfecto si lo hicieras. Pero al escribir código más complejo, es posible que haya descartado algunas suposiciones o introducido otras nuevas. Escríbalo también. Si no siguió todas las suposiciones, pero cree que debería haberlo hecho y tiene tiempo para cambiar el código, hágalo. Si no, déjalo como está.

IV. Comprobar la legibilidad del código

Aquí debe comprobar si entiende lo que acaba de escribir. Regrese a su código, verifique una vez más cada línea por su sintaxis y lógica. A medida que avanza línea por línea, evalúe si se puede mejorar la legibilidad del código. ¿Fuiste consistente en las convenciones de nombres? ¿Son sus alias claros de entender? ¿Hay alguna ambigüedad? ¿El código está estructurado de forma lógica y en partes lógicas?

Nuevamente, si tiene tiempo, mejore la legibilidad del código. Si no hay tiempo, trata de escribir o simplemente recuerda lo que podrías haber hecho mejor.

v. Guíe al entrevistador a través de la solución

Si realizó todos los pasos anteriores, este debería ser algo natural para usted. Lo más importante es que seas honesto cuando expliques tu código.

Independientemente de los errores que haya encontrado en su código al revisarlo, indíquelos explícitamente. No cuente con que su entrevistador no los note. No intentes ocultarlos. Sé dueño de tus errores y demuestra que sabes lo que hiciste mal. Todo el mundo comete errores, pero no todos pueden darse cuenta de que los cometieron y admitirlos. Demuestra que sabes lo que estás haciendo a pesar de que cometiste un error. Hablando de errores, Estas son las más comunes que la gente hace en las entrevistas de ciencia de datos..

Si incluyó una columna innecesaria en su salida, dígalo y continúe explicando la salida que tiene. ¿Se desvió de sus suposiciones iniciales o incluyó otras nuevas? Dilo y explica por qué. Si lo hizo por error, diga que no fue intencional, pero verá que su solución debe incluir algunas suposiciones adicionales. Indique cuáles deberían ser para que su código funcione. Lo mismo ocurre con la legibilidad: si ves que puedes mejorar tu código, explica cómo.

Al hacer todo esto, no solo mostrará su capacidad de codificación, sino también qué tan rápido piensa, que es responsable y honesto. Todas estas son características muy apreciadas por todas las empresas.

vi. Optimice su código

La última pregunta en la entrevista de codificación suele ser la que le pide que optimice su código. De esa manera, el entrevistador pondrá a prueba su conocimiento de la teoría SQL. Por ejemplo, si sabe que los JOIN pueden consumir mucho tiempo computacionalmente. Se le pedirá que averigüe si hay una forma de eliminar JOIN o una subconsulta. Por ejemplo, normalmente puede eliminar una subconsulta en la cláusula WHERE con alguna función, como la función de clasificación, si intenta encontrar el valor máximo.

O si sabe qué tan rápido se realizan las operaciones en ciertos tipos de datos. Por ejemplo, la comparación de cadenas es más lenta que la comparación de enteros, así que tal vez haya una forma de hacerlo con datos de cadenas.

Conclusión

 
Todo esto se resume en esto: escribir un código debería ser casi un tecnicismo si estructura bien su enfoque. El acento está más en el pensamiento y menos en la codificación. Y escribir un código debe hacerse de una manera muy organizada.

Debe pensar en la pregunta, los datos que tiene frente a usted, las posibles soluciones, sus suposiciones y las funciones que necesitará. Solo después de eso, debes comenzar a codificar. Una vez que comience a codificar, debería poder incluir al entrevistador en lo que está haciendo y hacerle saber cada paso que da. Como en la vida real, deberá verificar y optimizar su código antes de comenzar a usarlo en producción. Esta entrevista es tu producción; administre su tiempo para que pueda revisar su solución.

Estas son las cosas que debes hacer. También hay más consejos de preparación en nuestra publicación: 5 consejos para prepararse para una entrevista de ciencia de datos.

Todo esto no es fácil. Requiere experiencia y práctica; nadie puede fingir esto. Pero seguir esta lista de verificación seguramente agregará una estructura sólida a su pensamiento y desempeño de la entrevista, sin importar su experiencia. Solo puede hacer que te desempeñes mejor.

 
 
Nate Rosidi es científico de datos y en estrategia de producto. También es profesor adjunto de enseñanza de análisis y es el fundador de StrataScratch, una plataforma que ayuda a los científicos de datos a prepararse para sus entrevistas con preguntas de entrevistas reales de las principales empresas. Conéctate con él en Gorjeo: StrataScratch or Etiqueta LinkedIn.

Original. Publicado de nuevo con permiso.

Fuente: https://www.kdnuggets.com/2022/01/answer-data-science-coding-interview-questions.html