Proceso de selección en empresas para desarrolladores (p.e. Tuenti)

[^MiSaTo^]

Pese a quedar como inculto... ¿Que es un algoritmo A*?

De hecho el enunciado dice que es un programa para iPhone, pero me dijo la chica que lo hiciera para Android (evidentemente, porque mi prueba era para Android).

¿Me dijiste que SI pasaste esta prueba, no? A mi me han dicho que el resto ya son entrevistas por teléfono...

Por lo que vi en la uni (na) y en el curso de AI de Stanford (un cacho) es un algoritmo de búsqueda, pero yo normalmente lo he visto más en espacios físicos (pathfinding). Supongo que también será aplicable a grafos, Misato es una jefa del código y sabrá más xD

Efectivamente es un algoritmo de búsqueda muy usado en IA (especialmente en videojuegos). http://es.wikipedia.org/wiki/Algorit...C3%BAsqueda_A*

Sí pasé esa prueba y tuve más de código, que eran a mi parecer más complejas que esta.

Mi madre me ha hablado alguna vez de el hijo de una compañera suya de trabajo que está trabajando en Holanda haciendo aplicaciones móviles, no será alguno de ellos

Si se llama Antonio, puede que sea el mismo Eso sí, hace tiempo que ya no está en Holanda ni en Madrid, ahora está en Berlín.

[pakoito]

Efectivamente es un algoritmo de búsqueda muy usado en IA (especialmente en videojuegos). http://es.wikipedia.org/wiki/Algorit...C3%BAsqueda_A*

¡Pero explica cómo lo aplicaste a este caso, coñe!

[^MiSaTo^]

¡Pero explica cómo lo aplicaste a este caso, coñe!

Pues apliqué el algoritmo para buscar la conversión más rápida de las monedas. Si esque esa es la única "dificultad" del ejercicio, que la conversión no es directa y tienes que ir mirando uno por uno en la lista a ver si la moneda tiene o no conversión y a cual. Eso es el único algoritmo que había que hacer, porque el resto del assigment es trivial.
Entonces la manera de hacer eso (que a mi se me ocurrió) era o bien un algoritmo recursivo normal o el A*. Elegí el A* porque es era más óptimo y recordemos que es una aplicación para un movil con escasos recursos y la recursividad es de lo más costoso (aparte del brutal consumo de memoria porque los ficheritos no son pequeños y las conversiones son "complejas").
Ayer estuve buscando pero no tengo el código por aquí Por haberos puesto el algoritmo si os daba curiosidad

[firesign]

Pues apliqué el algoritmo para buscar la conversión más rápida de las monedas. Si esque esa es la única "dificultad" del ejercicio, que la conversión no es directa y tienes que ir mirando uno por uno en la lista a ver si la moneda tiene o no conversión y a cual. Eso es el único algoritmo que había que hacer, porque el resto del assigment es trivial.
Entonces la manera de hacer eso (que a mi se me ocurrió) era o bien un algoritmo recursivo normal o el A*. Elegí el A* porque es era más óptimo y recordemos que es una aplicación para un movil con escasos recursos y la recursividad es de lo más costoso (aparte del brutal consumo de memoria porque los ficheritos no son pequeños y las conversiones son "complejas").
Ayer estuve buscando pero no tengo el código por aquí Por haberos puesto el algoritmo si os daba curiosidad

A mi la verdad es que me sorprendió encontrarme algo como eso. Es cierto que es la única "dificultad" del ejercicio, pero me esperaba más algún ejercicio sin tener que meter ese tipo de conocimiento teórico-práctico, más del tipo de cosas como las que también solicitaban, que no era más que demostrar que sabes:
- acceder a datos de red
- parsear JSON o XML
- realizar tareas en segundo plano sin bloquear la UI
Vamos, cosas típicas de programación de móviles, y no aplicar un algoritmo que se da en primero de carrera (yo ni me acuerdo de cuando estaba allí), que no he tenido que usar nunca más en mi vida, y aparte de ayer, no creo que tenga que volver a usar en lo que me queda.

Yo había visto en entrevistas que habían hecho a gente de RRHH de Tuenti que utilizan esta primera prueba de código para quitarse de enmedio a gente que dice ser programador pero que después no son capaces de escribir una línea de código por si solos cuando se les exige algo con urgencia. Pero no me pareció ese tipo de prueba, la verdad.

[^MiSaTo^]

