toy^surgeon #GS-HK@lockfree

H:= Interviewers was an OMS guy in GS-Hongkong, bent on breaking the candidate.

Q3: any real application of CAS in your project?

Q3b: why did you choose CAS instead of traditional lock-based? Justify your decision.
%%A: very simple usage scenario .. therefore, we were very sure it was correct and not slower, probably faster [1]. In fact, it was based on published solutions, customized slightly and reviewed within my team.
%%A: In this context, I would make my decisions. Actually my manager liked this kinda new ideas. Users didn’t need to know this level of details.

[1] uncontended lock acquisition is still slower than CAS

Q3d: how much faster than lock-based?
%%A: I didn’t benchmark. I know it wasn’t slower.

H: but any change is risky
%%A: no. There was no existing codebase to change.

H: but writing new code is a change
%%A: in that case, lock-based solution is also risky.

H: “Not slower” is not a good answer.

%%A: I don’t think I can convince you, but let me try one last time. Suppose my son wants to try a new toy. We know it doesn’t cost more than a familiar toy. We aren’t sure if he would actually keep it, but there’s no harm trying it out.

I said this as a last-ditch effort, since I had all but lost the chance to convince him. So I took a risky sharp turn.

H: but this is production not a toy !

So he was on the hook! What i should have said:

A: No we didn’t roll it out to production without testing. Look at what google lab does.

A: well, my wife went through laser surgery. The surgeon was very experienced and tried a relatively new technique. She was not a guinea pig. Actually the procedure is new but shown to be no worse than the traditional techniques. Basically, we don’t need to do lots of benchmarks to demonstrate a new technique is worth trying. For simple, safe, well-known-yet-new techniques, it’s not always a bad idea to try it on a small sample. Demanding extensive analysis and benchmark is a way to slow down incremental innovations.

A: the CAS technique has been well-researched for decades and tried in many systems. I also used it before.

story: %%investigation skill #etscfg

Hi Paul, In my etscfg I used this simple ifelse:

1        %IFELSE{defined(SOME_CHECK)}%
3        %ELSE%
5        %IFELSE%

To my surprise, Line 4 comes out preceded by a new-line when the if-condition fails. This impacts a lot of config artifacts that shouldn’t be impacted.

On the other hand, when the if-condition evaluates to true, I get exactly Line 2 and I don’t see any new-line added anywhere. This is correct output.

— Investigation —
On my Line 3, the implicit new-line character right after %ELSE% is incorrectly included in $else_block and printed out before Line 4, causing the surprise result. Attached are two test programs showing

my ($if_block, $else_block) = split(/(?:[^\w\n]*)\%ELSE\%/, $block); ### should be
my ($if_block, $else_block) = split(/(?:[^\w\n]*)\%ELSE\%\n?/, $block); ### to include trailing newline in delimiter of split()

In my fix, I also added a “guard” to deal with any trailing spaces sandwiched between %ELSE% and new-line character. I know sometimes I can leave a trailing space sandwiched there.

Altogether, my fix consists of two changes

• 1 new line of perl
• 1 modified line of perl


“didn’t like my face”: we aren’t his top-favorite #bbg

Hi Deepak,

I now think there’s another reason that SIG, Bloomberg, LiquidNet, CapitalDynamics and other employers didn’t make me an offer even though I probably passed technical screening with a technical win.

In our chats, I used the generic term “didn’t like my face” as an umbrella term for several different factors. Today I want to mention a new factor – “what if this candidate takes my offer and continues to shop around?

I believe some companies shun that risk. When in doubt, they reject. When they make an offer they want to ensure the candidate will accept. They want to see “Hey we are clearly the favorite in his mind and he is in a hurry. If we make him an offer he will likely accept right away.”

Clearly, I’m not that type of candidate. I often come across as a “job shopper”, through my non-verbal language, or even through my explicit verbal answers. For example, when asked “Why are you looking to change job” I often answer “I’m actually doing fine on my current job but there are better opportunities like the role in your company.”

Q:so you didn’t write c++for rebus only configured it #CSY

Q: so you didn’t write c++for rebus(or any engine) only configured it?
A: Well, the major (I won’t use superlatives like “biggest” or “real”) challenge in my project is understanding the non-trivial legacy codebase. Once I (I won’t use “we”) reach sufficient understanding, it’s relatively straightforward to implement the required change in a “pinhole surgery”. The best change in this system is usually isolated in a few files and a few functions, among thousands.

I would say that analysis is 50% of the effort, and design, testing, debugging constitute 45% to 49% of the effort and code change is up to 5%. These percentages can vary depending on the type of change. Analysis could be 30 to 70% of the effort.

Frequently, the moment we figure out how things work inside the system, we hit that Aha moment and the problem is basically solved.

In terms of c++ work, as a team we bend over backward to minimize source code change in favor of config change, but there are exceptions —

  • I made many bug fixes.
  • Occasionally, I refactor a function as part of a change. This is unpopular in my team due to the risks. The team basically says Don’t fix something that’s not broken.
  • When we upgraded to c++11, I had to adapt my modules.
  • I added performance instrumentation, without affecting business logic
  • I often need to add logging in my local codebase as part of analysis and testing.
  • (I won’t use “we” here.)

