The Art of Getting Interviewed

I was recently involved in interviewing many candidates – a mix of freshers, juniors and seniors for some positions at Virtual Instruments. Based on my limited view, I see some worrying trends at the freshers level. This blog is a result of some observations to help freshers (also applies to other candidate levels) prepare for industry.

Most of the freshers I interviewed had a Masters in CS/Electronics background – some already had an year of experience, mostly interns. It left me wondering what do they really teach at the Universities? College Ed in USA is not cheap, its a loan that haunts you most of your life. Yet, are the freshers who put a lot of money and effort ready for the real world? It appears that University CS courses still teach a lot of “outdated” stuff that hardly matters in silicon valley jobs. Are the professors aware of changes/challenges in the industry? Has the industry attempted to influence Universities to prepare students for future jobs? I honestly don’t know. Most candidates are familiar with a few algorithms, a few technologies but that alone is not enough to get hired.

Some of the common issues I see are:

lack of clarity: Agreed, that as a fresher you just want to get a break, but that should not yield an impression of “I will work on anything you give me”. Software Industry is extremely varied – engineers eventually specialize into some area based on their passion – web design, web development, server-side, networks, cloud etc are too varied to become a master of all. Ask yourself what technology motivates you most and bring out that passion. Interviewers are not expecting you to know everything or to know what they already know, but look for how quickly you can adapt, learn and positively work in a team.

too much technology on the resume: There are resumes that span from TCP/IP Socket programming to AWS Certification and myriad acronyms in between. It takes considerable amount of time to master any technology these days. Differentiate between what you know and what you have heard of. And its okay to not know. Interviewers will eventually figure that out anyway.

bad spelling and grammar: believe it or not, this is common. Imo, it just shows carelessness (not bothering to get it reviewed). Be thorough and get resumes reviewed by your friends. Inconsistent capitalization/acronyms etc. are on eye-sore on the resume.

inconsistent style: a resume should be easy on eyes, highlight the most important. Too many bolds, italics, underlines are jarring. Be consistent in content styling too. Eg: If you use italics for orgs you worked for, use italics every where. Many people assume styling is not as important as content. In reality, they exhibit at different levels. Styling plays a part in our psychology at a sub-conscious level.

resume too long: For some junior/seniors, I’ve seen resumes that run 6-10 pages long. Even if an interviewer manages to go through it all, he/she won’t remember your history. For all practicals, your last job is really the most important thing. And the one before is a useful incident.

lack of presentation skills: This is one of the biggest issues I see. Too much of “I did this” (taking credit for everything) or “We did this” (you did not contribute much) paints a wrong picture. Highlight how you worked as a team, with the right mixtures of I’s and We’s. All I had to ask is one question “Can you describe yourself briefly?” and many candidates go on a lecture of what they did technically in some project. Some don’t even pause to ask if I understood what they said (esp on phone-screens). Come with innovative ways of rephrasing most banal answers like “I want to solve customer’s problems” or “I like to learn new technology”. An interviewer is typically going thru 10s of candidates, think how you can stand out to contribute.

make your presence felt: Contribute to open source at least a bit, even if just documentation. Presence in open source communities rate higher score than just knowing how to code.

be humble but convincing: You have to be positive and attempt to convince the interviewer that you are up for the challenge, without being arrogant. For eg, if you change jobs frequently, thats usually a red flag, but you can convert that to positives. It may not be your fault that a company got sold or a project nixed due to external factors. But highlight the impact you have made on teams or groups or how you smoothened the transition without being acerbic about it. Self-confidence without arrogance gets noticed.