Jodo pues yo sí he usado muchísimas veces recursividad. Ya no el A* en concreto (que es sólo uno de los mil algoritmos de búsqueda recursivos que hay), sino la recursividad en general, que me parece importante que sepas hacerlo bien y más en un chisme que tiene a lo mejor 50MB de memoria libres para tu app.
Quizá como primera prueba es algo excesiva, pero vamos a mi tampoco me pareció de una complejidad extrema ni mucho menos.
De todos modos como he dicho mi solución fue con el A* porque es el primero que se me vino a la cabeza, pero estoy segurísima de que hay otras muchas más formas de resolverlo. Eso sí, no se me ocurre ninguna sin usar recursividad xD

PD: quizá a mi no me pareció tan extraño el assigment porque estoy acostumbrada a currar fuera, y aquí es común hacer pruebas de este tipo para entrar a currar en cualquier empresa medianamente importante.

[Eskema]

Como curiosidad en esa prueba, ¿te dejan usar frameworks?, por ejemplo ¿el jsontal y cual para descargar?.... esto lo digo porque recuerdo una empresa que me hizo una entrevista (que no pasé) y me pedian varias funciones que el SDK de iphone trae , algo como [myimagen loadimage:ruta]; pero ellos querian que me currara la función a pelo para demostrar que sabia manejar coregraphics y como cargar una imagen, moverla por los buffers y demas cosas "chulas".

[dardo]

A mi la verdad es que me sorprendió encontrarme algo como eso. Es cierto que es la única "dificultad" del ejercicio, pero me esperaba más algún ejercicio sin tener que meter ese tipo de conocimiento teórico-práctico, más del tipo de cosas como las que también solicitaban, que no era más que demostrar que sabes:
- acceder a datos de red
- parsear JSON o XML
- realizar tareas en segundo plano sin bloquear la UI
Vamos, cosas típicas de programación de móviles, y no aplicar un algoritmo que se da en primero de carrera (yo ni me acuerdo de cuando estaba allí), que no he tenido que usar nunca más en mi vida, y aparte de ayer, no creo que tenga que volver a usar en lo que me queda.

Yo había visto en entrevistas que habían hecho a gente de RRHH de Tuenti que utilizan esta primera prueba de código para quitarse de enmedio a gente que dice ser programador pero que después no son capaces de escribir una línea de código por si solos cuando se les exige algo con urgencia. Pero no me pareció ese tipo de prueba, la verdad.

Son ellos los que están sondeando, pueden pedir cualquier cosa. Seguramente estén buscando talentos, más que nada por fichar a algunos que sean un poco máquinas y por cada uno de esos quitar a dos. o poder ofrecer un sueldo de junior a algún máquina.

Otra cosa es que te apuntes a la oferta, que pedirán lo de la oferta, aunque se ven cosas muy extrañas a veces. Yo en perfiles de desarrollo no estoy puesto, pero una vez me llamaron de una oferta de administrador de sistemas en la que pedián además de administración AIX un poquito avanzada, con temas de tunning y solución de problemas a alguien con experiencia administrando sistemas de archivos GPFS, que supiera de CICS y MQseries y además WebSphere. No es muy raro, son cosas que se suelen montar más sobre AIX que sobre otros *nix, porque al fin y al cabo son productos de IBM, pero pedían conocimientos de administración de todos esos productos con un sueldo de Junior. Evidentemente me autodescarté, porque aunque he tocado esos temas no me considero administrador avanzada (ni no avanzado) de algunos de esos productos. Por ejemplo no se mirar en detalle problemas graves de configuración de MQ, por ejemplo para WebSphere suelen pedir conocientos avanzados de j2ee para saber por qué la aplicación web o el webservice de marras tiene un mal rendimiento... y cosas de esas. Lo único que se les había olvidado pedir es administración DB2, por ir a por el "IBM big combo". Yo creo que esas ofertas de "administrador de todo" es para encontrar a alguien lo más competente posible que cobre lo menos posible, porque son perfiles poco realistas, que nadie de menos de 45 años podría cumplir, más que nada porque no hay tiempo material para dominar tantas cosas. Conozco administradores Senior con una granja de más de cien servidores que todavía se sorprenden y ven algo nuevo de vez en cuando.

[Eskema]

Son ellos los que están sondeando, pueden pedir cualquier cosa. Seguramente estén buscando talentos, más que nada por fichar a algunos que sean un poco máquinas y por cada uno de esos quitar a dos. o poder ofrecer un sueldo de junior a algún máquina.

