Más fácil que FizzBuzz

Me salió a la primera y me tardé menos de un minuto. Está buena la pregunta, luego les digo por qué.

Lo que está muy bueno es la correlación entre el tiempo que se quejan de su chamba y el tiempo que les toma resolver el problema. No necesariamente significa algo, pero ciertamente está interesante.

Yo tardé menos de un minuto y funcionó con el primer intento, aunque el compilador en línea se tardó algunos segundos en compilar y ejecutar... :-P

01:07, contando la ejecución en línea de comandos.

creo que me demore menos de 30 segundos en pensar la solución , no lo he realizado supongo que escribiéndola hubiera sido un minuto a minuto y medio , como dato se me ocurrio usar un menos dentro del for.. , alguno uso otra forma??

Igual use una resta tarde como 3 minutos con todo y código, a lo mejor había otras soluciones pero elegí la primera que vino a mi mente.

No me gusta pero también lo hace:

Con una pequeña modificación:

Pero solo imprime del 99 hacia atras, si cambiamos el for ya lo hace desde el 100

Aunque aún así no me acostumbro a ver sentencias distintas a operaciones y declaraciones dentro de la sintaxis del for, tal vez porque casi nunca las veo.

hay dos formas de hacer la resta, esta es otra  

Solo por curiosidad de ver si se podía o no usar un closure, y quedo algo así:

¿99? Mea culpa >.<

Correcto, se puede poner la sentencia en el for, pero ¿porque lo harías? es terrible. Si, me tardé 2:07 en abrir el editor, escribir el public bla bla, pensar en la solución ( como 30s ) , hacerle una ejecución mental? (no quería hacerlo en dos intentos por el 99 , 0 etc. y listo, pare el cronómetro en 2:07

Obvio es muy sencillo, es como una pregunta de entrada, el artículo dice que hay quién no lo puede resolver ( por N razones ). Si alguien no lo resuelve en un tiempo considerable y se queja mucho, vale la pena continuar la entrevista? Habríamos perdido a jpaul aquí porque escribía 99?

No es lo mismo evaluar a alguien por algo tan pequeño como esto, ( o por preguntas meramente teóricas ), es muy difícil. En donde estoy me dejaron un proyecto sencillo, pero completo, de 16 hrs máximo, ( lo hice en 20 ) y dice que máximo porque le puedes seguir poniendo más y más features sin parar, y menos de 16 hrs. lo dejarías muy básico y con eso se evaluaba al candidato.

Desafortunadamente lo tuvimos que quitar porque ese proceso tomaba mucho tiempo y nos ganaban mucho candidatos buenos.

He aquí mi solución original:

Jajaj ok entonces si pasas a la segunda pregunta.... oh, un momento, sin llaves después del for?

;) ;)

:'(

Correcto, se puede poner la sentencia en el for, pero ¿porque lo harías? es terrible.

Intencionalmente la coloque (deducí que no la debo de usar porque esta puede formar parte del bloque de código del for y si hablamos de legibilidad de código, algunos o varios podrían tardarse en interpretarlo ), y si fuera el caso con un reclutador cuando menos preguntaría cuales preguntas falle y porque falle, no me quedaría con el puesto pero cuando menos algo aprendería.

No es lo mismo evaluar a alguien por algo tan pequeño como esto, ( o por preguntas meramente teóricas ), es muy difícil

La mayoria de las veces los reclutadores como no son gente del área, pues ni lo teórico preguntan (he visto a varios reclutadores), cuando menos con algo básico puedes evitar tener una papa caliente.

vale la pena continuar la entrevista? Habríamos perdido a jpaul aquí porque escribía 99?

Yo he entrevistado gente, y no es que yo tenga mucho conocimiento, pero la realidad es que no confiaron en los reclutadores por lo que ya mencione anteriormente, yo si continuaria la entrevísta aunque se tardarán más de 10 minutos, siempre y cuando la resolvieran, y tampoco descartaría a jpaul podría ser que por el afan de hacer algo rápido por la presión se descuido, y si tal vez digan pero si asi se descuido como confiarias en algo que haga para un entorno productivo, y pues como siempre contestaría somos humanos y todos cometemos errores algún día, eso si se vigilaría más el trabajo de estas personas al principio.

esta si no se quien se atreva a escribir los 100 números , pero es una solución no?
pasándole lista de argumentos en el comando :
java M 100 99 98 97 96 .........0
 

