Advice to new recruits...

For those joining/working in my groups at CDAC, this is for you.

General Thoughts

An institution grows with its staff (and disintegrates the same way!). So your growth is important. When you cease to grow, you cease to contribute. But the growth has to be well directed - otherwise, it becomes selfish. For example, spending time to learn new technologies or languages is, in general, good (if you dont overdo it!). But spending time to prepare for entrance examinations and certifications which are of relevance to your work profile is selfish. This note keeps this mind, and ensures your growth in a mutually supporting way - you help the institution grow, and the institution helps you grow.

If you have no serious interest in R&D including development, you are wasting your time and others' time here. CDAC is an R&D institution. While not all centres and groups are focussing heavily into research, our groups have been. Every group has a theme - artificial intelligence, e-learning, etc. You must build good competence in the theme area, beyond the project that is assigned to you. Self study and motivation is important ingredients. No one is going to sit and teach you these - you are expected to learn.

You normally have a mix of roles to play here. Research, development, teaching, and general activities. I mention each of these below. Your expectations will also be a mix accordingly. It is ok to excel in one or two, and be an average performer in the other. But none of these activities are optional! Trust me, you will come to like it that way, in the long run.

Your activities

Your project

You will be assigned to one or two projects within a day or two of your joining. Some projects take a while to get a hang of, and some you can join without understanding the whole story. Some are new projects and some may be years old. You can take a while to get going depending on these parameters and your familiarity with the domain and the software technologies used. The projects may have a heavy research component, and some are purely developmental. Normally, you will not be put on the research activities at entry; you can get into them as we go along.
It is assumed/expected that much of your time will go in this activity - something over 70%. Your supervisor will give you broad directions of work to be done on the project from time to time. We normally dont believe in close supervision - you are the best supervisor for your own work. If you cant do justice to this, perhaps you should find another job!
When working on project, remember to keep the earlier guidelines in mind. You are not to be seen as a pure developer as in industry. We would like you to understand the context of the project overall, the project architecture, why we are doing it, where we are going, and so on. Ask your supervisor and others in the group and make sure you have answers to such questions [You don't necessarily have to agree with the answers!]. The immediate circumference of the project is your core competence area. You should understand other work in this area, the major challenges and issues in this area, etc.
Occasionally, depending on the nature of the project, etc we may write some technical/research papers based on the work. Consult your supervisor and/or division head on these things. Normally, people who are seriously involved in the project are given credit - as authors often. You can (and are expected to) contribute to writing of these papers also. Hence your writing skills are important (see the point about communication below).

Some light, but worthwhile reading on graduate education/research/etc. David Merril on Graduate education

Teaching

We run long-term diploma programmes of 6 months or 1 year duration. We also have many short term training programs (1 to 5 days long) on specialised topics. Check your division page on the web for more information on the kind of courses. As a rule, you are expected to participate in all these. If you have a physical problem that prevents you from doing so, inform the supervisor/division head. In all other cases, this is not optional. Your evaluation in the annual performance report will reflect this aspect quite seriously.

I recommend slowly getting into teaching whole heartedly. Keep aside about 30% of your time for it. I am making it mandatory because of the conviction that it helps everyone. It will help you in improving communication, personal growth, clarity of thinking, and so on. Being a good teacher is hard; but it is a worthwhile goal. Be serious about the teaching activity - it should not be construed as an imposed work. Otherwise, you will spoil your own image and the institutions.

Make sure you prepare well for the lectures. Slides are highly recommended for all lectures. Organise your presentation well, with proper flow, good examples, and adequate preparation. Consult your seniors on all these. Attend some of their lectures and look for things you like and hate. Constantly improve your methodology for conducting classes. A lecture well delivered, leaving a satisfied smile on the audience's face, can give you immense satisfaction.

Other activities

The various divisions organise short term courses, workshops, conferences, etc at times. Similarly, the Centre itself has activities like Hindi day celebrations and cultural programmes like New Year's eve, and so on. At times, we have special dignitaries visiting the centre. All these are times, when you are expected to share the organisational load. Volunteer and chip in for planning, specific sub-activities, etc. From small to big, all kinds of work need to be done, to make these go well. Contribute as well as you can.

Communication Skills

As a researcher/developer/teacher - the most common roles you will be playing here - it is important that you develop a comfortable level of familiarity with speaking and writing in English. Your utility will be severely restricted otherwise, and so will be your opportunities.

Pick up a good book on English grammar, and ensure that you learn enough to understand/detect common grammatical errors in a piece of text: including use of tense, singular/plural for verbs, punctuation, grammatically valid constructs, etc. Use simple sentences wherever possible, atleast till you are comfortable with the language.

Make it a habit to read through local documents trying to identify mistakes (the editor's read!). Write atleast a few 5-10 page reports on technical topics. Get a blog account and practice writing technical notes - it is useful reference later on, and improves your ability to organise and communicate. You are never going to improve communication skills without actually practising. You cannot be a good swimmer by reading dozens of books on swimming, unless you actually get into the water (not simulated water) and swim.

  • How to speak and write correctly? Book by Joseph Devlin. An old book - but simple to read, and you must know this much about English and communication. It is available free from here. You may also want to go through my attempt at putting together some notes on technical communication. It is an early draft - but still has some useful points. [I will upload this soon!]

Here is another writeup on how to make a research presentation. I strongly recommend a read. Presenting a research talk

Technical reading and competence building

At the point of entry

It is important you feel at home technically in the group that you join. On one side is the personal comfort with the members and the seniors in the group. On the other is the technical comfort. Follow this section, for the latter aspect. Depending on your area choose the right section and study the material prescribed here.

KBCS

  • Russel and Norvig book AI. It is a bit hard. But you must read through the whole book once. You may not understand all of it - but you should have a feel for all aspects of AI, and be quite comfortable with the basic topics.
  • If you are working in NLP/MT, this is worth a read. Intro to MT

ETU

OSS

  • Open source software: perspectives for development. Paul Dravis, Global Information and Communication Technologies Department, The World Bank, 2003
  • FOSS Primer from IOSN.
  • Learn Linux at the user level well. You must know the following commands minimally: ls, vi, cp, diff, chmod, cat, join, awk, find. Refer to 'man CMND' for help on any CMND. You must know the task done and the common command line options.

There is more… I will fill in as we go along…

Once you are settled

Most of the areas are growing fast. If you dont keep running, you will be 'technically dead' within two years. A useful target is to read atleast one book that is relevant to your division, and say, five papers from good journals. Understanding all that you read is not important, it will come gradually, as the jig-saw pieces fall into place. But you will have general awareness of what is going on in the area. Whatever you are reading, write a short summary and a critical review of the same. Add this to your blog. It is a useful material for others, and good for your own later reference. If you can write such reviews well, go and get a registration from ACM computing reviews. They will send you articles and books for review - and these reviews will be published by ACM.

Acquire mastery over one topic: Pick one topic in which you can claim to be an authority. Set a target of 18 months from joining for this. It is your specialisation. You know the domain, its challenges, current trends, and so on. Keep in touch with this topic through reading, mailing list, attending conferences, etc. Of course, the topic must be a core part of the division focus.

Acquire mastery over two programming languages Make sure you know well at least two languages. Focussing on one language makes you narrow minded often. Once you go beyond one, your vision will be broader, understanding a language as something with plus and minus points. Understand the languages, not purely syntactically, but also semantically.

Expectations

What should you expect at the end of an year? Here is a check list you can match against. Ideally review every 3 months how you are doing.

  • One good publication a year. For first year, it can be a good technical report of a survey nature. After that it must be a publication in a conference/journal. An internally approved paper submitted to such a conference would also be ok - since acceptance is not always in your control!
  • A decent contribution to development activities. A significant chunk of programming work in the project assigned to you. In some cases, the project may not be much on development, in which case, the appropriate type of activity may be substituted here.
  • At least 25% of your time on teaching related activities - preferably including atleast 10-15 lectures (except during your first year). Select modules of your interest in consultation with your supervisor and the course coordinator(s).
  • Active contribution/involvement in general activities of the centre - technical and non-technical events.
  • At least two seminars to internal staff.

Some warnings

  • Do not register for any courses (even if it is part-time) without a written consent from the head of the division. Violation of this can result in punishment including termination of your contract with the Centre. Remember that permission and support to pursue higher studies is a privilege, not a right. Permission and support will be directly dependent on your 'perceived' utility to the group and to the Centre during your period of work.
  • Respect work culture of the institution. Attendence rules and reporting times are to be observed. While exceptions can be allowed, make sure they are exceptions. Report on time, and spend the office time on office work. You can work late or come on holidays, and pursue your private agendas.
  • While we do keep and maintain an air of informality, as needed for a research environment, it should not be mis-used. Loud talks, long phone calls, casual chit chats disturbing others, are all a strict no-no. Imagine the others doing the same to you!
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License