La mayoria de empresas hoy dia buscan gente muy cualificada, gente "normalita" no les vale salvo que esten muy desesperados, y buscan entre la maleza para encontrar a un john carmack to makinote que sepa hacer de todo. A mi no me parece mal ese planteamiento, y al menos en el resto de paises ofrecen un sueldo digno para eso que piden (aunque van a la baja en todos)

[^MiSaTo^]

Como curiosidad en esa prueba, ¿te dejan usar frameworks?, por ejemplo ¿el jsontal y cual para descargar?.... esto lo digo porque recuerdo una empresa que me hizo una entrevista (que no pasé) y me pedian varias funciones que el SDK de iphone trae , algo como [myimagen loadimage:ruta]; pero ellos querian que me currara la función a pelo para demostrar que sabia manejar coregraphics y como cargar una imagen, moverla por los buffers y demas cosas "chulas".

Creo recordar que en mi caso no (salvo para el parseo que te recomendaban usar TBXML creo), pero esque tiene lógica, hacer una llamada a un webservice es algo trivial desde el SDK. Si no sabes ni hacer eso apaga y vámonos.
En tu caso pues ya no se, pero en el caso de este assigment lo veo lógico.

[Eskema]

obviamente usar el nsurlconnection no es nada del otro jueves, pero me refería mas a el hecho de usar cosas que no existen en el sdk y son comunmente usadas como el tbxml o el yljson. Porque si te piden que te hagas tu propia funcion para leer xml o json entonces apaga y vamonos. Estara bien saber hacer eso, pero no veo que a dia de hoy te vayas a poner a perder el tiempo para crear/usar tu libreria cuando el tbxml es usar y listo (por poner un ejemplo).

De todas maneras por usar el ejemplo que me has puesto de un webserver, supongamos que en el sdk de IOS viene una funcion [ulrObject connectToWebserver:urlToconnect withParameters:username&password];, me parece un poco chorra que me digas, no uses eso, currate a pelo la llamada para que veamos lo que sabes de programar. Pues me parece algo ridículo, si el puesto es para programar en IOS doy por sentado que vamos a usar el sdk, no a reinventar la rueda aqui con funciones propias. Salvo que me digas que sois una empresa que todo lo haceis en C/C++ y entonces hay que traducir todo el sdk a cosas nativas en C/C++ y por ello necesitais de esos conocimientos (he visto ese caso).

[pakoito]

Pues apliqué el algoritmo para buscar la conversión más rápida de las monedas. Si esque esa es la única "dificultad" del ejercicio, que la conversión no es directa y tienes que ir mirando uno por uno en la lista a ver si la moneda tiene o no conversión y a cual. Eso es el único algoritmo que había que hacer, porque el resto del assigment es trivial.
Entonces la manera de hacer eso (que a mi se me ocurrió) era o bien un algoritmo recursivo normal o el A*. Elegí el A* porque es era más óptimo y recordemos que es una aplicación para un movil con escasos recursos y la recursividad es de lo más costoso (aparte del brutal consumo de memoria porque los ficheritos no son pequeños y las conversiones son "complejas").
Ayer estuve buscando pero no tengo el código por aquí Por haberos puesto el algoritmo si os daba curiosidad

A mi en la implementación de estos lo que me cuesta es elegir la heurística, ¿cuál sería el H en este caso?

[ZeNiTRaM]

Problema principal: no había forma humana de descargar los datos JSON desde las direcciones que ellos me pasaron. Al menos, con código Java en Android. He probado 15 formas diferentes, muchas de ellas que las tengo usadas en mis programas, y no bajaban absolutamente nada. Si apuntaba a cualquier otro sitio, conseguía descargar los datos sin problemas, fueran cuales fueran, pero de las direcciones que ellos me pasaron nada. Eso sí, desde el ordenador, los podía descargar: si accedía con un navegador web, salían en XML. Si accedía mediante un "curl", salían en JSON. Si accedía mediante "wget", salían en XML... Seguro que tienen hecho algo extraño que en función de quien acceda a los datos salen en un formato u otro, y esto estaba provocando que con el código Java fuera imposible bajarlos. En serio, probé todas las formas existentes (que son tremendamente simples, pero no había forma). Con esto perdía una hora y cuarto... Al final los baje con un "curl" en el ordenador, los subí a mi página web personal, y cambié el programa para que los bajara de allí (se lo expliqué en un correo a la que contactó conmigo para la prueba).

