Salesforce es una empresa de unas 70.000 personas que vende software a los administradores de otras empresas, no a consumidores. Ese detalle reordena su entrevista de ingeniería más de lo que espera la mayoría: la ronda de diseño va de organizaciones cliente y no de usuarios, y la conversación de cultura es una ronda puntuada, no una despedida cordial.
El proceso que describen habitualmente los candidatos incluye una llamada con el hiring manager, live coding, diseño de sistemas y una ronda de valores construida sobre el vocabulario de la casa: Ohana, el término con el que Salesforce se refiere a su comunidad extendida de empleados, clientes, partners y comunidades, y V2MOM, el marco interno de planificación (Vision, Values, Methods, Obstacles, Measures) con el que fijan objetivos y miden el avance. Ninguno es decorativo: los dos acaban apareciendo en preguntas.
El patrón de fallo es previsible. Ingenieros solventes pasan el código con holgura y rinden por debajo en la llamada con el hiring manager y en la ronda de valores, que es donde vive una parte incómodamente grande de la decisión. Estos diez consejos están ordenados alrededor de esa asimetría, y el primero solo aplica si te presentas desde España.
1. Aclara si entrevistas con Salesforce o con un partner del ecosistema
En España, la mayoría de ofertas que mencionan Salesforce no son de Salesforce. Son de consultoras e integradores del ecosistema, que buscan perfiles de Apex, Lightning Web Components, flujos y certificaciones de Trailhead para proyectos de cliente. Es un trabajo muy demandado, pero su entrevista no se parece a la de un software engineer de producto.
La versión equivocada: preparar tres semanas de estructuras de datos y sistemas distribuidos para acabar respondiendo sobre límites de gobernador de Apex, triggers y modelo de permisos. O al revés, presentarte a una vacante de plataforma repasando certificaciones.
La versión correcta es resolverlo en el primer correo, antes de estudiar nada: pregunta si la vacante es de Salesforce Inc. o de un partner, si el trabajo es sobre la plataforma o sobre implantaciones para clientes, dónde reside el equipo y si el puesto es remoto desde España o exige relocalización. Salesforce tiene presencia en Madrid y Barcelona, pero buena parte de la plantilla local es comercial, preventa y servicios profesionales, y muchas vacantes de ingeniería cuelgan de equipos de otros hubs europeos.
Por qué falla la versión perezosa: optimizas la preparación equivocada durante semanas y lo descubres en la primera ronda técnica, cuando ya no hay margen. Es la pregunta más barata del proceso y casi nadie la hace.
2. Trata la llamada con el hiring manager como una ronda técnica
En la mayoría de empresas, la llamada con el manager es una conversación de encaje mutuo posterior al filtro técnico. Salesforce la coloca a menudo al principio, y ese manager suele ser quien tiene la vacante y quien te defiende en el debrief. Llegar en modo charla quema la hora de mayor apalancamiento del proceso.
La versión equivocada: «llevo tres años en mi empresa actual, en el equipo de pagos, y busco más alcance». Eso es leer el currículum en voz alta. No le da al manager nada con lo que defenderte.
La versión correcta es llegar con dos proyectos que aguanten tres capas de profundidad y abrir por la arquitectura, no por el organigrama. «Soy responsable de la capa de idempotencia de la ingesta de pagos. Procesa unos 40.000 webhooks a la hora, y el fallo interesante fue una liquidación duplicada cuando el proveedor reintentó durante una partición de red. Te cuento qué construimos y qué cambiaría hoy». Y deja que te interrumpan.
Por qué falla la primera: el hiring manager no decide si eres agradable, redacta mentalmente la tesis que sostendrá delante de otros, y solo puede defender lo que le hayas dado. Hice dos simulaciones de esta llamada concreta en PhantomCodeAI antes de la mía, porque mi instinto era empezar por el puesto y no por el sistema.
3. Cuenta tus proyectos con la lógica de V2MOM sin pronunciar «V2MOM»
V2MOM es el marco de planificación interna de Salesforce: Vision, Values, Methods, Obstacles, Measures. Los equipos lo escriben y lo usan para discutir prioridades. No te van a examinar del acrónimo, y recitarlo suena exactamente a lo que es.
Lo valioso es que ese marco te dice qué considera una historia completa un ingeniero de Salesforce. La mayoría de relatos están llenos de métodos (lo que construí) y vacíos de medidas (cómo supimos que funcionó).
La versión equivocada: «migramos el servicio de informes a un motor de consultas nuevo y ahora va mucho más rápido».
La versión correcta: «el objetivo era que soporte respondiera preguntas de cuenta sin escalar a ingeniería. Movimos los informes a un almacén columnar. El obstáculo fue que un tercio de las consultas estaban limitadas por permisos, así que no podíamos precalcular de forma ingenua. La medida fueron escalados por cada mil tickets, que pasaron de 18 a 4 en dos trimestres».
Por qué falla la primera: «mucho más rápido» no es falsable, y la cultura de planificación interna de esta empresa está orientada a medidas. Un ingeniero que no sabe nombrar el número que movió suena a alguien a quien le repartían tickets. Ponle una métrica real a cada historia, también a las que salieron mal.
4. En live coding, publica el contrato antes que el algoritmo
Salesforce construye software de plataforma sobre el que otros construyen. Ahí una interfaz es una promesa, y romperla rompe el código a medida de miles de clientes. Al entrevistador le importa tanto cómo defines el borde como cómo lo rellenas.
La versión equivocada: escuchas el enunciado, dices «aquí me sirve un diccionario» y empiezas a teclear. Diez minutos después te preguntan qué pasa con un campo nulo y hay que mover toda la estructura.
La versión correcta es gastar los tres primeros minutos escribiendo la firma y los casos límite como comentarios, antes de cualquier lógica. «La función recibe una lista de registros y devuelve un resultado más una lista de errores por registro en lugar de lanzar excepción, porque quien la llama son procesos por lotes que no pueden abortar por una fila mala. Comportamiento no definido: identificadores duplicados, entrada vacía y registro sin clave de ordenación. Resuelvo los dos primeros y señalo el tercero». Y entonces programas.
Por qué falla la primera: produce una solución correcta en el vacío e inservible como primitiva de plataforma. La pregunta real es si diseñarías una API de la que dependen mil administradores.
5. No ofrezcas tests: escríbelos, y explica por qué
Hay un dato de plataforma que conviene conocer: el código desplegado a una organización de producción de Salesforce debe superar un umbral mínimo de cobertura de tests de Apex, históricamente el 75 %, y lo comprueba el propio entorno al desplegar. Ahí probar no es una aspiración cultural, es una puerta que la plataforma impone a todos sus clientes.
Eso cambia cómo se lee tu cierre. Quien termina y dice «ya está» señala algo distinto de quien termina y empieza a enumerar qué comprobaría.
La versión equivocada: acabar la función, callarte y luego decir «puedo añadir tests si quieres».
La versión correcta: en cuanto la implementación te compila en la cabeza, dices «voy con tres casos: lote vacío, un identificador duplicado y un registro con clave de ordenación nula. El duplicado es el que de verdad me preocupa, porque mi fusión se queda con la última escritura y no tengo claro que ese sea el valor por defecto correcto aquí». Y los escribes si queda tiempo.
Por qué falla la primera: ofrecer los tests como favor los convierte en algo opcional. En una plataforma donde el código sin cobertura literalmente no se puede desplegar, ese matiz se nota.
6. Pon la multi-tenencia en la pizarra en los primeros cinco minutos
Es la mayor diferencia respecto a las entrevistas de diseño a escala de consumo que casi todo el mundo ensaya. No diseñas para un millón de usuarios de un producto, sino para miles de organizaciones cliente que comparten infraestructura y dan por hecho que sus datos son privados y su rendimiento es suyo.
La versión equivocada: dibujar balanceador, capa de aplicación, base de datos, particionar por identificador de usuario y arrancar con la caché. Ese diseño está roto en silencio: una importación nocturna enorme de un solo cliente puede dejar sin recursos a todos los demás.
La versión correcta: en los primeros minutos, «antes de escalar quiero fijar la frontera de inquilino. Los datos se particionan por identificador de organización y toda consulta lo lleva, forzado en la capa de acceso a datos y no por convención. Además quiero cuotas por organización en la cola de trabajos asíncronos, porque el vecino ruidoso aquí es la carga masiva de un cliente grande monopolizando los workers». Y entonces diseñas las cuotas, que es la parte interesante.
Por qué falla la primera: responde a una pregunta de capacidad cuando la pregunta era de aislamiento. La plataforma de Salesforce es conocida por sus límites de gobernador justamente porque compartir infraestructura obliga a poner techos por cliente. Nuestro banco de preguntas de diseño de sistemas sirve para practicar esta forma.
7. Diseña para el administrador del cliente, no solo para el usuario final
Los productos de Salesforce los configuran administradores del cliente que añaden campos, cambian reglas de validación y montan automatizaciones sin tocar a ingeniería. Un diseño que asume un esquema fijo está equivocado para todo el modelo de negocio.
La versión equivocada: un esquema relacional normalizado con lista fija de columnas para la entidad principal, y «el cliente quiere un campo nuevo» resuelto con una migración.
La versión correcta es sacar la extensibilidad a la superficie. «Los clientes van a añadir campos a este objeto, así que separaría las columnas propiedad de la plataforma de una capa de metadatos definidos por el cliente, con las definiciones de campo almacenadas como datos e indexadas selectivamente en vez de añadir columnas físicas por cliente. El precio es peor planificación de consultas, que mitigaría con vistas materializadas por organización sobre los campos por los que realmente filtran».
Por qué falla la primera: obliga a una release de ingeniería por cada cambio de configuración de un cliente, exactamente el acoplamiento que el SaaS empresarial existe para eliminar. No hace falta reproducir la arquitectura interna de Salesforce, sino demostrar que has notado que el esquema no es tuyo y nombrar el coste de tu flexibilidad.
8. Diseña el fallo y la conversación con el cliente, no solo el camino feliz
Salesforce publica el estado de sus servicios y sus clientes construyen procesos operativos encima de esa información. La disponibilidad es un compromiso comercial, no un SLO de un panel interno. Una respuesta que se detiene en «y añadimos reintentos» se queda corta.
La versión equivocada: «si la integración de destino está caída, reintentamos con backoff exponencial». Punto.
La versión correcta baja una capa más, hacia la degradación y la comunicación. «Si la sincronización está indisponible, las escrituras se encolan con un tope por organización y las lecturas sirven el último valor conocido con una marca visible de antigüedad, porque para un cliente empresarial un dato desactualizado en silencio es peor que uno visiblemente desactualizado. Pasado un umbral lo publicamos en la página de estado, en lugar de dejar que cada administrador lo descubra por su cuenta».
Por qué falla la primera: los reintentos son higiene mínima y los menciona todo el mundo. El instinto diferencial en software empresarial es que los fallos tienen público, y ese público son administradores que pagan y necesitan saber qué contarle a su propia gente.
9. Responde a la ronda de valores con un incidente que te costó algo
La ronda de valores puntúa, y es donde peor suenan los candidatos preparados. Devolverle al entrevistador la definición de Ohana es la forma más común de suspenderla.
La versión equivocada: «me identifico mucho con la idea de Ohana porque creo en una cultura familiar donde nos apoyamos y ponemos al cliente primero». Es la paráfrasis de una página pública y no contiene información sobre ti.
La versión correcta: un incidente con una compensación real y su precio dicho en voz alta. «Teníamos un cliente atrapado en un formato de exportación obsoleto. La respuesta limpia de ingeniería era obligarle a migrar. Dediqué tres semanas a construir un adaptador que sabíamos que borraríamos, y eso retrasó un sprint una funcionalidad que era mía. Lo volvería a hacer, pero me equivoqué en una cosa: no avisé a mi manager del retraso hasta que ya se había producido».
Por qué falla la primera: estas rondas miden si has pagado alguna vez por un principio, no si sabes reconocerlo. Y hay una capa local: se hacen en inglés, y una historia de matices en un idioma que no es el tuyo se improvisa mal. Ensayé esta ronda tres veces en inglés en PhantomCodeAI justo por eso. El banco de preguntas conductuales cubre la mecánica general; el matiz de Salesforce es el coste declarado.
10. Pregunta como quien sabe que Salesforce no es una sola empresa
Salesforce ha crecido en buena parte por adquisiciones, y la realidad de ingeniería cambia entre grupos de producto: el lenguaje, la cadencia de despliegue y cuánto se apoya el equipo en la plataforma común. Las preguntas genéricas desperdician el único momento en el que puedes interrogar al entrevistador.
La versión equivocada: «¿cómo es un día normal?» y «¿qué te gusta de trabajar aquí?». Producen respuestas que podías predecir.
La versión correcta, dirigida al hiring manager: «¿tu equipo despliega con el tren de releases de la plataforma o de forma independiente?», «¿qué parte de vuestro stack comparte con el núcleo y dónde tenéis infraestructura propia?», «¿cuál es el reparto entre plataforma multi-tenant y producto en los próximos dos trimestres?».
Y luego el seguimiento, dentro de las 24 horas y dirigido al hiring manager, no solo al recruiter: tres frases con una idea nueva. «Una vuelta más sobre las cuotas por organización: dije tope de trabajos concurrentes, pero la primitiva mejor es una cola justa ponderada por organización, para que un cliente grande se degrade a lento en vez de a bloqueado». El agradecimiento genérico compite con el de todos; un apunte técnico corto le da al manager una frase concreta para el debrief.
Qué hacer con la semana que te queda
Si vas justo de tiempo, el reparto que encaja con este proceso no es el de un proceso FAANG. El código tiene que estar automatizado, pero rara vez es la ronda que termina una candidatura en Salesforce. Dedica tiempo desproporcionado a la narrativa para el hiring manager, contada con medidas reales, y a un diseño multi-tenant que puedas levantar desde cero: cuotas, esquema configurable e historia de degradación.
Cierra además dos temas que en España llegan siempre tarde: tu preaviso real, quince días por el Estatuto de los Trabajadores salvo que convenio o contrato lo alarguen, y si el puesto implica horario de otro país o mudanza. Y normaliza tú las cifras antes de comparar: las multinacionales razonan en doce pagas y en España es habitual cobrar en catorce.
Lo que hice la semana antes de mi propio proceso fue encadenar la llamada del hiring manager y la ronda de valores dos veces seguidas en PhantomCodeAI, porque eran las dos que no podía ensayar con un amigo sin sentirme ridículo. El patrón de las transcripciones era siempre el mismo: explicaba arquitectura bien y resultados mal, que es exactamente la carencia que nota una empresa obsesionada con las medidas.