Ya que usaste un varargs (argumento variadico) y son bastantes números, digo suena algo enfermo (no digo que tu solución lo sea) añadir miles o tal vez millones de argumentos pero solo por curiosidad investigue cuantos permitiría y encontre que sería el limite de tamaño de un arreglo, lo cual varia de virtual machine en virtual machine:

limit size of arrays

El sentido de mostrar otras soluciones, denota conocimiento del lenguaje y creatividad, tal vez el reclutador este buscando estas características tambien.

… y tampoco descartaría a jpaul podría ser que por el afan de hacer algo rápido por la presión se descuido …

La pregunta es buena para ver si el entrevistado sabe las idiosincrasias de algún lenguaje de programación:

O bien para determinar que tanto tiempo le gusta perder en un ciclo for...

y pasar con el siguiente entrevistado ;-)

El sentido de mostrar otras soluciones, denota conocimiento del lenguaje y creatividad, tal vez el reclutador este buscando estas características tambien.
si ante una pregunta el entrevistado te muestra varias opciones explicando ventajas y desventajas entre una y otra , es necesario seguir preguntando? alguien que sabe se nota al instante por su manera de responder expresarse y rebatir con conviccion .
a mi me toco un entrevistador que queria ejecutar mi .war dandole doble click......pfff
en cuanto al codigo de @Antonio Hernand no lo entendi pero me hizo acordar una funcion recursiva y aqui mi ultima solucion :
 

Hola @Antonio, considero que tu código tiene un exceso de complejidad innecesaria, usar el   como una especie de   no es una buena idea, incluso si te obligaran a usarlo así, podrías escribir algo un poco menos complejo, p.e.:
 

No considero que usar funciones recursivas en JavaScript sea mala idea, pero debes tener mucho cuidado en los escenario que eliges para ese tipo de tareas. Echale un ojo a esto

Por otro lado, la misma curiosidad de una función anónima dentro del   en JS:
 

Saludos.

Se clavan mucho en el código. Yo creo que la pregunta es útil no tanto por el código que la persona escriba, sino por ver el proceso por el cual llega a esa línea o dos líneas que escriba. Para mi, la mejor respuesta sería:

Y ya. Sin cosas rebuscadas, código bien escrito, que hace lo que tiene que hacer, no es rebuscado, y ya.

Nuevamente, esto que sigue es mi opinión muy personal:

¿Por qué es importante que lo escriba en menos de dos minutos? Porque el problema es bastante simple y la neta si no encuentran la solución rápido ps ni al caso continuar. Oscar puede hacerse el mártir todo lo que quiera pero en la entrevista seguramente nadie va a contar el tiempo que se tarde en abrir el editor de su preferencia, o en compilar el código, porque el entrevistador ya se sabe las pocas respuestas aceptables y ni siquiera es necesario compilarlo (o pueden usar algo tipo groovyConsole para compilarlo y ejecutarlo rápido y simple).

¿Por qué es importante que lo hagan bien a la primera? Cualquier programador se puede poner a teclear soluciones y probarlas hasta encontrar una que funcione. Eso es un code monkey. Gracias por participar, pero no gracias. Un buen programador le piensa un rato, y luego escribe el código. Para un problema tan simple, sí espero que lo puedan escribir bien a la primera; es muy importante que primero piensen lo que van a hacer, y luego lo hagan. Qué tal si eso de escribir código nomás para ver si jala lo hace siempre, ya en proyectos reales? Alguien va a tener que mantener ese código. Que si tal vez lo hagan mal por la presión de la entrevista, pues sí, pero es un buen ejemplo también de cómo se comportan bajo presión, porque seguramente habrá un momento en que tengan que trabajar así (obvio debe ser algo esporádico; si un programador está constantemente trabajando bajo presión, algo anda mal).

...pero también tuve que salvar el archivo y luego ... compilaaar! ( e invocar el interprete ) :D :D

Pues estoy 7 segs más arriba de un candidato normal, he tenido que suplir mis carencias con esfuerzo extra.

¡Psst! Oye, Oscar … Para estos casos tal vez quieras usar  . Ya incluye el método  . ¡Ya no tienes que escribirlo! ;-)

Yo si conte ese tiempo jajaja.

Ya que se habla del tema:

Programming Interview Resources

Claro ... menos que me he tardado en solo escribir y compilar ( ya sabiendo la respuesta obvio) 45 secs ( y mejorando )