mainstream domains, again

Perl is  becoming very niche and out of demand. It’s true that someone in tech would “take up” the perl (or the apache, mysql, Delphi …) full time jobs at a comfortable salary, but I don’t want to be one of them.

Majority of programmers in finance aren’t working on trading systems. It might also be true that the majority of programmers aren’t in finance and java/c++, so maybe I should feel less lonely in those domains like perl. However, in reality, I would feel deeply lonely in those domain. I feel deeply “mainstream” if I’m in trading/java/c++, not even c#

ranking %%proficiency in java, c#, c++

Q: phone interview?
A: java c++  c#. I fail more c++ questions than java.

Q: depth of understanding?
A: java c++  c#. Largely /conceptual/
c++ —- Some essential libraries like threading, STL, socket, IO

Q: coding standards, best practices, patterns?
A: java c++ c#. Some are theoretical
c# —- needs more books

Q: real world problem solving?
A: java  c#  c++. Depends on diversity of past projects, not on theoretical

Q: productivity (real projects)? Managers often focus here. Some coding tests also focus here.
A: java  c#  c++

Q: mileage?
A: java  c#  c++

Q: theoretical mileage?
A: java c++  c#
c# —- Need linq, CLR, GC, tuning,

[11] y I turned down BGC-Partners

Now looking back after these few days, I feel java’s strength over c++ is too obvious. Most large trading apps are built in java; only some in c++. Experience in java has more _value_; mine is still limited.

Domain knowledge is the other big factor. Socket programming is too low-level and non-financial to my liking.

If I really decide to quit US early, then my “current US salary” counts. Consulting salary commands higher return salary.

Current job also gives me a lot of freedom and flexibility.
– I can interview;
– have time to study c++, swing, gemfire etc.
– can consider equities
– can consider analytics
– can consider London or Hongkong

Ultimately, as I told the recruiter, i don’t see myself committed to the new job for more than a few months. It would cause too much pain to interview for another job so soon.

workload comparison — GS vs elsewhere

To compare workload, it’s unfair to just look at working hours.

GS is high intensity. In most companies, people work 3 to 6 hours most days — 95% of the “distribution”. A common estimate is 5 hours/day. At GS I work about 8 hours out of 11 (9am-8pm), but intensity is probably twice the average intensity elsewhere.

A day at GS gets about 2 to 3 times the work done compared to many other companies, because my GS colleagues think, read, search, memorize and absorb information faster, under higher pressure. If and when I work 9am-6pm it's equivalent to at 12 hours/day.

presenting my SQL experience to an interviewer

I think I might talk about

·         Complexity of my system – as we went over yesterday.
·         Tuning techniques
·         Table and proc design
·         Execute immediate
·         Milestoning and history table
·         Interesting joins and sub-queries
·         Index design
·         Writable views
·         Identity column

I'm lucky to have a few books on advanced T-sql. I can mention a few
non-trivial points for illustration.

Even more importantly, I'm lucky because my GS department has a tuning
class by an in-house Sybase expert. He gave us a practical and fairly
systematic tutorial on tuning Sybase queries in our specific context.
I can draw upon his ideas.

I also asked an experienced Sybase developer in my department – “how
do u gauge someone's Sybase expertise? What specific questions would
you ask?”. He's kind enough to give me a good answer — short and
sharp
·         Force plan
·         Show plan
·         Show statistics io

If I'm not wrong, perhaps he also mentioned Transaction management.

humor again

I feel it's good to develop humor both at work and at home, with
“mom”, and soon with granny, and sooner than we think, with baby boy.

As u pointed out at The Pond (or something), a lot of times I don't
get it when people say something funny.  Perhaps due to language,
figures of speech, pace/accent. Often I interpret things too
literally.

(Without going into details, I feel there are many types of humors. I
was more interested in witty remarks. Even more comfortable to me are
the one-liners by intellectual writers, though I seldom emulate them.)

Perhaps I should try to learn all kinds of humor and use whatever and
whenever I can. Assumption is, humor is welcome in most situations
except the obvious like after an accident or someone (me?) is sacked.

A recurring pattern of my incorrect communication with bosses

I now realize an obvious mistake I made at GS — I frequently expressed negative attitude when proposing a simpler, easier solution to an otherwise arduous, time-consuming task.

In GS I had daily or weekly interactions with 3 managers — I report to A, who reports to B, who reports to C. The bosses in the examples below include all 3 persons. So my communication issues are fairly wide spread.

Example 1: I once wrote an email to my internal clients on 2 options about a system rollout. These internal clients are the users of the system. I said one of the 2 options would not require the team (potentially including some internal client as well) to stay late in office. I mentioned this stay-late factor as one of the pros and cons. My manager also received this email and she was shocked and even ashamed.

Example 2: My team lead and I each proposed a competing design on a major re-architecture project. I felt so strongly about this design choice that I arranged with team lead to present the 2 designs to my senior manager (who manages about 15 people), me first, team lead 2nd. After a 90 minute presentation and discussion, manager has heard all the facts and analysis. When it came to the final list of advantages/drawbacks, i mentioned that my simpler design has better performance, business logic transparency, auditability, … and can save, very roughly, an estimated 8 days of effort. (I felt it can save 20 days, but couldn't say it in front of manager). Then I said “You all know that long ago I planned a 2-week vacation for this month. The bigger design will be nearly impossible to finish before the deadline. We all know the deadline is not something we can change — many other teams are impacted in this huge project.”

2 months later, this senior manager revealed to me that personal vacation should never be brought up during system design discussions.

Example 3: This happened many times, perhaps 10 times between me and team lead. I often propose a simpler solution, against my team lead's more ambitious design. When discussing (sometimes debating) with him, i often speak about “easier”, “too difficult”, “faster”, “we can change later when we have more time”. These words became such an obvious pattern that team lead wrote in my performance review “seek what's good for the system long term, not what's easy for you… Pushback….Bin often says something is too difficult, but later it turned to be doable… Can-do attitude required.”

Citi muni ^ Barcap credit etrading — 2 jobs choose 1

— deciding factors 3pr
[C]
$
[P]

— Citi
[P] workload, reputation of bureaucracy. GS hangover.
established, battle tested, not a lab product
green card?
$, considering annual leave, benefits, bonus
[C] if things fail like GS, i do NOT want the same pain of job hunting. Consultants easily change contract

— Barclays:
companies usually fire consultants before employee.
contracts can end without notice
newer technologies? Actually Neoreo uses new stuff too.