| April 29, 2013
No comments

‘Muscle Fiber’ Composition of Hackers and Architects

It is now generally accepted that muscle-fiber composition  (fast-twitch versus slow-twitch muscles) is a good indicator of the type of sports an athlete would excel at. For example, elite sprinters and running backs (short power-burst activities) have a majority of fast-twitch muscles whereas elite marathoners and climbers (prolonged endurance activities) have a majority of slow-twitch muscles. Understanding where an athlete lies on the Slow-Twitch-Fast-Twitch Spectrum (STFTS) helps scouts identify appropriate talent and helps trainers structure performance-enhancement programs.

This may sound far-fetched, but this is analogous to talent identification and performance evaluation in technical domains. Let me illustrate this with two examples from my previous career as a Wall Street Quant.

1) Trading Desk Quant – the role involves solving moderately hard problems in Math/Stats/CS at a rapid pace in the dynamic environment of the trading floor. When hiring, I looked for people with Math Olympiad or Programming Contests on their resumes.

2) Market Modeling Quant – the role involves solving a few very hard problems in Math/Stats/CS over a long period of time in a quiet environment. When hiring, I looked for people with Math/Stats/CS Ph.D.s or research experience.

Trading Desk Quants are examples of the ‘fast-twitch quants’ and Market Modeling Quants are examples of the ‘slow-twitch quants’. I found that fast-twitch quants performed poorly as Market Modeling Quants and slow-twitch quants performed poorly as Trading Desk Quants (both judged on a relative basis). When interviewing potential hires and when evaluating performances of my team members, understanding where someone lies on the ‘STFTS’ was extremely beneficial. Like in athletics, elite talent in technical domains tend to be somewhat predisposed one way or the other.

Now let me take this analogy to software development roles. The young hacker in your team is the fast-twitch guy – he can produce amazing code at 10x the speed of the average programmer but his code is not documented, not exception-handled and sometimes not architected for scale. In other words, he is awesome at playing offense but you can’t trust him with defense. The senior software architect in your team is the slow-twitch guy – his design is always well thought-out and built for reliability and scale, but he doesn’t produce code at the pace you’d like. In other words, he is amazing at playing defense but you can’t get him to play offense. When it comes to hiring and career development, it really helps to get a grip on a developer’s predisposition to be fast-twitch or slow-twitch.

If you think your team is full of ‘dev sprinters’, you probably need a couple of ‘dev marathoners’ to complement the sprinters, or perhaps train some of the sprinters to also run long-distances. However, if you have an ‘Usain Bolt’ in your team, you don’t want to train him to run a marathon because you need him to operate at peak performance in his area of strength.

Finally, a question for all of you. When strength training, we measure where a trainee lies on the Slow-Twitch-Fast-Twitch-Spectrum by taking the ratio of his 1-Rep-Max load to his 10-Rep-Max load. Can  think of a similar objective metric for software developers to indicate their predisposition on the STFTS?

Ashwin Rao
Co-Founder, ZLemma

Category: Recruiting |
| April 9, 2013
No comments

Job Interviews – What to Expect

I’m going to assume here that the role you are interviewing for requires background and skills in areas within the broad domain of Science, Technology, Engineering, Math/Stats (STEM) and that your interviewers are themselves fairly technical people. Under this assumption, it’s safe to say that your interviewers won’t be spending much time on personality-evaluation questions or even on questions regarding career-goals. STEM folks tend to get down to the business of technical questions fairly quickly! Your interviewer is likely to come well-prepared – with a copy of your resume and armed with a large set of technical questions. This “Going to War” mindset of the interviewer tends to be more acute when interviewing junior candidates.

So how do you put up a good fight? Reading books on technical interviews and solving a lot of puzzles before the interview is somewhat useful as it puts you in the right frame of mind and eliminates any cobwebs from your head. But the most important thing is to understand what type of questions will be asked and the motivation behind each type of question. Surprise is the most dangerous element in a battle, so let’s help you anticipate better! Here are the categories of questions you will typically encounter.

