(This article is written on Dec, 2004)

找工作經驗
結束consulting工作後,我開始為期一個半月人生有史以來真正失業的時光。

在台灣,可能是自己蠻幸運,找工作面試,沒有真正遇到什麼大問題。

在美國, 我這屆畢業的,剛好遇到911後外國工作簽證減半,IT業景氣不在與大公司多半不願意僱用非美國人的尷尬時期。從最後一個學期開始陸續寄履歷與面試的經驗,有一度我真的開始會懷疑自己的能力。

美國學校都會有Career Center,大公司一般會在12月底開始來找明年夏天的畢業生,可能因為靠近紐約 ,大部份來我們學校的都是財務保險公司 JP Morgan, Morgan Stanly, Bloomberg, Met Life, Computer Associate(CA)等 。但是這些公司除了Bloomberg外,都是不收外國人的。而Bloomberg只找C++的人才 ,所以我java的背景也無用武之地 。聽說在IT業的輝煌時期, 因為CA離我們學校很近, 很多人都是把CA當backup ,真的找不到其他工作才會去CA,但是在我這屆,今非昔比,擠破頭還不一定盡的去CA。

我記得第一個在學校的正式面試是一個NJ來的DB公司,面試者是個印度人。 他問了我一些DB的問題,我都能順利回答,但是我永遠記得他要我解釋OS Semaphore的原理時,我解釋半天講的不清不楚的窘狀。當時真的有想挖個地洞鑽進去的感覺,我心想他一定覺得一個CS碩士畢業,有兩個java認證的人竟然連semaphore都解釋不清楚,可能可以變成他以後面試經驗的笑話吧。但是後來經驗較多後,加上聽了很多更誇張的例子,也開始學著原諒自己了。

順道一提,我記得有一次去聽某個公司的說明會,那個主管說他每次面試一定會要面試者解釋Quick Sort,他說他總覺得能正確清楚的解釋出quick sort的人,思緒必須很清楚。之後每次面試我都會先把Quick sort 偷複習一次,不過就莫非定律的鐵律-考試卷上永遠出現你沒準備到的問題,這個問題當然從來不曾被問過。

雖然很討厭面試,覺得要向一個陌生人在短時間裡證明自己的能力是一個很殘酷有點剝削性質的過程,但是我還是很儘量把每次面試的經驗當作一次學習的機會 因為這裡面試不像台灣,面試真的是得來不易,很多人計了數百封履歷,搞不好連一次面試的機會都沒有的,所以我都鼓勵自己能有面試就是好事.

有時人的際遇真的很難說,當時一心想進財務公司的我,因為沒有財務背景,面試通知也以龜速進行,在某次偶然收到Standard& Poor’s 的面試通知,我還納悶那是什麼公司,作了公司背景調查後,才知道是類似道瓊工業指數的財務分析公司。 S&P 500 index是全球著名的 financial market credit rating。當我到了他們為位在Wall Street附近 Water Street 的豪華建築外,才開始後悔沒好好重視這家公司,這個面試我表現的很不好,一方面面試的印度人口音重到我好幾次都得需要他重複問題,然後幾個關鍵性的問題都沒答好。不過這個職位是資深的分析師,我覺得我資歷根本還不到,也不知道他幹麻叫我去面試,只能以是履歷寫的太好了來安慰自己。

但是這個經驗讓我注意到S&P的母公司,也就是我現在的公司,也是個很大的跨國企業,是美國Fortune 500 之一 。它主要是以出版業起家,之後收購S&P跨足財務市場,還經營媒體雜誌等。我當時找工作時是抱著要是不能進財務公司,至少要進有規模的大公司,不然就準備去多倫多或回台灣。在公司的網站投了履歷後一週內,我竟然奇蹟似的被叫去面試,且它的職務內容就完全是我想作的東西,所以我開始如臨大敵似 ,準備著這個面試。

公司位於Madison Square Garden與Penn Station,因為Penn station是大站 NJ train 、 Amtrak 、地鐵站都停,所以是個四通八達好到無可挑剔的地點。這個大樓其實只是紐約的分公司,headquarte是位於就我同事描述內部是裝潢的像皇宮一樣,也是很多大公司所在的Rockefeller Center。除此之外,在Time Square附近還有一棟很有特色頂端有我們公司商標的綠巨人大樓