There is a beautiful anecdote of kAlidAsa. For those who are unfamiliar, kAlidAsa was one of the greatest Sanskrit poets. In the same court, there was yet another great poet bhavabhUti. (There were nine such). Once pArvatI (shivA’s wife) had a doubt who is greater between the two, and shivA promptly says her to test it out. So she descends to the king’s court as an ordinary woman with a (pretend) dead son and tells the king, “My son is dead. A sage predicted that a poet in the king’s court can revive him by solving a samasyA (word-puzzle)” (A samasyA is a type of word-puzzle in Sanskrit, where only half of a verse is given – usually nonsense, and the other half must be completed to make it meaningful). bhavabhUti comes and king asks him to complete the samasyA. bhavabhUti tries but the son is not revived. Then bhavabhUti says “I am sorry, this is the best I could do. Perhaps ask kAlidAsa”. After some time, kAlidAsa enters the court and is presented with the puzzle. kAlidAsa completes the puzzle with exactly the same words that bhavabhUti did. And the son is not revived either. Then kAlidAsa says to the woman “Your son is not dead because this is the only way a samasyA could be solved”. That’s the difference between the two great poets. Same content, but kAlidAsa had that self-confidence.

Finally, if you do not get selected, follow up with the interviewer what are the areas you could improve and do better next time. Most interviewers will oblige and point out positives and negatives.

The Manager Guru

In the IT industry (or any for that matter), its typical that an engineer after gaining a bit of experience (say 5y) is expected to take on a bigger role. Usually it starts with becoming a Team Lead, Module Lead, Architect etc. depending on the needs of the team or the org. Notwithstanding the title, it usually signifies the responsibility is not any more of an individual’s productivity, but ensuring that a group of people can stick to the same quality of productivity.

It is somewhat a gradual slope to slip into. All fine for a while. But a few years in the lead, then the industry also expects something drastically different – promote the individual engineer to a People Manager. There is a general tendency to question the capabilities of an individual with a wealth of experience not ending up in the management. Why aren’t you a Manager, Director or VP yet?

Its a cliche that employees leave managers, not jobs. A lot of best sellers have been written around management, lectures delivered, courses created and money made. But the fundamental problem of why employees don’t get along with their managers remains and will remain. Why? Because, humans. Understanding human psychology is a fundamental part of people management. Mere technical proficiency is not a ticket for that skill.

The greatest fear of any manager is that, on any given day his/her best engineer will leave. So the biggest tap dancing any manager has to do is to sustain the balance of “happiness-quotient vs egoistic-importance” of the employee. While every resource is (or must be) replaceable, a manager cannot simply go around and say that to his/her employees. At the same time, the manager should not give too much importance to anyone at the cost of displeasure to others. True, in any company, everyone’s productivity is different and should be rewarded in proportion, but at the same time explicit indulgence isn’t a good management trait.

One of the first things I did after becoming a manager is, I stopped calling any one as “subordinates” and referred to them as “reports”, for a lack of better term. But now, I think even that is wrong. So I reflected a lot on “What should a manager be”?

The biggest asset of any company (project or team) is not the people, but the institutional knowledge. If the higher-ups tell you that the people are most important, its a lie. You are missing the flashing marquee of old style web page that says “you are replaceable”. So if a person leaves, he/she does not just take the knowledge, they take the crucial mental map and gap of that knowledge. That includes the nodes, links, qualities, relations, relevances and most importantly, the irrelevances. Thats almost impossible to reconstruct by someone else to the same degree. How do we protect that institutional knowledge? Documents? LOL. Knowing what won’t work is much more expensive than knowing what works.

For a different perspective, let’s look at the how some of the world’s greatest institutional knowledge were retained. In India, the guru-parampara (loosely translated as teacher-student-lineage) is the basis of its traditional-knowledge-system. Ancient knowledge has been transferred over hundreds of generations, pretty much intact. How was this possible? The Guru was once a student, gained technical proficiency, but at some point of time graduated to a senior, then eventually establishing his own lineage continuing to transfer that knowledge, by becoming a guru himself and taking care of his students. Now, why was this necessary? Because knowledge gained is considered a debt and not a business. That means the only way of getting of rid of the debt of learnt knowledge, is by teaching it to others. This way the guru is not a manager but a server to his students. The guru teaches his students, commands respect, course-corrects the errants, serves for their future, and all this by getting rid of his debt. And that makes the difference.