A) Wordy “Out-of-the-box thinking” puzzles: These questions are not technical, but some interviewers seem to characterise them as technical because of the “trick” element or the “out-of-the-box thinking” you need to employ to answer these questions. The questions can range from the bizarre “What is the significance of the term ‘Dead Beef’ ” to the clever “Why are manholes round?”. The problem with these questions is that they are often vague and people from different backgrounds can interpret the questions differently. Some interviewers ask these questions just to have some fun. Some others take the response as an indicator of IQ. Some others use these questions to evaluate personality and communication.

My observation has been that the well-reputed technical teams at the best companies tend to avoid, or at least limit, these questions (personality/communication skills can be evaluated independent of these questions). Make sure you are very clear on what problem you are supposed to solve. And try not to laugh loudly if the question is too bizarre! If too many questions from this category show up, you should be concerned if the group is indeed technical.

B) Discrete Math Puzzles: This category refers to discrete math puzzles requiring high-school level, or sometimes freshman-year background. These questions test your general ability in STEM and in discrete math in particular. You should expect a few questions of this type with almost all technical teams. Whenever there is a mismatch between the background of the interviewer and the interviewee, there is a high probability of this type of question showing up. Here’s an example puzzle: “How many ways can you climb a set of 10 stairs if at every step you can climb up 1 stair or 2 stairs?”. Candidates who enjoy doing puzzles or who have had years of practice with these puzzles have a clear advantage here. If you are not one of those people, you should get some practice with these puzzles for a few days preceding your interviews.

If you haven’t done much discrete math in a while, you should also review some of the key discrete-math concepts that appear often in these puzzles, eg: Binomial Theorem, Pigeon-Hole principle, Unique Prime Factorization, Bayes Theorem etc. If the majority of your questions are in this category, the role might not be well-defined or the interviewers were not well-prepared. Highly technical teams tend to limit these questions to about 1 question per interview and will typically phrase these questions in precise mathematical terms rather than a play with words.

C) Fundamental Domain Problems: These are questions narrowed down to the general domain of the job (eg: Programming or Linear Algebra or Thermodynamics). So they are somewhere between the broad umbrella of STEM and the narrow area of expertise required for the job (eg: Python programming or Stochastic Calculus). These questions require subject-expertise at the Sophomore-Junior level. These questions are fairly fundamental but will require you to be strong in the general domain of the job.

Here’s an example for a job involving programming: “Write an efficient algorithm to enumerate all subsets of a set of integers (no subset should be repeated)”. If you have been focused on a narrow area for a long time (say Java programming), you should prepare for these questions by reviewing some of the books you used in your Sophomore and Junior year courses (for tech jobs, Data Structures and Algorithms is a favorite topic in this category).

These questions are critical in any job that emphasizes the general caliber of a candidate more than narrow skills. In such jobs, you want good problem solvers with a solid undergraduate foundation who can pick up the requisite skills pretty quickly. Be very thorough with the details as the interviewer will typically expect you to get to the final solution. eg: you’ll be expected to work out a definite integral all the way to the final answer on the whiteboard, or you’ll be expected to write a program on a laptop and make sure that it’s working correctly. Being precise is important because interviewers will often report back just your final answer (a single number or the output of your code) during post-interview discussions.

D) Advanced Skill Questions: These are questions that evaluate your expertise in the narrow area (or areas) relevant to the job. Examples would be – Expertise in Parabolic Partial Differential Equations, or expertise in Support Vector Machines (an area within Machine Learning), or expertise in Scala programming. These require background at the senior level and more typically at the graduate-school level. Note that if you have a Ph.D., you will be asked fairly advanced questions in topics pertaining to your Ph.D. thesis (even if the job doesn’t require those specific skills).

The purpose of this category of questions is to evaluate how good you are in your claimed area (or areas) of expertise. I emphasise the word “claimed” because this is where a lot of candidates trip up – candidates tend to oversell their skills and rate themselves a lot higher that their true ability. The best groups at good firms will have people with expertise in a wide range of areas and so you can’t fake your way through.