除了對地點很滿意外,當我步入公司大樓,對裡面的設施也非常滿意 ,裝潢也很有氣度。面試出奇的進行的很順利,長達2小時多的技術面試結束,接著又去樓上見HR。HR其實沒有僱用的權利,他們主要是和你講一些公司的規則,然後當然最重要的是問你Salary Expectation。我老練的問他這個職位的預算,答案竟然超出我預料中的多超多的,不過她說要拿到這樣的錢必須是有很多年經驗的並有出版業相關經驗的,我想我在美國還算是菜鳥,所以當然不敢開那麼多,不過因為有這樣的上限,我當場開了比我自己原本想的還多一萬的薪水。不過也是因為這個上限,我才會覺得我的同事們應該不少都賺超過10萬年薪的。

整個3個小時的面試,讓我覺得應該是很有機會的,通常面試官若是覺得不適合面試大概半小時內就會結束的。不過心理也不敢抱太大希望的,怕落空後會更失落,所以就暫時把這件事忘了,同時我還有工作證被寄丟的問題要處理,所以除了繼續找工作,就是每天打電話給INS。雖然沒工作,但是覺得每天要處理擔心的事還是很多,就在11月快底時,我寫了一封信問當時的Hiring Manager SS recruiting status,結果我收到他令人鼓舞的回信說,我還在他們考慮capable的人選之一,但是因為公司的recruiting process就是很慢,所以請我在等候通知。然後沒幾天後,就收到第二次面試的通知,這次是和SS的主管,也是我的第一個大主管BP先生面試。美國的第二次面試通常已經無關技術了,就是要看你的個性,個人特質是否符合公司或部門要找的人,所以我在網路上找了一堆問題,然後逐一準備如何回答。

正式面試那天 ,我生平第一次穿了重金買的套裝,覺得自己看起來就像個初出茅廬的MBA畢業生。面試過程還算順利,和BP相談甚歡了一個小時。 臨走前,SS和我說BP很滿意我,但是他們還有其他面試者,沒有意外Offer應該會是給我,但是他現在還不能給我100%的答案。我記得當天是禮拜2還是3,他說下禮拜一才能給我,然後接下來幾天,就是我每天吃也吃不好,睡也睡不好,過著成天緊張兮兮,患得患失的日子,直到禮拜一,我正式接到HR來的電話說我得到這個offer為止。

另外,因為美國只要稍有規模的公司,都真的會打電話給申請者留的推薦著,我當時留了我指導教授prof. Bernstein 和 JT的電話,就JT所言 SS打給他兩次但是他都沒接到但是SS有聯絡到Prof. Bernstein, JT說Prof. Bernstein說了我很多好話,所以我想之前我的努力,也算是有回報了。找到工作後,我也入境隨俗的寫了一封感謝函給我的教授,謝謝他的指導,我的教授在今年正式退休了,他的退休歡送會訂在明年一月,我想我回這一趟是跑定了。

因為SS希望我早點開始上班,可以早點上手,所以在12月初接到offer,12月15日我就開始我正式在曼哈頓的上班族生活。
 
工作經驗
這次探友的行程中,除了同學外,見了以前的同事們,我只顧一股腦的吐漏苦水語言的障礙帶來的困難,外國同事的拖功云云。

我一直不喜歡那種喝了洋墨水,猛誇外國月亮圓的人。

所以這次返鄉之前,我沒有認真想過或比較過兩邊的不同。

但是這次回了台灣,所有的回憶又歷歷上心頭。

我開始想,這一年的工作經驗裡,我真的沒有學到什麼嗎?

其實是有的。

以我目前的公司來說,它雖不是專屬的IT公司,但是也是挺有規模的國際公司。我隸屬的是Education 事業群下的一個子部門Higher Education。我的Team 正職的約有16人,Engineer 有7人,3名PM,一名QA analyst, 1 manager, 1SVP(Senior Vice President 是這個子部門的大頭,是一個看起來很年輕,真實年紀不詳,非常幹練的Grace女士),1名秘書,還有2名直接為SVP做事的 (有時根據不同案子,常常有印度來的consultants參與某個案子,目前有4~5個來自不同公司的consultants )
我們部門需要維護數個系統,但主要是一個內部的書籍上版系統Novella,編輯們可用此系統編輯書籍內容,選擇不同版面功能,或是自動整合至目前美國學校普遍使用的Blackbroad ,WEBCT或是我們自己的Classware課程管理系統。
對外是透過Novella系統產生的課程管理網站-Classware,教授們只要採用我們的書籍,即可用該Classware建立課程、指派作業 、發送announcements、管理學生成績等,學生也可登入網站送交作業,觀看成績等 。除此外,還有一個專門負責使用者權限管理、認證、帳號管理的系統。