Creo que esto era por la cabecera HTTP "Accept": http://shiflett.org/blog/2011/may/the-accept-header
Probablemente las librerias que tuvieras no la mandaban o mandaban algo raro y la API REST que te daba los datos se hacía la picha un lío y no te daba nada, el navegador es normal que acepte XML (para páginas con XSL por ejemplo) y lo mismo con Wget. Tenías que forzar a que mandara: Accept: application/json.

Si se llama Antonio, puede que sea el mismo Eso sí, hace tiempo que ya no está en Holanda ni en Madrid, ahora está en Berlín.

Vale, pues no es el que decía mi madre.. sino mi vecino de al lado. Esto confirma que Almería es un pañuelo.

[swapd0]

Yo creo que hubiera precalculado las conversiones, ¿cuantas monedas puede haber? ¿10 como mucho? pues con una matriz de 10x10 y asunto resuelto. Se precalculan al iniciar la aplicacion y despues la conversion es directa.

[ZeNiTRaM]

Yo creo que hubiera precalculado las conversiones, ¿cuantas monedas puede haber? ¿10 como mucho? pues con una matriz de 10x10 y asunto resuelto. Se precalculan al iniciar la aplicacion y despues la conversion es directa.

Pero estás en las mismas: para eso tienes que saber el cómo llegar de moneda X a moneda Y, aunque sólo sea para precalcularlo.

aunque teniendolas en una tabla creo que sí que puedes hacerlo así:
-llenas la tabla con las conversiones que tienes
-y mientras que la tabla no esté llena, aplicas las conversiones que ya hay en la tabla para generar las que falten

Creo que no llevaría demasiadas iteraciones, aunque puede que alguna de las conversiones de demasiadas vueltas innecesarias que le hagan perder precisión.

[firesign]

Como curiosidad en esa prueba, ¿te dejan usar frameworks?, por ejemplo ¿el jsontal y cual para descargar?.... esto lo digo porque recuerdo una empresa que me hizo una entrevista (que no pasé) y me pedian varias funciones que el SDK de iphone trae , algo como [myimagen loadimage:ruta]; pero ellos querian que me currara la función a pelo para demostrar que sabia manejar coregraphics y como cargar una imagen, moverla por los buffers y demas cosas "chulas".

Te dejaban usar solo librerías de terceros para el parseo de JSON, pero ponía que mejor no usarlas para nada.

-----Actualizado-----

Creo que esto era por la cabecera HTTP "Accept": http://shiflett.org/blog/2011/may/the-accept-header
Probablemente las librerias que tuvieras no la mandaban o mandaban algo raro y la API REST que te daba los datos se hacía la picha un lío y no te daba nada, el navegador es normal que acepte XML (para páginas con XSL por ejemplo) y lo mismo con Wget. Tenías que forzar a que mandara: Accept: application/json.

No usaba ninguna librería para bajar los datos. Simplemente los bajaba de la forma típica, habiendo la conexión, usando un stream, y mediante un vuele mientras hubiera datos. Probé a bajar JSON y XML de otros servicios web y los bajaba de lujo. Pero del que ellos me habían pasado no había manera...

-----Actualizado-----

Jodo pues yo sí he usado muchísimas veces recursividad. Ya no el A* en concreto (que es sólo uno de los mil algoritmos de búsqueda recursivos que hay), sino la recursividad en general, que me parece importante que sepas hacerlo bien y más en un chisme que tiene a lo mejor 50MB de memoria libres para tu app.
Quizá como primera prueba es algo excesiva, pero vamos a mi tampoco me pareció de una complejidad extrema ni mucho menos.
De todos modos como he dicho mi solución fue con el A* porque es el primero que se me vino a la cabeza, pero estoy segurísima de que hay otras muchas más formas de resolverlo. Eso sí, no se me ocurre ninguna sin usar recursividad xD

PD: quizá a mi no me pareció tan extraño el assigment porque estoy acostumbrada a currar fuera, y aquí es común hacer pruebas de este tipo para entrar a currar en cualquier empresa medianamente importante.

Evidentemente todos hemos usado la recursividad montones de veces, y seguiremos haciéndolo. A lo que me refiero yo es al A* o similares. Eso si que no he tenido que usar nunca y me cuesta pensar en un caso practico real que pueda presentarseme en el que lo necesite.

Si tienes que hacer algo en la realidad para convertir monedas (o medidas o lo que sea) al final lo harás usando algún tipo de servicio que te haga la conversión o que te de el cambio directamente...