So, you have just graduated or are in the final year of graduation – nice! All set to look out for a job. A ‘dream job’ is a concept of the past – its a job that you want right now. HOWEVER, its still the first 10 minutes of the interview that you actually gain 90% chances of getting your job. Here are a few things I learnt and would like to tell people about interview skills:
- Be prepared. Every job position is different. its better to first profile the company you intend to apply for. Find out what they do, who is the management team, who is the core team and primarily what technologies they work in. For example, if you are applying to Microsoft, don’t have your skill sets shout: I have excellent skills in Java! If you are applying to a kernel or embedded systems company, they would be interested in seeing the first few skills they seek: C, unix etc. NOW, this is not hard and fast rules – mostly companies look for potential and talent but I see no harm in this approach, especially when your resume could get screened !
- Prepare the resume properly. Prepare 2-3 different resumes, each highlighting a different skill. After profiling the company, send the relevant resume there first.
- Always mention your graduation degree and years of experience if any, awards won, scholarships won and other extra curricular activities on your resume where they can be easily seen. This helps as companies prefer team players and all-rounders and not just people with a scholastic apptitude.
- There is no need to prominently mention things like age, marital status and other irrelevant details upfront.
- Dont mention each and every little tiny technical detail. The bigger the resume, the more boring it gets !
- Know every word on your resume – If you say you know Flex, you should better know something relevant in it. You are not expected to be an expert in the field, but at least should have proficiency. If you are not confident
- Think before you talk. During the interview, usually the first few questions are general questions about you, your school etc. This is just to get you comfortable and calm your nerves. Don’t give really lengthy answers cos the attention span of interviews will then reduce Keep the talk small, precise and brief.
- Once you are asked a technical question – dont answer immediately – pause, think and then answer.
- Speak slowly, there is no hurry.
- Very important: If you dont know – say so! Honesty is indeed the best policy. Sometimes, the interview does tend to go into directions where you are not comfortable – for example, if you are not very comfortable in digital signal processing and the interviewer is aking you something in this field – say it curtly that this is not your area of expertize or interest.
- Its also important to know when to say this is not your area of interest No point telling the interviewer in Cisco that networking is not your area of interest!
- Once you are asked a technical question – dont answer immediately – pause, think and then answer.
- Don’t open the doors. No! By this, I dont mean be impolite and slam the door When you are asked a technical question, every word that you mention may be probed into. You may think its wise to mention a few big technologies or words in your answers that make you look good – however, think again! As you start taking a dig at big words, the interviewer will definitely ask more details about what you mentioned. If you are not smart enough to ‘lead the interview‘ it professional suicide. For example, I had an experience with candidate who answered my question of ‘whether he know what are data structures’ and he responded with – ‘yes, I know what are AVL trees’. Next question I teased – ‘Whats the full form of AVL mean? Never heard of it’. He responded with ‘Dont know but its something do with balanced trees.’ Now, I was enjoying myself as he was digging his grave – so I cross examined (while my colleague was silently laughing) – ‘What other trees have you heard of’ – immediate response – ‘rb trees and binary trees’ – my question ” what are rb trees?’ – now he was scratching his head as he did not know how to get out of this maze.
- Keep an ace up your sleeve. Now, here is what another candidate tackled the situation. This is an example of leading the interview. (We hired him btw). My question was simple – ‘What all inter process communication are you familiar with’ – Simple answer: ‘Threads, shared memory, pipes and mutex’. Next question: ‘what are mutex?’ -Simple ‘leading’ answer: ‘Mutual exclusion of code via atomic operations’. Next obvious question: ‘What are atomic operations’ — You can see the candidate what leading the interview. This was probably the ACE he had up his sleeve. ‘Atomic operations are steps which are performed within a CPU cycle using DCAS’– woh – next obvious question – ‘DCAS?’. Nailed the interview: ‘Double compare and set – the assembly operations which ensure that a flag is set and compared twice to ensure the lock is taken’ .. my response – ‘welcome to the family’. It takes some skill but it ALWAYS helps to read some extra technicals and steer the interview to you strenghts !!
- Watch your body language. Seems very wierd how much our body talks in the interview. Sweaty hands and nervousness is obvious – infact if you are not nervous, you are abnormal What matters is that you calm yourself down – breathe deeply and maintain a constant rhythm. It helps. Trembling hands, sweating is normal. Ask for a glass of water, coffee or tea. It calms you down. Avoid repetitive movements like clicking the ball-point pen, dangling your feet while talking, tapping on the table etc. it distracts !
- Watch your dressing sense. Its better to be formally dressed in an informal interview than to be dressed in shorts when you interviewers are in a suit This does not mean you dress in a suit for an interview. Dress in casuals – its ok. A shirt and jeans or a shirt and trousers is fine. Avoid floaters (if your feet stink!) What is most important is that you have to be comfortable with what you are wearing – if not, you will be conscious of what you are wearing and will not be able to concentrate !
- Watch your language. Address people politely. Does not have to be ‘Sir’ or ‘Madam’ every time but no harm done. Please do not use slang or abusive language (obviously) and dont get carried away.
- You must learn from the interview. It is NOT wrong to ask for an answer in the interview. You are not expected to know all the answers. But its perfectly normal and a sign of confidence to ask for answers in the interview. It is generally appreciated.
Overall, you should come away from an interview feeling that you have at least learnt something from it ! If you feel that you have not learnt something from it, its not gone well. Also remember, the longer the interview carries on, ‘usually’ it means that its all good. Always recap your interview later and try to find the answers of all the questions you did not know.
Giving interviews is a skill – but its something that can be learnt from and should always be enjoyable.
All the best!
Being in Pune – the student Mecca of India, I get to interact a lot with students – especially freshers or students in their final semester. These are the enthusiatic new kids on the block who want to make a difference. Unfortunately there are a couple of things which are not taught in schools:
- Interview Skills
- Presentation Skills: verbal and written.
- Management Skills
- Entrepreneur Skills
Though it seems a little too far fetched to teach these in technical schools but its common sense that the ‘First impression is the last imrpresion’. I am going to feature a few blogs here 10 minutes that you your dream job – a talk that I had given in Pune at Naralkar Institute, Entrepreneurship in schools – one that I would like to see get implemented. There are tons of help on Presentation skills and management skills, so I am not going to harp on them !
All the best!
So, working with nginx and passenger has been really simplified. There is an excellent screen cast about how exactly how to get it working. (http://www.modrails.com/videos/passenger_nginx.mov). What I was really interested in finding out was, what happens under covers.
It turns out that this is the core of what passenger does is irrespective of whether its running via Apache or Nginx. This was interesting as, I believe this is one step we take for granted!
When passenger_enabled is ‘on’, the Rails (railz in Passenger terminology) or the Rack, the processes are not exec’ed but forked! This is HUGE – unlike mongrel or thin. Processes have a different process id but they are child processes – ie. They share all the parents file descriptors. NOW, since we can fork on demand, it makes a huge difference when we are trying to balance the load on servers and reap them on lower load.
There are different types of ways the server is spawned:
smart lv2 (default)
The conservative method of spawning is the same as what happens with mongrel and thin – the processes are independent. Not recommended at all as this kills the performance.
Smart and smart lv2 are the pre-cached spawners. In the smart way, the framework is spawned and all applications of this framework are spawned. Slightly heavy considering that we do not deploy like this usually.
Smart lv2 is the best of the lot and does a cached application loading – this reduces the load time when the application is requested even for the first time. This is the one we shall dissect.
Questions which arose:
Where is the ruby process?
How much memory does it take?
What is the load time?
If its a smart spawn, I would assume that since one process is forked for every framework application, there should be only one ruby process for rails and one for rack. Need to really investigate this
If its a smart-lv2 spawner, I assumed that there should be at least one ruby process for every application we spawn – however, this is not the case somehow. At all times, I see only one ruby process – how? I created 2 applications and tried to start them from a single nginx server – still only one ruby process – that too consuming 6MB in resident memory. What’s going on here??
Now, I created 2 basic scaffolds, one for each application and invoked the routines – voila, here is my answer! I see 4 ruby processes of 21MB each for 2 applications. So, this explains it – its not rocket science.
Initially, since there are no HTTP requests processed – just the basic application and welcome to rails page, only a single application got spawned. Hence it was only 6MB. When there are some HTTP rails requests, the rails apps were spawned. To verify this:
I killed the nginx process and the ruby child processes disappeared – expected.
I restarted nginx and invoked form browser. Only the welcome page – no ruby process spawned
I invoked a rails request on 1 of the apps – 2 ruby processes (21mb) spawned.
I invoked a rails request on the second apps – 2 more ruby processes surfaced. Passenger-status shows 2 domains and 1 PID (probably implies 1 process and 1 child worker thread?)
Now, the question remains – when are the processes reaped – is there always 2 instances of the app in memory – which is still huge as each consumes 21mb! Now, I was trying find out if and when the instances get reaped – Still doing some investigation on this.
I finally made it to LSRC !! After some initial registration hiccups I was finally on the way (All thanks to Jim Freeze and Satish Talim).
Talks ranged from casual ruby talks to code examples, coding on stage to herding tigers, Avionics to Japan !! It was great to see totally different styles of presentations – some very carefully prepared and perfected like that of Joseph Wilk to those with about 420 slides by Correy Donahoe. The pace of talks and the varied ideas ensured that there was always some excitement in the air. The atmosphere was casual, refreshments were frequent and tasty, people were very approachable and almost anybody got talking to anybody – exactly like how a ruby community should meet. Being the first conference I attended, not only did I gain in knowledge but also got to meet different people from different walks of life, from different states and countries.
Meeting Matz was a pleasure – he is a modest individual who finds it embarrassing to be called a ruby rock-star :). He is a very cool guy and calls himself a simple programmer. It was particularly interesting to see how much he was interested in helping spread ruby awareness in India and was keen to even come down to India to meet the community here. James Edward Grey II is a maverick who gave us a taste of Japan (Tokyokiagi) along with a technical dose of module mixins. Dave Thomas spoke of the messiness in Ruby and various nuances of the imperfect language which makes the language human! Glenn Vanderburg showed the harmony between programming and music, which I could relate to (even though knowledge of music is rock bottom). He was able to give a rational reasoning about why programmers lose track of time (a must read for my wife, who keep complaining about my time management skills) and how programming is an art – something that we can smell, taste and feel. Evan Light was great at showing how TDD works and with his flair is probably the only one who can run through a live demo with ideas from the audience at run time! Joseph Wilk had probably the perfect presentation – but it was the way he prepared it. As a core team member of Cucumber, apart from being called the Cucumber Man, his British-styled humor, meticulous planning for this presentation and his delivery made it one of the best technical sessions I have ever attended. Chat Pytel of Thought Works gave a talk of ‘succeeding in rails’ and this was the one I could connect to the most. At Josh Software, it felt we are at exactly the same stage they were 3 years ago – I had a frank talk with him after the presentation and that was when the humility and the passion for ruby was evident. He is very emphatic in his endeavor to ‘give back to the ruby community’ and its one of the things I intend to incorporate in my company. Jeremy Hinegardner was very enterprising and forthcoming in tools that help between language integration. I had one of those intellectual discussions with him about data analysis and the energy in him about looking into something challenging was soon evident. Larry Diehl of Engine Yard gave a technical session on Dataflow,which left me thinking whether I was living in the past – imagine poping elements from a queue which does exist yet ! Danny Blitz was unbelievable – he came as a war tiger, explained what it was to have a military style software core commando team and what it takes to succeed in the software industry as a leader – its his book that I do plan on purchasing soon! Bruce Tate and Wynn Netherland gave talks on SEO in rails and Compass – the simple ‘take for granted’ things which can make or break your rails application. I am not much in css and html (its high time I did something about it) but with haml and sass, it seems the progression to them may indeed be painless! Did Correy Donohoe gave a presentation?, I wonder! It was 421 slides in 45 minutes, which amounts to about 10 slides per minute! It was one of the most entertaining presentations – a mix of right practices – XP, pair programming, testing and what he does at Engine Yard. Rich Kilmer delivered the keynote and took us through a tour of the defence industry and Ruby. Encoding domains was something I had never heard earlier which I will never forget now ! Among the lightenting talks Eleanor McHugh spoke on how to manage a segmentation violation in ruby and Jared Ning touched everyones heart with his experience in Tanzania building a rails app for the community (wow!). Yahuda Katz gave a great talk on bundling gems which is going to be extremely useful.
Meeting other people like Dallas Pool, Coby Randquist, Gerald Bailey, Dan Mayer, Tim Harper was awesome – they are experts in their own field and gave me plenty to think about! My apologies to some people I met but did not mention.
2 days of intense technical discussions, learning and fun IS what I had hoped for and its exactly what I got. I got a warm welcome from people who were surprised pleasantly that I had flown in only for this conference — well, to be honest, it was totally worth it and I would do this again every year !!
Cheers to Austin!