1. Probation
2. Employer's expectations
3. Employee's expectations
3.1. No death marches
3.2. Enough time to complete work
3.3. Managers who respect technical opinion
3.4. Freedom to use the right technology rather than the preferred technology
3.4.1. "we don't do open source because there's no-one to sue"
3.4.2. We have to use a certain vendor's products
3.4.3. Use TFS for everything
3.4.3.1. But need to understand the tools you are using
3.4.3.1.1. Whether it's one system or a suite of systems
3.4.3.1.2. Train people up
3.4.3.1.3. And document the problems, and installations
3.5. Enough technical knowledge in the team
3.5.1. Enough testers
3.5.2. Enough infrastructure
3.6. Make sure decisions and requirements are documented to ensure projects don't fail
3.6.1. Does everyone know what's happening?
3.7. Not working on projects that get cancelled
3.7.1. 7 months work down the drain
3.7.2. Poor planning
3.8. High management competence and high technical competence
3.9. Things should be managed
3.9.1. Higher level decisions
3.9.1.1. Customer view
3.9.1.1.1. Looking across all the customers
3.9.1.1.2. Focus groups
3.9.1.1.3. Support feedback
3.9.1.1.4. Is one customer pressuring the team?
3.9.1.1.5. Stop writing features that no-one wants
3.9.1.1.6. Contrary to public opinion, techies do like talking to users
3.9.1.2. Business planning view
3.9.1.3. Technical view
3.9.1.4. All are important
3.9.2. Listen to technical staff, and act on feedback
4. Benefits
4.1. Maslow's hierarchy of needs
5. Career path
5.1. Do you have to be a manager?
6. Portfolios
6.1. Interviewers will check GitHub etc. if you're on there
6.1.1. Commits are a good way to see someone's code
6.1.2. Games industry relies on it
6.2. Only sites/projects that enhance your CV
6.3. Final year project
6.3.1. App store submission
6.4. Talks and blogs may help too
6.5. StackOverflow reputation
6.6. Anything to demonstrate knowledge and passion
6.7. Prove you can deliver
6.7.1. "Good developers ship"
7. Would you look at twitter/facebook/linkedin?
7.1. Generally not unless it was on CV
7.2. But remember you may be judged on anything you post publically
7.3. Recruitment Agencies will
7.4. Is it suspicious not to have one?
7.4.1. If you don't have one, that's fine
7.4.2. More suspicious to have a dummy one
7.4.3. Magnet for recruitment spam
7.4.4. But it might help you if you do
8. The role of schools and universities
9. The role of businesses
10. Recruitment Agencies
11. Interviews
11.1. It's less about technical knowledge and more about how well a person will fit in your team
11.1.1. You don't want a liability on your team
11.1.2. Make sure you're consistent
11.1.3. How long do you tend to last in a job?
11.1.3.1. More than a year
11.1.3.2. Less than a year
11.1.3.2.1. Can cast doubts on your career path
11.1.3.2.2. But some areas suffer high burnout and turnover
11.1.3.2.3. And contractors might have shorter contracts
11.2. Do you have programming tests, to prove technical knowledge (or the right way of thinking)
11.2.1. An hour of paired programming as part of interview
11.2.2. Does your ego get in the way?
11.2.3. Games industry is very heavy on technical tests
11.2.4. FIzzBuzz screening
11.2.4.1. See Scott Hanselman/Joel Spolsky
11.2.4.2. Can the candidate think like a programmer?
11.2.4.3. Or show them a version with a bug and see if they spot it
11.2.4.4. Frustrating if someone has a good CV but can't handle a FizzBuzz
11.2.5. Military idea - you know everyone's done the same test, and knows their chops
11.2.6. Using Google to find method docs is OK, but not to find solutions
11.2.6.1. simulate the day job
11.2.7. Even without programming tests, talk about data structures and algorithms
11.2.7.1. How does the candidate solve problems?
11.2.7.2. Will they bullshit or admit they don't know?
11.2.7.2.1. "Could you tell me more" is better than a shrug
11.2.7.2.2. Or "it sounds similar to x in Java, let me tell you my thinking..."
11.2.7.2.3. You will find plenty you don't know in the job
11.3. Interview prep
11.3.1. Make sure you're rested
11.3.2. Practice your craft
11.3.3. Specific questions on programming languages
11.3.3.1. but you aren't supposed to know everything
11.3.4. Don't be boring
11.3.4.1. be ready to stop talking
11.3.4.2. don't shout!
11.3.5. Answer the question you are asked
11.3.6. Don't whinge about your old job
11.3.6.1. but it's OK to be honest about why you're leaving
11.3.6.2. there will probably be positive reason why the new job is better
11.3.6.2.1. I want more training
11.3.6.2.2. I'm bored and want to learn more
11.4. Awkward questions
11.4.1. Is it becuase the candidate is unprepared?
11.4.2. Is it because the interviewer is unprepared?
11.4.3. Is the CV accurate?
11.4.3.1. Has the recruitment agent changed your CV?
11.5. Show you know the area
11.5.1. What blogs to you read?
11.5.2. What technologies have you learned?
11.6. Also about the candidate choosing the right employer
11.6.1. So it's OK to ask the employer hard questions too
11.6.2. Keep a personal barrier on a first meeting
11.6.3. Good to have questions to ask about the employer to demonstrate interest if nothing else
11.6.3.1. If they've answered your questions, let them know
12. Do you need to be an IT graduate?
12.1. Many blue chips and public sector don't think so
13. CV
13.1. Get your information across quickly
13.2. Does it tell employers about your interests, and how you stand out
13.2.1. And refine your interests
13.2.1.1. Do open source development
13.2.1.2. Do programming challenges
13.2.1.3. Present at events
13.2.2. Final year projects, make your potential employer interested enough to interview
13.3. Summary showing the stand-out points at the top
13.4. Do fancy CVs work?
13.4.1. Might turn some off
13.4.2. Agencies will strip off the fancy stuff
13.4.3. Don't use default fonts etc to make it subtly stand out
13.4.4. But try to have something eye catching
13.4.4.1. Recruiters look at a lot of CVs
13.4.4.1.1. Sometimes hits the bin on the first line
13.4.4.1.2. Need to weed out people quickly to avoid wasted interview time
13.4.4.2. But if you say "I have a good attention to detail", be consistent
13.5. Make sure CV and covering letter are tailored to the job you're applying for
13.5.1. Frame your summary to highlight what matters for *this* job
13.5.2. Use the right keywords for pre-screening
13.5.2.1. C# and .Net aren't equivalent to agencies
13.5.3. Demonstrate your passion
13.5.4. Be aware of the corporate culture
13.5.4.1. A C#-expert for Google is someone on the language committee
13.6. Is it worth putting non-technical jobs?
13.6.1. For graduates, yes, to demonstrate that you can hold a job and take responsibility
13.6.2. Does it show you're passionate about something?
13.6.2.1. If you've been in a band, it shows you can work in a team
14. Probation
14.1. Not everyone passes
14.1.1. Mostly failures in the interview process, on either side