Most companies have an org chart that goes from top to bottom as CxO, xVP, xMgr etc. and trickles down to other staff employees. This gives a sense of people “managing” other people top down. In the guru-parampara system, the students would be at the top and who they learn from (are being served from) would be at the bottom. (Note that this is not to be confused with Top-Down management or Bottom-up management style of functioning). This is just the perspective of how one employee is seen in relation to another employee. Calling an employee a subordinate or report, pre-supposes a “superiority”, while calling a manager as one who serves his employees is a mark of humility, respect and above all – humanness – which is the original responsibility of “people” managers. It gives an opportunity for such a role to understand the human psychology, perform the role of enabling others in terms of repaying debt, rather than a sense of scaling up the hierarchy.

The roles and responsibilities are still same, but the frame of reference is now quite different. The top becomes the “root” yielding to a tree chart, where the layer below exists for the fruition of the layer above. Who knows, the tree chart could potentially allow to optimize the organization using tree-based algorithms! A binary tree org, anyone?

The Mutable State-of-Art

Once very often, social media lights up with opinions about the Javascript language, frameworks and its ecosystem being terrible. Some time ago, there was one around React framework, and the question was whether putting all HTML/CSS/JavaScript in one file is a really a good thing, which is against the age old practice of separation of these technologies.

Whenever people question the new ways of doing things, I am reminded of one of the greatest quotes by the Sanskrit poet Kalidasa (4th century CE).

“Just because its old, something cannot be assumed right. Just because its new, something can’t be brushed away. The smart ones analyze and adapt, the fools are swayed by others’ opinions”.

Many retweets, faves, dislikes, epics, savages later, the question still remains: What is the right language or framework?

The separation of technologies then, say 15 years ago, was not intentional. It was a necessity of times. CSS, HTML, JS were advancing independently, performance in browsers were so poor and finding an engineer who could do all was almost impossible. But now, we still have specialists designers and developers, but in general they have a good idea about the other technologies. I still remember back in my IBM days, pointing out to JSP structures to our designer, on where to make style changes. But now these frameworks and their idiosyncrasies are not strange to designers.

Here are my thoughts on why it is pointless criticizing the Javascript world for its organic growth, and equally pointless to criticize the criticism.

Whether “language purists” like it or not, Javascript is ubiquitous. Yes, that’s very hard to digest. Despite its “severe short comings”, it has conquered the net. Why? As IT engineers, we keep holding ourselves to this arbitrary sense of “perfection” and trying to judge everything against it. Typed languages, OO Patterns, Functional paradigms, Modularity, Testability – we seem to know what should be “right” and we are inching towards it – but we just aren’t there yet, we say. But we will know when we reach it, we say. Really? Every language invented since Javascript, seems to be solving the same problem of types, patterns, modularity, dependency etc, only in different syntax combinations.

Here is a fundamental question: Have we got anything right at all in the programming industry at the first stab? Or is 50 years too short to judge? The real limit of the problem is that physiologically, human brains can only process a limited amount of information, so it has to break complex into simple pieces. Eventually the simple pieces evolve to become complex enough, or perhaps our brains shrink so it perceives simple things as complex. So they have to be broken again. But the broken simple pieces have something in common with previously broken simpler pieces that they have to re-integrated. Thus we swing into an eternal pendulum of centralization and distribution.

Here is an illustration with evolution of Java, but you can substitute it with any starter technology:

  1. Java and JVM were originally built for small devices
  2. But once it entered application server space, EJBs were added to tackle distributed environments.
  3. EJBs became so complex, it was abandoned and broken into smaller pieces
  4. Smaller pieces were dependency-injected to form a bigger solution, but eventually they grouped into micro services
  5. Micro-services combined with distributed systems to facilitate container architectures, like Docker
  6. Container architectures are becoming complex and are yielding to orchestration solutions like Swarm and Kubernetes
  7. Predictably, By induction, orchestration solutions will become complex and will yield to Local Clouds
  8. Predictably, commodity local clouds will be broken into Fogs, Cirrus, Altostratus, Cumulus … and delivered by drones.
  9. Predictably, Drones functionality will super-evolve, so they will eventually need a new programming language specifically written for small devices… well…

