Interviewing at Google June 4, 2007
Posted by josephcargo in Blogs, Développement, Entreprises, Free Software, Google, IT Services, SI, Silicon valley, Software, Technologie, Web, ingénierie.5 comments
There are some tips that can help to get hired by Google. Mike Knell tell us :
I’ve now been at Google for, wow, 11 whole months! I thought I’d write down some stuff I really wish I’d known when I started, and especially some things about the interview process. Disclaimer: This is my personal blog, and these views are mine, and not those of my employer.
Don’t worry too much about what to wear when interviewing at Google. If you wear a really sharp suit people will wonder why you own a really sharp suit rather than one you obviously keep just for formal occasions and hardly ever wear, but other than that it doesn’t really matter. Don’t go too far the other way, though. At least make sure you shower and put on something clean, as you’ll be stuck in a small airless room all day for your onsites and if all that people remember about you when they come to write up their feedback is the smell that’s a bad thing. You’ll get irony points for turning up in a Yahoo! or Microsoft T-shirt, though.
Be nice to everyone. Be especially nice to the recruiting coordinator who’s looking after you. And if you need a break for the bathroom or just need to get the hell out of that small airless room for a few minutes or whatever, don’t be afraid to ask. One of your interviewers would probably quite like to go for a stroll outside rather than be sitting in a small room anyway. Similiarly, if you have a phone screen which turns out to be at a bad time or you’re suffering from lack of sleep and can’t think straight, don’t be afraid to ask to reschedule. We want everyone to give us the best impression they can when they’re interviewed, and if you don’t think you can do yourself justice for some reason or another tell us.
Don’t worry too much about getting 100% right or 100% wrong answers. If you don’t know the answer to a question, try to derive it from what you do know. Theorise and hypothesise and think aloud. People who answer every question straight out are few and far between, and that actually tells an interviewer less about you than listening to you reasoning. Be interested in everything, or at least pretend to be.
Don’t be arrogant or cocky. Leave your ego at the door. Arrogance and cockiness will kill you when it comes to assessing your culture fit. We’re looking to hire Obi-Wan, not Luke, and we don’t care if you used to bulls-eye womprats in Beggar’s Canyon in your T-16.
Do come up with interesting questions to ask us, but do be savvy enough to know that questions like “Please give me a detailed description of your production infrastructure” and “How many servers do you guys have exactly, anyway?” aren’t questions we can answer. Please don’t ask us “How have I done? Will I get hired?” or “How much will you pay me anyway?”. We really can’t answer that one.
Don’t make assumptions about how you’ve done unless you, say, ran screaming from the building halfway through your second interview of the day (and hey, you probably wouldn’t be the first to do that).
Do poke your recruiter gently for an update if you haven’t heard anything after a week or so. But be polite – they’re insanely busy. Generally when they have information to pass on to you about your application they’ll do one of the following:
- Call or email you immediately (call if it’s good news, email if it’s bad)
- Go away skiing for a week
Do understand that while the hiring process is tedious and frustrating, it’s tedious and frustrating for just about everyone. It does mean that if you get through it alive you get to work with lots of insanely smart people, and it’s worth it in the end. I promise.
Je suis chaud pour partir à San Francisco. May 28, 2007
Posted by josephcargo in Apple, Blogs, Ecole Centrale Paris, Entreprises, France, Free Software, Google, IBM, IT Services, Linux, Microsoft, SI, Silicon valley, Software, Technologie, Web, Windows, ingénierie.8 comments
Ca sera sans doute parmi les aventures les plus chaudes que j’ai connu dans ma vie. Grâce à Jeremy, nous serons une vingtaine à aller visiter la Mecque des industries de pointe. Silicon Valley accueille les sièges sociaux et campus de nombreuses entreprises. Quand je me rends compte que cette zone joue avec un PIB qui équivaut à celui d’un pays comme le Chili, je sens à l’instant même une sorte de frousse qui s’installe dans mon dos. Entre le 25 novembre 2007 et 2 décembre 2007, je serai à San Francisco plus précisément à la Silicon Valley.
Le but :
Visiter Microsoft, CISCO, Google, Apple, Yahoo…
Pour ne pas galvauder l’ambiance ni le suspens, je voulais juste dire que je suis impatient et j’ai hâte de partir. En ce qui concerne les détails du voyage, je crois savoir que vous saviez pourquoi je m’abstiens à les mentionner 
Partie 1 : L’urbanisation d’un SI May 21, 2007
Posted by josephcargo in Conseil, Consulting, Entreprises, IT Services, Politique, SI, Technologie, Web, Web service, ingénierie.12 comments
C’est un terme assez fort, je me suis rendu compte de sa vraie force lorsque j’ai commencé mon stage dans LBP. A vrai dire, un nombre énorme d’applications informatiques encapsulées dans des projets à différentes architectures techniques doivent être “saisies” avant de commencer la refonte du SI de toute la banque. Le DSI de LBP est un autre monde plein d’énigmes. Des gros projets qui ont été commencés depuis 25 ans et qui doivent pouvoir continuer à offrir leurs services tout en modernisant tout le SI de LBP.
D’abord la bataille des différentes applications informatiques dans un environnement hétérogène laisse croire qu’il est impossible de banaliser l’accès au SI et donc de l’homogénéiser. Un travail de refonte de telle envergure prend au moins 2 ans, en sachant que ce n’est pas sûr qu’il va continuer. Ici, j’ouvre une parenthèse en disant que de grosses boites (sans citer leurs noms) ont voulu urbaniser leur SI mais au bout d’une dizaine d’années, elles se sont arrêtés à le faire vu sa complexité périlleuse et donc son impact sur le fonctionnement de l’intégralité du SI. C’est une question soit d’un bon fonctionnement ou d’un dysfonctionnement, il n’existe pas de solutions entre les deux.
Alors j’ai dit au moins 2 ans (en tenant compte bien entendu de la taille du SI, de ses composantes, des équipes mises en place pour le modéliser…), mais le cabinet de conseil où je suis, a relevé le défi en affirmant qu’il est possible de le faire en 6 mois ! Voila, je suis en quelques sorte visé car mon stage est équivalent à cette période. Je n’infirme pas que le travail qui nous attend (on est 4+1+1) est bien un boulot d’arrache-pied qui consiste à proposer une solution concrète et draconienne pour “sauver” le SI de LBP. Toutefois, je crois à la compétence des gens qui travaillent dans mon cabinet de conseil ainsi que je crois aux qualités des personnes qui tiennent la responsabilités des différents composants du SI de LBP entre leurs mains et plus particulièrement le personnel de la DSI. Jamais, je dis bien jamais, un travail dans une DSI n’a été aussi facile que ça ! Ici on mise et je n’aime pas le dire : On n’a pas le droit de commettre une faute, sans parler des qualités que je m’oblige à les avoir en tant qu’un consultant ou consultant-architecte.
Mais c’est quoi l’urbanisation ?
L’urbanisation est un concept qui vise à simplifier le SI et à améliorer la communication entre ses composantes, tout en offrant une plus grande réactivité lorsqu’il s’agit de le faire évoluer.
Le But ?
- Battre un système informatique existant « en cheminées »
o Développement progressif du SI, construction d’application propre à chaque domaine
o Le besoin de récupérer et de transmettre les informations traitées par ces applications s’est traduit par une imbrication forte des composants du SI et par de la redondance d’informations.
- Des exigences métiers de plus en plus fortes
o Mise en place de nouveaux produits et services dans un marché fortement concurrentiel
o Élargissement des canaux de distribution
- Vers un système informatique souple et évolutif
o Permettre un accès au SI banalisé, cohérent, et multi canal
o Donner une position centrale à la gestion de la relation client (découplage client/canal/services)
o Fournir des offres rapidement et à moindre coût
o Séparer la gestion des opérations financières de la gestion des comptes
Pour la définition du canal, cela est une autre chose, je le développerai dans un article subséquent.
On ne peut pas urbaniser un SI sans mettre en place une base documentaire qui est composée de :
1 cadre = Cadre de référence
1 méthode = Guide de modélisation : Démarche
1 dictionnaire = Guide de modélisation : Dictionnaire des concepts
Ma mission consiste à élaborer ces derniers composants de la banque documentaire. Pour ce faire, il faut opérationnellement passer voir toutes les architectures mises en oeuvre dans les différents serveurs (en imaginant le travail que cela demande au niveau de la Comm.), ensuite,une phase ciné qua none de l’élaboration d’une synthèse technique qui permet de fournir une vision lucide sur tous les composantes du SI.
Ici, je dois évoquer le plan d’urbanisme qui est l’un des vrais piliers de l’urbanisation d’un SI. Lire plus de 50000 pages (Dossiers d’Architectures Techniques) rien que pour modéliser la couche Logique du SI. Il y a bien entendu une couche Métier qui doit précéder la couche Logique. L’organisme où je suis a une DSI compliquée. C’est vrai que LBP date de 5 ans mais son SI est bien plus vieux. Les applications sont déployées sur des architectures techniques bien différentes entre elles et basées dans la plupart des cas sur des concepts propres à LBP (Cloisonnement de la couche Logique, PNiLD…)
Les objectifs ?
Les objectifs opérationnels de l’urbanisation sont :
- D’aligner les architectures métier, fonctionnelle, applicative et technique
- De rompre avec les logiques « en cheminées » du système informatique
- De mutualiser les fonctionnalités
- D’unifier les données correspondant à la même information (et donc de partager les référentiels)
Les objectifs de base de connaissance :
- Faciliter la capitalisation de la connaissance, et donc le partage, la communication et la visibilité sur les actions de la DSI
- Faciliter la décision et le pilotage global des évolutions du SI
- Faciliter les prévisions budgétaires
- Faciliter les études d’impacts lors de demandes d’évolutions
La suite : A la prochaine.