It’s important to note here that often you are not expected to “solve the problem”. These questions often tend to be open-ended and geared towards a discussion rather than a final solution. The interviewer will typically want to know how you would approach the problem and what kind of techniques you have experience with. Interviewers will often also look for communication and presentation skills via this category of questions.

Good luck with your interviews!

Ashwin Rao
Co-Founder, ZLemma

Discuss on Hacker news

Category: Guidance for Students, Interviews, Job-Seeking Asvice |
| February 21, 2013
7 comments

Language War – Scala v/s Python (Part 2)

This is a sequel to my earlier post – Language War – Scala v/s Python where I shared some of the practical yet emotional/instinctive factors that come into play when picking the core language at a startup. We left the story tied at 1 – 1. Read on to see who ultimately won the ZLemma language war.

Libraries and Tools: Scala’s interop with Java makes it very attractive, giving access to a wide range of libraries and tools for algorithms development. Although numerical computation forms the core of our app, we are not compute-bound and are unlikely to be compute-bound anytime soon. It’s easy to be sucked into the scipy mantra because of the nature of our business, but practically this is not the biggest consideration with our product right now.

What’s important is to note that ZLemma is not just about mathematical programming. A web platform and database engineering are key components of our app. Yes, Scala has Lift but it can’t match the maturity of Django. This overrode the benefits of some of the other libraries/tools that Scala/Java have on offer. Python gets ahead again: 2-1.

Team Culture: A good language coupled with elegant paradigms enable us to express the math/business models more naturally and make the process intellectually satisfying as well as rigorous. This has the effect of establishing a strong and consistent culture in the team.

My view is that functional programming and stateless computation is the natural way to think and code. It’s not just about elegance and clarity of thinking. It’s also about “Kill state, and you kill bugs” (okay – I made up that line :) ). I wanted the team to think along the lines of “lambdas, maps and folds” to build a high-quality software product. While Python gives you lambdas and list-comprehensions, the languages doesn’t really encourage the functional style.

The other factor I thought a lot about was the “If it lints, it’s probably correct” approach to coding – we are all guilty of this, aren’t we? With Scala, the approach often works and we unfortunately end up with a false sense of security and consequent indiscipline. On the other side, this approach to coding doesn’t make any sense for Python, but we still indulge in it! The discipline problems are compounded in Python because the language generally encourages playing offense more than defense (seeking too much instant gratification). Ultimately, I felt Scala leads to a better coding culture in the team. 2-2.

Tried & Tested versus New & Cool: Scala is an impressive language because certain things can be accomplished more easily than in other languages, thanks to features like traits, type variance, lazy evaluation, and actors. However, I reminded myself that it’s a relatively new language and that very few startups have begun with Scala. I feared that we might be too slow in our development and what’s worse, might not even realize that we could be much faster if we had opted for Python.

I also worried that Lift might not be as convenient or versatile as Django. Most importantly, there was the fear of going off the beaten track and encountering something unexpected. The advanced features of Scala are indeed complicated (eg: type variance) – maybe we’d end up tying ourselves in knots trying some of these new things? I was chickening out … So, Python ended up winning the ZLemma language war 3-2.

Looking back: Our platform has been built in Python. But we do use some Scala for independent code outside the platform. The speed with which we have progressed has surpassed my expectations. I am sure it would have taken us much longer to get here had we opted for Scala.

With Python, we get a high from making things work quickly. That’s nice for team morale, but I also get frustrated with the poor defense habits it generates. So I’ve told the team: “Play offense to develop a feature for say a week, then play defense for a couple of days to consolidate (type asserts, exception handling, unit tests etc.), then go back to playing offense on the next feature, and so on …”. This is a happy middle-ground. But the occasional discovery of bugs (mainly due to dynamic typing) gets me ranting about Python. So I’ve decided to rewrite just the core calculation engine in Scala and have the web/data framework remain in Python. REST will bridge the gap. Wish us luck Cmd-Tabbing between Scala in Eclipse and Python in vim :)

Ashwin Rao
Co-Founder, ZLemma

Discuss on Hacker News (please be civil!)

Category: Programming | Tags: , , ,
| February 20, 2013
12 comments

Language War – Scala versus Python