Much like a fractal, as we dissolve complex problems into simple solutions, they just take a new shape of complexity, due to external influences (mobile, bandwidth for eg). The point is – This cycle will never end.

Working as a Web + Network application engineer (on the SDN controller OpenDaylight) I am seeing two ends (philosophically speaking, they are the ends and the means respectively) of a spectrum. Both UI and Network are always evolving in interesting ways, yet we can analyze these two into a fundamental problem statement:

Network: Deliver content (a packet) from one place to another place, efficiently.
UI: Deliver content (html) from one place to another place, for a user friendly read.

(Of course I am intentionally oversimplifying, but as an end user, when your bandwidth drops below 1Mbps, you call up the customer service to negotiate a discount, not enquire the complexity of the network protocols).

But just to solve the packet delivery problem, think about myriads of protocols and schemes created – TCP/IP, VLAN, MPLS, BGP, VXLAN, OpenFlow, NETCONF and many combinations of these. Similarly in the UI world, all we have to do is deliver readable content, but there are so many aspects and choose-your-noun libraries CSS, SASS, WebPack, D3, Material, visualization, accessibility, modularity, layouts and the most subjective of all – Colors!

So why do front-end developers keep seeking and preferring newer frameworks? There are many reasons and not all are technical. The fundamental reason is: Boredom. Human mind always seeks something new. Not because its useful, but it has to be something just different. And perhaps have a personality.

For any framework in general, to be popular and become sustaining, it should satisfy ALL these conditions:

  1. A very nice familiar sounding easy-to-pronounce name
  2. Should NOT be one person driven
  3. Code should be easy to change and testable
  4. Good documentation
  5. Not do too much magic
  6. Ability to teach it easily to others

The golden rule of framework success is this: It takes a few smart developers to create an idea. It takes a few hundred average developers to sustain it, because the smart developers have moved on to a new idea.

ReactJS Gotchas #001

Tags: Mocha, Chai, Sinon, React 0.13.3

Problem Context: Run a unit test using Mocha against a Form.

Error: Invariant Violation: addComponentAsRefTo(…): Only a ReactOwner can have refs. This usually means that you’re trying to add a ref to a component that doesn’t have an owner (that is, was not created inside of another component’s `render` method). Try rendering this component inside of a new top-level component which will hold the ref.

Example:

beforeEach(function () {
rendered = TestUtils.renderIntoDocument(
<MyComponent ref="myComponentRef" param="10" />
);
});

Solution

Don’t use ref attribute for the component when running a unit test (ie remove ref=”myComponentRef”)

React Impressions

Let me start with a mandatory statement that many first-use-React-blogs start with: “I have played a bit with React and its great. And…”

Having recently completed a decent sized project in ReactJS, I have to say, once in a while there comes a library or framework that truly makes you go back to the basics and think. Despite much gained knowledge, it is fascinating to see that human brain collectively misses the fundamentals as “progress” happens. Much like an experienced cricketer suddenly losing ‘form’ and is adviced to go back to basics. It is not that he forgot to how hold his bat, but that intuitive coordination or that ‘elegant touch’ has disappeared. Perhaps we humans are not wired to over-learn! From simple to complicated to simple, we keep oscillating, just like we keep regurgitating the centralized and distributed system concepts.

It also emphasizes two underestimated facts in software engineering:

1. Creating good software is hard
2. Keeping it simple is even harder

I still remember Rod Johnson’s impacting book ‘Java without EJB’, (I was advocating the same in one of my early projects – removing all EJBs because its complexity did not make sense and the book gave me a lot of cannon). Spring framework made a great impact on many web developers then, bringing in IoC principles into a Java container. (Spring wasnt the first one though, PicoContainer was).