I also need to read lots of existing code as part of analysis.

describe Latest project #weak@22Feb

See also my notes in C:\0\z0\cv,iview.0

Gayle has a good one-pager too for tech companies. There are similar resources.

Current project is supposed to be fresh in your mind, so interviewer has high expectation of details. Better avoid the current project.

Option: you could talk about a “past” project, but bring in details from another project, such as your actual current project, but beware you may be asked “what’s your current project?”

Avoid naive honesty, which often backfires. Such honesty doesn’t serve any purpose. We are professionals, expected to communicate truthfully but also stay relevant. The major challenge or a key component I created may be irrelevant to the interviewer or impossible to describe over phone.

Q: which component did you *design* ?

  • A: wait/notify framework to associate order requests sent out with response received. See the SCB concurrency design questionA
  • A: orderbook + reset, refresh. Orderbook alone could be too familiar to some interviewers .. hard to score points
  • A: Guardian — monitoring, with microagent + server + GUI. Easy to describe with some complexity
  • A: retrans gap mgmt. More details needed
  • A: NYSE+Arca+American integrated feed parser
  • A: Preferences framework
  • A: vol model serialization

Q: major challenges?

%%A: wait/notify framework

Q: what does the system do, in layman’s term

IV Q: proud achievements #incomplete

See also ## lasting achievements as a techie

I need lots of technical details to substantiate my answers.

  • NYSE integrated feed with up to 400k x 8 msg/sec.
  • Barclays vol fitter with half a million B/S equation solver per minute
    • Black Scholes
    • biggest eq drv house in the world as of 2012.
    • fast refitting
    • server farm

elaborate python project/challenge #PWM

Key is “technical challenge”. Without it, I may look like just another python coder. Some of the interviewers may not be easy to impress. I will only target the majority.

Different companies might have different needs for python skill. I can only guess

  1. Usage: data analysis, data science
  2. Usage: automation, glue language
  3. …. py as primary language to implement business logic in an enterprise application? Only in Macquarie, baml and jpm
    1. I could remake my PWM Commissions system in python

For 2), I used

  • devops
  • integration with git, maven, g++, code generation, test result parsing, …. for devops
  • automated testing
  • simple network servers
  • subprocess
  • integration with shell script
  • automatic upload
  • generate c++ source code to be compiled into a native python extension
  • import hack
  • logging decorators —
  • python code attached to trade object. Code to be evaluated at reval time.

(Revisit) senior manager IV: what they watch out for

Common, non-trivial, perhaps hidden issues in a candidate, ranked:

  • twist and turn and not /candid/ about his past
  • not listening
    • jumping to conclusions
    • assuming too much
    • not waiting for a long-winded interviewer to finish, perhaps interrupting
    • jumping to the defensive, when deliberately provoked
  • desperate for the job and losing his perspective
  • opinionated
  • choosy on projects
  • conceited beyond “cool confidence”
  • —–secondary
  • impulsive answers ^ elusive, guarded answers
    • elusive answers? common
  • bad-mouth past managers
  • lack of humor? common
  • tensed up and not cool and calm, perhaps prone to workplace stress
  • exaggeration about his past? common
  • not articulate enough? common
  • poor eye contact? common

%% Quesiton to interviewer

As I get older, the soft interview is becoming more important more tricky. Part of the soft interview is my list of questions to interviewer.

Tip: If possible, ask a “salesy” question so you can highlight your memorable strengths. More importantly, ask smart, serious questions.

How about “truthful” question that show your real concern? I feel there’s very limited value in truthfulness here.

Some people (like me) don’t like [e]asy questions, but interviewer may find it too sensitive and blunt, though they can always dodge it.

  • [e] Q: between quality and speed, what’s more important in everyday situations?
  • Q: bottlenecks and what was/is done about each
  • [e] Q: what are your challenges?
    • resource?
    • people not communicating enough?
    • requirement changing too fast?
  • [e] Q: what design trade-offs have you made?
  • [e] Q: what user groups, and what challenges do each present?
  • [e] Q: what types of team player are needed here?
  • [e] Q: how is performance *measured*?
  • [e] Q: your management style?
  • [e] Q: median age among the developers?
  • Q: Are expectations any different on an older developer (say, my age)
  • Q: who is the most important (not necessarily biggest) competitor?
  • Q (only for the hiring manager): Based on what you have learned about me in this interview, do you have any questions or concerns about my ability (not suitability) to do this job?
    • Note This is a pretty aggressive question, but if there is a good rapport built during the interview, it can be useful. More assertive hiring managers like this as it shows the candidate is not shy about seeking feedback. This can also clear the air of any lingering concerns or possible miscommunications/misconceptions that are a subtext to the interview.


Q: what do you look for in a job

Note this answer is completely unrelated to my true “10Y direction”.

I don’t want to spend too much time on this behavior question since this is one of the easiest behavior questions. Stock answers would suffice, as many candidates prepare stock answers.