No – I am not going to discuss the theoretical pros and cons of Scala and Python. Instead, I am going to talk about the practical issues startup founders like me face in establishing our main language.

The context: The core of ZLemma.com is a mathematical framework involving highly structured data representations and numerical algorithms. The product involves a large relational database and is delivered through a web application. We wanted to move fast with our development, but we also wanted to build for scale and robustness. A compiled language like C++ was not in consideration because dev progress would be too sluggish. On the other hand, a web programming language like PHP was also not in consideration because it simply wouldn’t work for mathematical modeling.

Initial Thoughts: My first thought was Haskell. You say, “Haskell? Are you crazy?” Crazy – You got that right :) It’s a very beautiful language and once you start coding in Haskell, you tend to get religious about functional programming. Lately, Haskell has become a fairly pragmatic language and is gaining popularity because of the emergence of functional programming paradigms in mainstream languages. However, people talked me out of it – although I am still considering Haskell as a choice for the future :)

The next thought was Scala. Scala is inspired by Haskell and is a more pragmatic functional programming language because of its interop with Java. I decided that Scala will be our core language and that we will program in Scala in the “Haskell-style”.

When Zubin (our Python Guru) joined the team, he began selling me on Python. I remember my impatient persona telling him, “That’s great, but you are going to do Scala here”. Zubin is not religious about Python and appreciates functional programming, so he started learning Scala. After a couple of days, I realized I am being bull-headed and that I should give Python serious consideration. After all, many startups have built sophisticated functionality with Python. And who the hell does Scala? (Actually, Twitter does!)

After some analysis, I realized that Python and Scala are more similar than I had assumed (functions are first-class objects in Python, after all). However, the differences are significant. Here are the five factors I took into account before deciding on our main language.

Developer comfort: We’ve been fortunate to have a very strong dev team. Each of us can pick up new languages and paradigms quickly. Ajit is a very careful engineer – he prefers object-orientation and static typing. Gaurav comes from a mathematical computing background like me and so he is more comfortable with functional programming and static typing. But generally, both Ajit and Gaurav are fairly neutral in their attitude to languages. As should be obvious by now, I am pretty obsessive about functional programming and static typing.

Zubin is the classic hacker in the team, so it was important that we give Zubin a language that he is comfortable with. Zubin enjoys Python’s duck typing and swears by “Code like a Pythonista”. I paid close attention to this fact :) He also enjoys the elegance of list-comprehensions in Python (that made me happy!). Finally, I had to think about future developers we’ll hire. Hmmm … suddenly, it looked like Scala is losing this battle and it did. 1-0 to Python.

Fine – it’s just a battle. I was hoping Scala will win the war.

Typing: My first thought here was : “If you are doing any serious algorithms or anything mathematical, dynamic typing is just not on. When we define functions in Math, we first talk about the domains. The domain specification effort is always well-worth it – you need to know the space you are operating in, otherwise the Math goes out the window”. I heard myself and thought: “That’s the academic in me talking”. More practically, it’s a question of safety. This amounts to playing defense. Good defense is very important to me, even though playing defense slows down the pace of dev progress. Dynamic typing is like speeding on the highway on a motorbike – exciting and dangerous. Static typing is like riding in a military tank – safe and slow. Neither is ideal. The solution is somewhere in-between.

Either inferred static typing (Haskell, Scala) or libraries for automatic type assertions in a dynamic language (Typecheck in Python). My view has been that the former works without slowing you down much. Typecheck in Python sort of defeats a key philosophy of Python: duck-typing. Besides, dynamic typing scares the hell out of me. I’d rather be a bit slow and safe than fast and dead (a.k.a. chicken!). Scala wins this battle. 1-1.

Time Out. The remainder of the story is here.

Ashwin Rao
Co-founder, ZLemma.com

ps: Discuss on Hacker News (please be civil!)

Category: Programming | Tags: , , ,
| February 4, 2013
No comments

ZLemma.com launches!

ZLemma.com is now open for science & engineering students and recent graduates from the top 500 universities in the world.

Map your credentials to scores to determine your suitability for prospective jobs ranging from Silicon Valley to Wall Street.