Facebook’s ReactJS is one such framework going back to basics. Apart from the usually quoted strong features like VirtualDom, simple lifecycle model and one-way data flow, what is it that really made React tick? After all component based frameworks are not new – Awt/Swing, Tapestry, Vaadin, GWT, JSF/Seam, Wicket (all Java based) and several Javascript-based were successful – but they all fell into the trap of hiding the complexity of Javascript (and to some extent HTML/CSS) from the developer and that turned out to be a costly decision. Everytime Javascript and HTML standards evolve or browsers support something new, these frameworks have to undergo quite a bit of refactoring. Remember, both designers and front-end developers ultimately like to nano-control the HTML output.

Among the existing component frameworks, the gap between the ‘framework’ and Javascript/HTML is shortest in React. Compared to many frameworks that advocate a structure like .html,.js and .css for each component, React neatly rolls them all into one testable unit, surrounding it with a simple lifecycle. And with the virtual-dom concept, you can apply same concepts to mobile or even desktop apps.

Some complain that JSX is ugly. I first thought same, (I am not a big fan of XML based structures), but it took me all of 10 minutes to overcome it. In fact, I think its one of the smarter things that has come out of React: making Javascript expressions look like HTML. It is quicker to learn JSX than yet another templating language. Passing properties and reading state just feels syntactically familiar.

Another common complaint about JSX is that it makes if conditions and for-each syntactically harder, compared to say AngularJS ng:if/ng:repeat or Handlebar-type syntaxes.

AngularJS:
<span ng-if={showElement}>I am here!</span>;

JSX:

return (
showElement ? <span>I am here!</span> : undefined;
)

While the JSX version does not look concise, the ‘if’ and ‘for/map’ are natural and readable in programmatic syntax than in declarative syntax. Not only that, it can be elevated to a function to make the component reusable. And then it also provides an incentive to make the function stateless – so the component is now slowly turning into a dumb component. AngularJS, though concise, feels more XML-ly than React and you cannot reuse the <span> element as-is in some other place or context (unless you elevate it to a directive). The JSX downside appears to be that you keep creating component wrappers, but isn’t that problem to solve – making composability easier?

The biggest advantage of such componentization is, it also makes unit testing much more delightful. In our project, we use Mocha+Chai+Sinon, which seem to work pretty well. In React, you start to think in terms of composability, than just a page. Many a time, we wrote a complex component, but quickly dissolved/abstracted it into dumb components, by breaking out its props and state.

That’s another thing about React – the learning curve and refactoring is comparitively less steep than others, with only a few concepts to learn.

I am also often asked how long will this framework last? Will Polymers and Web Components take over the browsers? Unfortunately, the Delorean only went upto 2015 and the Almanac probably did not mention React.

His Last Framework

Its been a while since I visited my pyschiatrist and now, Chiropractor Dr. Pear – Perspective Readjustment Specialist. Last time, he helped me cope up an aggressive experience with pair programming. The front-desk handed me a big chunk of forms to fill up my software history.

Years of experiencing web frameworks: About 18.
First framework of pain: JSP Model 2, perhaps Applet, can’t remember.
Latest framework of pain: AngularJS
History of major pain points: EJB, WebSphere, WebLogic, Spring, Fusion Middleware, Wicket, ASP.Net Web/MVC, SharePoint, Grails, SpringBoot, Backbone, Ember, AngularJS and innumerable minor ones.
What type of pain is this? (Select one: Sharp, Shooting, Numb): All of them
Approximate location of pain: Initially Back-end. Then moved to Front-end.
Exact location of pain: Depends on Mood.
Frequency of occurrence of major pain: About every 18 months.

I physically submitted the forms and started checking my tweet feed. New tweets from dzone on Top 20 Javascript frameworks; AngularJS Jobs; Best 35 CSS Frameworks; Top 15 build tools for Javascript; AngularJS vs.., no wonder I needed a therapy.

The nurse called me in and after the initial handshake of pulses and vital stats, she said 200. I was idly looking at the magazines – PlayWeb, Maximum Frameworks… Dr. Pear entered after a knock.

