Solo puedo hablar por Extreme Blue en los Estados Unidos (aunque sospecho que estás en los Estados Unidos, ya que el sistema de calificación de 4 puntos es más común aquí).
La respuesta corta es no, no podremos considerarlo para Extreme Blue si su GPA general está por debajo de un 3.0.
La respuesta un poco más larga es que Extreme Blue está muy enfocado en la colocación a tiempo completo de nuestros pasantes (por eso damos prioridad a los estudiantes dentro de los 2 semestres de graduación), y las organizaciones de IBM que contratan a nuestros estudiantes a tiempo completo requieren GPA de menos 3.0 (y algunos de ellos quieren un 3.2).
Voy a seguir adelante y proporcionar una respuesta aún más larga aquí, ya que me etiquetaron para responder esta pregunta. Quiero dejar en claro que no sé nada sobre la situación del OP más allá de lo que pusieron en la pregunta anterior, por lo que esta respuesta más larga no debe considerarse como un comentario directo sobre la situación del OP, las opciones de carrera, las decisiones personales o cualquier otra cosa. más. Esto es solo un resumen de mi pensamiento sobre la cuestión del GPA.
He pensado mucho en esta pregunta a lo largo de los años, y he ido y venido en mi opinión sobre la importancia del GPA, y particularmente el GPA acumulativo. En este punto, la culminación para mí de todo ese pensamiento es que * creo * que el GPA acumulativo es un criterio importante.
Para explicar por qué, tendrás que consentirme con algunos párrafos de aparente digresión. Prometo que hay un punto por venir. Si debe hacerlo, puede saltar a los puntos de viñeta a continuación, aunque perderá algo del contexto.
La naturaleza de nuestra industria ha cambiado enormemente en los últimos 30 años. Ciertamente hubo un tiempo en el pasado cuando el procedimiento operativo estándar en la industria de la tecnología implicaba contratar a muchos codificadores, colocarlos en una habitación sin ventanas en algún lugar y alimentarlos con montones de especificaciones técnicas detalladas que convirtieron en código, con la ayuda de pizza. y cafeína.
Un nombre formal para ese proceso fue el “Método de la cascada” del desarrollo de software, en el cual una persona no técnica o semi-técnica habló con el cliente, reunió sus requisitos, los entregó a una persona algo más técnica que los tradujo a una tecnología spec, que a su vez fue entregado a los codificadores para codificar. Luego, su código se entregó a los evaluadores para que los probara según los requisitos originales, y si todas las pruebas pasaban, el resultado final se entregaba al cliente con un apretón de manos y un adiós, posiblemente un año o más después de que comenzara el proyecto.
Esto era, por supuesto, terrible, si el objetivo era complacer realmente al cliente. Tal vez la gente que registró los requisitos acertó, y tal vez no lo hicieron. Tal vez la persona que tradujo esos requisitos en una especificación acertó, y tal vez no lo hicieron. Tal vez los codificadores pudieron convertir con precisión esa especificación en software de trabajo, y tal vez no lo hicieron. Tal vez los requisitos del cliente no habían cambiado durante ese año, pero probablemente sí.
Hay una razón por la cual casi toda la industria se ha convertido en variaciones del desarrollo de software Agile, un proceso cuya base se basa en obtener comentarios continuos de las partes interesadas y que, por su propio diseño, pone a los desarrolladores en contacto más directo con los clientes.
Combine eso con el auge de la web, y más recientemente en la nube, y lo que tiene es una industria en la que equipos mucho más pequeños, que consisten en una mezcla de codificadores, diseñadores, evaluadores, gerentes de producto y empresarios, están desarrollando software en muy poco tiempo. -escalas, y en comunicación íntima con sus clientes de forma semanal o incluso diaria.
Suena como la receta para un inicio exitoso, ¿verdad? También suena como la receta para un exitoso equipo de Extreme Blue, y eso es intencional.
Pero lo que eso significa es que todos en el equipo tienen que ser buenos en una variedad más amplia de cosas. Nuestros ingenieros de software deben ser buenos en la codificación, pero también deben ser buenos en:
- comunicarse con compañeros de equipo y clientes, en un lenguaje claro, utilizando el nivel apropiado de detalles técnicos según la audiencia
- haciendo malabarismos con múltiples líneas de tiempo y múltiples, a veces conflictivas, fechas límite
- Trabajar con las partes interesadas para evaluar y priorizar constantemente el trabajo pendiente
- comprender los puntos débiles de los clientes y traducirlos en soluciones de software que realmente resuelvan esos puntos débiles
- identificar obstáculos rápidamente, notificar a las partes interesadas sobre el riesgo potencial y solicitar ayuda
Mientras más pensaba en el promedio de calificaciones acumulativo a lo largo de los años, más concluía que, aunque de ninguna manera es perfecto, sigue siendo un indicador valioso de la capacidad de un estudiante para tener éxito en todos los puntos anteriores. Sus cursos no importantes requeridos [con suerte] lo ayudarán a aprender a comunicarse con mayor claridad, y también le brindarán perspectivas diferentes a las suyas, perspectivas que podrían ser similares a las de sus futuros clientes.
Tener que hacer malabarismos con entre 4 y 6 cursos por semestre, y desempeñarse satisfactoriamente en todos ellos, es una excelente capacitación para la naturaleza multiproceso y multitarea de la industria moderna. La gestión del tiempo es fundamental para nosotros: si le decimos a un cliente que enviaremos en una fecha determinada, o bien debemos enviar en esa fecha, o debemos alertarlo con la mayor anticipación posible de que vamos a Extraño esa fecha.
Y reconocer que está luchando lo suficientemente temprano como para dar la alarma, pedir ayuda, ajustar las expectativas, renegociar las prioridades (o abandonar la clase) es una parte crítica de eso.
Para ser brutalmente honesto, el GPA acumulativo también me dice cuán bueno eres para cavar y hacer cosas que te irritan y que preferirías no estar haciendo. Porque CADA trabajo tiene algo de eso. CADA TRABAJO. Amo mi trabajo más que cualquier otro trabajo que haya tenido (le he dicho a muchas personas que creo que es el mejor trabajo en IBM), pero a veces todavía hay algo estúpido que no quiero hacer. Afortunadamente, la atención [no deseada] de mis padres y maestros a mis calificaciones en el pasado me dio el enfoque para potenciar a través del informe ocasional de TPS y pasar a las cosas divertidas.