More about us here

Category: Uncategorized |
| January 10, 2013
No comments

First Steps to a Successful Career

These are notes from my career-advisory talks to graduating students at various universities. Here I assume that you are majoring in an area within Science, Technology, Engineering, Math (STEM) and that you are targeting jobs that require STEM skills.

Diversify your outlook: Most STEM students I’ve mentored focus on developing their hard skills and have had a homogeneous set of friends. Your career will demand good communication skills, a flexible personality, and a diverse outlook. Hence, my most important advice is to acquire versatility in your skills (particularly soft skills) and in your personality. The best way to do this is to interact with a diverse population, including people who are articulate and those who come from different cultures.

Decide objectively: You are a talented student from a good school and you are looking at a wide and interesting range of jobs. An embarrassment of riches can work negatively if you sway to your whims or if your friends & family have an undue influence on you. You need to think in a structured, objective manner. My advice is to find the sweet spot of intersection between your talents and your tastes. Introspect carefully – How talented are you in the areas you love? Did you enjoy the courses you aced? Write down your thoughts and understand in detail the specific needs of the various prospective jobs.

Chill out! As STEM career choices have expanded, I’ve noticed that the stress levels of graduating students have grown. It could be due to heightened peer pressure or due to the increasing emphasis on careers. This may be hard to do, but try not to compare yourself with your peers. It generally works negatively – you can always find someone out there who is not as smart as you but who landed a much better job (in your eyes). You must also understand that correcting a bad decision early in your career is easier than you think. The job choices within STEM are enormous and junior positions are where most openings are. So, research your options well, but at the end of it, chill out!

Higher studies? Students often ask me if they should do a Ph.D. My answer is simple: If you can see yourself in a life of research or academia, if you really enjoy your prospective Ph.D. area, and have the talent and stamina for research, don’t think twice – you are the Ph.D. type! Your work in your Bachelors or Masters thesis should be a good guide. A fancy title should not be your motivation. Neither should you think that it will bolster your job prospects. Apart from a few research jobs, most employers don’t care for a Ph.D. Besides, the job market will be considerably different by the time you graduate. As for a Masters (including an MBA), my view is that if your undergrad is from a good school, you won’t gain much unless you want to make a major domain shift.

Non-STEM careers? I am always surprised when students tell me that STEM careers are boring or are career-limiting. There’s an increasing emphasis on math, stats, algorithms, software engineering, and data science skills in pretty much every domain. If you are a talented STEM student, it makes little sense to consider other career options. STEM jobs are growing not only in numbers, but also in importance. Not to mention compensation! Where else can you find routine 6-figure entry-level positions and sometimes 8-figure net-worths before you turn 30?

Startups? Well, that last statement pertained to startups. But startups are not for everyone. Answer these three questions carefully before you jump into a startup – Is your market big enough? Can your product indeed do a better job than the competition? Is your team talented enough to execute? Often the team is just you, and you are on a shoestring budget. So funding is something you need to sort out quickly. It’s important to have a few good advisors. In fact, I would highly recommend having a co-founder simply for the purpose of having a different perspective or approach. Lastly, you’ve got to have immense passion for your startup – this is what will help you get through tough times.

Can ZLemma help? You bet we can! Our vision is to make career decisions a science for talented students and professionals. Our product algorithmically evaluates your credentials in an objective manner. Our algorithms have a deep understanding of universities, departments, course and project areas, advisors, standard tests, and employers. Our algorithms also work with a structured representation of the job requirements of various interesting jobs in STEM. Ultimately, you get a score called ZLemma Quotient (ZQ) that indicates your suitability for a prospective job.

Look at your ZQs across our representative jobs to get a good perspective on the suitability of various job channels. Once you settle on a channel or two (say ‘Big Data Scientist’ or ‘Trading Desk Strategist’), you can drill down into various jobs within those channels. In a few weeks, we will show you jobs within each channel that you can directly apply for. Until then, identify your broad suitability.

Ashwin Rao
Co-founder, ZLemma.com

Category: Guidance for Students | Tags: ,