Dr. Pear (browsing thru my history rather than looking at me): Oh, Hello! Its been a while from your last visit.
Me: Yes, Doctor.
Dr. Pear: And what brings you here?
Me: Well, Ive been spinning my head with the next web application framework and I haven’t been able to decide quite…
Dr. Pear: Well, the short answer is “As a consultant you should learn all of them !”, ha ha ha… (after a pause) Yeah, yeah I know. Its the viral season of frameworks. The Javascriptarix flu shot we gave last month was really a placebo. So what kind of framework you are really looking for?
Me: (a bit hesitantly) Not sure, Ive been taking the Javascript MVC Kool-aid for the last couple of years, but it looks like the pain isn’t gone…
Dr. Pear looked at me a bit condescendingly and said “MVC eh? in Javascript? Didn’t you get high enough on it in the Java/.Net world?”.
Me: Well, the Java web frameworks are kinda relegated to providing data services these days…

I had not finished. It must have triggered a raw nerve in him and he went on to a mini lecture of sorts.

“You see, web frameworks come in two general flavors – MVC and Component. Java failingly flirted with the Applet component model initially, and then took a stab at MVC via JSP Model 2, while ASP.Net took the component route after its success with Visual Basic. Interestingly, Java increasingly adapted the component framework model, but Microsoft abandoned ASP.Net Web in favor of ASP.Net MVC. Java/JVM probably tasted all kinds of frameworks in many levels – MVC (Struts, Stripes, Spring, Grails, Play) and Component oriented (Seam, Tapestry, JSF & Co, Wicket, GWT). The fundamental problem with MVC is – it sprays your logic and model everywhere. Many developers struggle to organize it between “what-they-are” vs “what-they-do”. As the complexity increases, the code gets re-organized by features, each of which in turn have the m-v-and-c. Add on top of that, the domain models and view-models are usually different, the whole thing about models start looking like a beauty pageant.”

He paused a second, probably aiming for me to get the pun.

“Component frameworks couple model and view tightly, because a view makes no sense without a model. But the biggest problem for them came from somewhere else: Javascript. Many pure java web frameworks are relatively stable, because of a stable and backward-compatible Servlet API. But component frameworks relied too much on encapsulating Javascript and HTML and in JS world, Friday’s release is outdated by next day Matinee show. Ajax, jQuery and related libraries innovated way too fast and library encapsulation really made no sense. When the JS libraries went unsupported, it dragged the Java frameworks along. With NodeJs, NPM-modules and unit-testing frameworks offering a vastly superior build ecosystem, life became miserable for frontend developers, bogged down by verbosity and slowness of JVM build tools.”

Me: Well, that’s exactly why I am here for. What is the JS framework you would really recommend?
Dr. Pear: Of course Backbone. I love backbones, especially if they aren’t straight. Get it? Ha ha !

He realized I didn’t look at him very admiringly. He continued.

Dr. Pear: Ok. Well, I hate to say it depends, because you didn’t pay me to hear that. So let me tell you something else. With JS frameworks like Backbone, Knockout and Ember becoming first class citizens, server-side slowly mellowed down to doing CRUDGE-work (Create, Read, Update, Delete, Gather and throw Exceptions), now gloriously termed as Microservices Architecture. With AngularJS offering a complete MVC stack, it doesn’t make sense to write Views in server-side anymore.”