Some other candidates would tailor an answer to the specific employer. I tend to go impromptu along :

  • mental engagement
    • math, statstics
    • analytical, data complexity
    • theoretical
    • complexity, not only theoretical
    • low-level challenges, like optimization
    • data volume — performance or analytics challenges
  • impact
    • in terms of number of people in downstream
    • in terms of influence at a higher level
    • helping team members?
  • work-life balance
  • remote
  • direct interaction with users
  • learn something new and strategic??? not worth mentioning.. Too misleading and complicated
  • Note I never mention “team” until prompted

some low-level QQ questions will beat me, but remain confident during IV

See Inevitably, some questions will beat us, perhaps in terms of algo challenge, but many recent questions beat us in terms of in-depth knowledge. So how do you react in an interview after you are beaten on some questions?

Look at this linked-in endorsement — … has a solid attention to details. He relentlessly pursues the most efficient and sensible means to developing software applications. He can lead a team of developers locally and globally, be a team advocate, a problem-solver, and a top-notch software designer. I often relied on him to explain and help detail some of the most complex logical components.

Such a person may very well fail some of those interview questions. He needs to be self-confident about his GTD skills like design, delivery…

## lasting achievements as a techie@@

Backdrop: Technological innovation is fast (less so in commercial banking, i was told) so “lasting” means … maybe 5 to 10 years (rarely longer)?? Few achievements meet this criteria.

See also,

– open source — software have real lasting values. I guess you can learn to Read their source code — usually in C.
– [L] contributions to foundation modules such as VM/CLR, compilers, threading library, GC, STL — real lasting values

What skills contribute to lasting value-add to an organization?

– tuning – DB — needed in many big and small systems
– tuning – low latency systems — more rare
– [L] instrumentation i.e. refactor/design a given (complex) system to make it easy to trace and follow
– [L] ? introspection – tend to be rather powerful in many new languages
– ? interpreting bytecode; decompilers
– ? system security; white hat hacker

[L = I feel most of these skills are low-level]

In theory almost everything can be learned by a young guy in a few years provided they get full (rare!) access to all source code and manage to make sense of it all. However, look at how many bright young people become kernel developers even though so much open source operations systems exist.

vague^normal^specific answers in non-tech interviews

My communication style is detail-oriented and I tune in to specific details. (That’s why I can write.) When another person’s or my own answer is rather vague or very specific, i often notice it before others do.

There are vague answers, normal answers and specific answers in any job interview. You can actually observe the interviewer’s own styleFor tech questions, the more specific, the better. For personality questions, probably not.

After you pass the tech interviews, you don’t have to sell any more. Non-tech interviewers are already sold and basically sniff for potential personality weaknesses. Non-tech interviews need to see “nothing suspicious” in you, not really seeking “star qualities”. If a non-tech interview is busy or have seen many candidates, he can only remember very few things about you. If you just give stock answers, you might be less memorable, but that’s perfectly fine. They always notice that you can explain complex things, can understand and speak English — you pass.

Very specific answers to non-tech questions often show a type of personality. Leaders aren’t always that type. High-level thinker/communicator. As a leader, you often need to communicate to different team members. Not all of them detail-oriented communicators.

Non-specific answers don’t sound evasive and fake.

I often react to surprise questions with slightly vague answers. (These answers could be **better** than the detailed but contrived answers I sometimes come up with.) I feel rather bad about my imprecise *words* therein because I’m sensitive to individual words. I think most people are less sensitive to individual words but rather listen to the whole sentence and the whole person. I think a lot of IT candidates aren’t particularly articulate and eloquent and often beat around the bush with vague, bland answers.

I almost never give brief answers to behavioral questions, but some good answers are fairly short, possibly guarded or evasive, perhaps depending on the listener.

You don’t want to be evasive when answering a pointed question like “why you left that company?”

If you can’t think of specifics to substantiate your answer, then it’s probably ok to be less specific. In your effort to sell yourself and demonstrate your personal quality, you might reveal a very strong flavor of communication style. I think for technical non-lead roles, most candidates answers are not that specific but that’s fine.

If you are detailed-oriented, story-telling may come natural to you, even if you tell the story backward, even if you use imprecise words. Most of my stories are relevant, and most interviewers are interested. Some may be too busy, so it’s good to stop and test their appetite. See other post on a list of good stories.

agile methodology %%xp

Challenge: too many agile principles
Sugg: focus on a few, relate to your personal xp, develop stories —
understandable, memorable, convincing

–xp: frequent releases

–xp: devops automation
RTS, Mac

–xp: frequent and direct feedback from users

–xp: frequent changes to requirements

–xp: “Working software is the principal measure of progress”
pushmail: repeated code blocks; many functions sharing 99% identical code;

–xp: “Working software is the principal measure of progress”
nbc: top3.txt (expert brackets) not following mvc

–xp: “Working software is delivered frequently (weeks rather than months)”
nbc: half-finished product with hundreds of bugs are released to user to evaluate

–Agile home ground:

Low criticality
Senior developers
Requirements change very often
Small number of developers
Culture that thrives on chaos

–(traditional) Plan-driven home ground:

High criticality
Junior developers
Low requirements change
Large number of developers
Culture that demands order