這快一年的工作經驗裡,以下是我對兩地軟體開發環境或工作環境上的一些看法。

較完整的軟體開發流程
以我之前在台灣2.5年的經驗,所謂的軟體開發流程都是只在紙上談兵的階段。不論是開發測試都在同一環境執行同一人執行(通常是工程師自己),然後一有問題馬上改程式,直接FTP到server 作hot fixes 或是測試是在Production。通常是直接跳過QA這個環節。

環境
我覺得我們team的開發環境是一開始會覺得有點過於繁瑣,但是習慣後會覺得是有其道理。Development,QA和 production是三個分屬的環境,各自的環境又分成staging 和live兩個不同server 。Staging是給內部系統用的,Live是給外部使用者使用的。在QA的Live serve為了模擬真正的production 環境,也有Clustered Setup。所以通過QA測試的codes 95%可以說是在production可以正確執行 (5%是有時QA做的不是很全面,還是有發生過bugs是在production才找到的狀況)

Release流程
每當有一個新的release 時
  1. 一開始的使用者需求會議 負責的PM會把這次release所含的bug fixes和新增工功能清單(bugs管理是使用Apache Bugzilla系統)和負責的Technical Lead討論清楚
  2. 等到需求確定後 engineer會根據需求撰寫文件,然後在Technical review會議討論可能預見的技術上問題。
  3. 一旦文件review完成,就開始coding。
  4. Engineer 若完成某個bug fix或enhancement,會到Bugzilla上mark as FIXED. Coding完成後, Application Administrator作一次QA deployment。詳細的deployment process在下面的Deployment。

Deployment

凡事想做的好,時間就得多花一些。這也是我對我們Deployment Procedure的感想。
我們Team裡有一個職稱application administrator的John先生,John作為介於網管team 和我們team間的橋樑,除了處理networking上的問題,另一個他的重要工作就是Deployment。我們所有的軟體release,不論是QA或是Production Release 都得經由John。
  1. 當軟體開發結束後,Application Administrator會作code freeze,然後把目前所有的code在CVS 放一個版本Tag,之後他就可以針對不同版本check out by tag。
  2. 接著他會對各個有變動的系統寄出一份files difference with previous release 的清單,然後Engineers就要review是否所有有變動的檔案都需要deploy。因為有時有數個案子一起進行,同時沒有在CVS建立Branch時,就有可能發生有些changes不需要在這個release中得狀況 ,這時John就會取得那個檔案前一個版本。
  3. 接著John會跑使用Ant寫的deployment script, deploy所需系統的war和jar(EJB) 和static contents 到QA staging 和live。
  4. 然後PM 和 QA會根據release的bug fixes和enhancement清單開始逐一測試。如果在QA執行正確就mark as Verified。 若是仍有bug, 就會reopen the bug。 接著1~2天的QA bug fix 與根據fixes的次數而訂會有數次QA release。
  5. 直到PM和QA Verfied所有的項目,接著QA PM Application Administrator 就會訂一個deployment到Production的日期,為了不影響正常使用,deployment的時間通常是凌晨5點或6點。
  6. 一旦Production release完成,PM又會再會逐一測試,如果運作正常就會把該bug在Bugzilla中mark as CLOSE。但是若不幸的bug是在production才找到,就得脫序演出直接Production release。 這也通常是我們engineer最討厭的時刻,我們都會互相抱怨QA很濫之類的(笑)。
  7.  直到所有的Bug都在production verified並且close後,這整個release就完成了。
 
我想這整個過程是很值得我們效法的,且我們非純軟體公司都有如此的流程,若是正統的軟體公司,想見應該有更為完整周全的流程。最近我們這個事業群,因上層決定導入Rational的RUP而開始在上課, engineer也會陸續開始上課,可以看出公司希望標準化整個流程的用心,和台灣是很不同的。

實作運用新技術的機會
以前在台灣,因為所待的是Internet公司,其實已經比一般IT Professional有更多機會接觸到比較新的技術。但是常常會有苦無機會實作或是做出的系統是很小眾的,沒有比較大規模系統的實作機會,像是在台灣就算是現在也很難找到真的有效的運用EJB,struts framework, Java Web Service的系統 ,大部分的系統可能直接用JSP Model 1就可以實作完成。