Me: So should I still stick with AngularJS MVW ? Besides its barrage of new vocabulary redefinitions like service, factory, provider, scope, directive, the next version 2.0 promises to be completely different and backward incompatible…
Dr. Pear: Yeah, I heard that. It appears that you really need to work on your persuasion skills on convincing your team about writing in new framework every year.
Me: (I looked at him awkwardly, wondering what to say)
Dr. Pear: (Ignoring my awkward pause) Well, the web has to evolve. Why do you think Javascript is going bonkers with frameworks – they have to compete with rapidly advancing browser features, handheld and wearable devices. Who knows, Javascript could be running inside your brain tomorrow. Ok, so you are now tired of MVC in Javascript world also. What about Facebook ReactJS?
Me: ReactJS. Yes I’ve heard of it. Isn’t that a component oriented JS framework?
Dr. Pear: It sure is. You write HTML directly within Javascript or CoffeeScript or Typescript in an XML like syntax and compile them to Javascript.
Me: Im not sure I like the sound of that. Thats not even the best practice.
Dr. Pear: Well, its time to Refactor the Best Practices too. IMO, ReactJS may indeed work out well, because unlike the Java component frameworks, its closer to Javascript, it uses Virtual DOM providing fantastic rendering speeds and helps write isomorphic apps. If you get used to JSX, you will love it.
Me: What about Services?
Dr. Pear: Use one of the many flavors of Flux, Reflux, Fluxxor, Alt – the Action oriented one-way-data-flow-store.
Me: Hmm, that eerily reminds me of Struts. So, there is no really a best framework?
Dr. Pear: There is one – come up with your own. You will surely get a few fans.
Me: What if I get bored and jump ship to another framework? What about the developers who depend on my framework?

“Send them to me!” Dr. Pear said calmly, washing his hands for no reason. “If anyone thinks JS frameworks have more than 18 months of fame, they need a Perspective Readjustment”.

As I was leaving, he gave a parting shot, “Just remember one thing, if it makes you feel any better: no matter which framework, you are solving only a single problem: Delivering html to a browser. And by the way, if you haven’t selected your styling framework, I am open on Saturday afternoon”.

“Er.. Thanks, I will think about it”, I said as I flipped my phone to follow @ReactJS feed on my twitter.

As I was walking out I could see him frantically typing on the screen “Successfully readjusted for component framework. Will likely come here in the next 12 months looking for Web Component and Polymer adjustment.”

Note: Title is a tribute to AC Doyle’s His Last Bow.

Defining React Routers via API

One of the issues I faced while using React for my project is which Router to use? React obviously being a new framework on the block, there are plenty of plugins/components that are being actively developed and not many are (yet) stable. Some plugins are just enough different for you to want a new feature, but it wont support other features required. You can see how bullet-point engineering does not help much. You gotta try out a few and see what works best.

For the Router, react-router is the most popular, featured and well-documented, but it (v0.12.0) did not have one feature I was looking for: Ability to define routers closest to the handler itself.

All the routes go into a single file, usually your app.js, like this:

var routes = (
  <Route name="app" path="/" handler={App}>
    <Route name="login" path="/login" handler={Login}/>
    <Route name="logout" path="/logout" handler={Logout}/>
    <Route name="page1" path="/page1" handler={Page1}/>
    <Route name="page2" path="/page2" handler={Page2}/>
    <DefaultRoute handler={Login}/>
  </Route>
);

Router.run(routes, function(Handler) {
  React.render(<Handler/>, document.body);
});

If the application grows, this is less than ideal and can bloat the app.js. And it somewhat breaks modularity too (even though the app.js will eventually know everything, it forces you to wire the routes statically). The react-mini-router defines the routes as part of component as a mixin and I think thats pretty convenient.

With react-router v0.12.2+ the routes can be configured via api. This is not documented yet officially, afaik.

approute.js

module.exports = Router.createRoute({ name: "app", path: "/", handler: App});

auth.js

var AppRoute = require('./approute.js');
Router.createRoute({ name: "login", path: "/login", parentRoute: AppRoute, handler: Login});
Router.createRoute({ name: "logout", path: "/logout", parentRoute: AppRoute, handler: Logout});

page1.js

var AppRoute = require('./approute.js');
Router.createRoute({ name: "page1", path: "/page1", parentRoute: AppRoute, handler: Page1});


app.js

var AppRoute = require('./approute.js');
Router.createDefaultRoute({parentRoute: AppRoute, handler: Login});

Router.run([ AppRoute ], function (Handler) {
  React.render(<Handler/>, document.body);
});

Notice how the variable routes is replaced with [ AppRoute ]. This is important!.

In auth.js, if defining multiple routes, If you dont want to use parentRoute property, you can also do this:

AppRoute.addRoutes([ LoginRoute, LogoutRoute ]);