所以相較之下,我覺得目前的機會就算很可貴的。目前的系統是動輒數百個classes ,像對外的課程管理系統就用到相當完整的J2EE platform。 後端是Session bean 包data store classes,前端運用Apache Struts Framework,然後JSP call前端的XSLT engine轉換XML to HTML。其中它也提供數個服務讓內部管理系統透過Java Web Service溝通。

我覺得雖然技術能力增長的是比較有限的,但是有一點很重要的是exposure。 有某些技術可能了解它的理論,但是對其真正的實用性,若有沒一個相對大規模的系統,其實是看不大出來。台灣因為本身市場限制,這方面的人才或機會是比較欠缺的。

懂得生活的美國同事
美國人把生活和工作分的很開,很少有人加班。基本上 6點後公司裡幾乎沒有人了。我覺得我還蠻幸運的,目前的同事其實都有一定水準以上的能力,其實我常開玩笑說賺很多的Web Developer AK 先生,因為他是讀設計美術出身的(是紐約著名設計學校Parsons 的碩士) 所以程式本身的能力或許不足但他的java script和Flash能力也是導師級的,他還曾經在Praat大學成人教育講授java script,雖然他偶而會運用上班時間查哪台數位相機好,或是處理他買房子是事宜,或在我抱怨週末幾乎花半天寫NYU的作業時建議我用上班時間寫作業 因為那個是job related,但是在我和他合作的案子裡,他也總是能負責的把事情做完,或是我有java script疑問時,都能給我合理解釋,還有值得一提的,下班時間後他是個artisit,他自己有租個Studio 定期會去練畫並且已經開過幾次畫展。

其他的engineer 除了Len先生的笑話我常聽不懂,還有他對於自己的見解非常自信與強勢外,他也算是個經驗豐富的engineer。另外擁有三個碩士的大陸Y先生雖是典型的中國大陸半路出家的程式設計師,之前兩個碩士是Chemistry,他也有我能效法學習的地方,比方能很有耐心的用不大輪轉的英文解釋自己的想法。另外印度幫同事們和consultants 們,特別是印度IIT畢業的hawala先生,讓我在他們身上偷師不少,其他非engineer的美國同事,也有很有故事可以講,有機會再寫,我想他們也各自的以不同程度的影響我。

 但,忙裡偷閒、生活工作分開的生活態度,或許才是我從他們身上學到最有價值的東西。
 

 
三年的美國經驗 真的很難完全描述完 

從第一次TA上課講課時,緊張到胃痛,到現在可以在數十名研究生前作presentation
從一開始開車差點撞到樹,到大風雪還開40分鐘的車去上班

從一開始被美國INS的櫃檯氣到眼淚快留下來,到現在可以為了不到一元多算的電話帳單據理力爭 (不過這點我功力還是不夠的)
 
我覺得我變得更獨立,抗壓性更高,更會安排自己的生活

但,我是否變的更快樂?
 
如果你的心是快樂的 不論你在哪裡 你都會覺得快樂的 

我想起一個陌生的美國女孩,在我最困難的第一個學期,在公車和我說的話
 
我會努力的 快樂的繼續下去的
 
 

12/06/2004 於UA 800 從東京往紐約的機上
 因為撥放的電影實在沒一部可看
在灌了一灌要來的紅酒和一灌beers還睡不著後
寫下的訪台後衍生的札記


nycEngDiary 發表在 痞客邦 PIXNET 留言(2) 人氣()


留言列表 (2)

發表留言
  • 偶然的逛到這個網站. 很有意思的文章. <br />
    <br />
    自己也是做軟體方面的工作的. 有點幸運的是. 公司還算肯投資在開發環<br />
    境上. 這種事情就跟買保險一樣. 一但有事情才知道它的可貴. 但說實在<br />
    的. 也要公司脫離"求生存"的階段才有可能做這些事情...<br />
    <br />
    Jay
  • Jay, <br />
    謝謝你的留言. <br />
    你說的沒錯. 公司必須要有足夠資本才能有餘力投資在其他地方,如開發環境或QA程序<br />
    等.但就算一開始沒有資本, 主事者有正確的觀念其實也蠻重要的.要防範未然,不能只看<br />
    短線,才不會之後覆水難收. <br />
    <br />
    Jodie