This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Dan Antion's talk on hiring Smalltalkers
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
David Buck took these notes yesterday at a talk he attended, and was kind enough to make them available to me. So here you go - Dan Antion's talk on hiring and training pre-college workers
There's a benefit to hiring people straight out of school with no programming experience.
American Nuclear Insurers
small business providing insurance to nuclear industry
hard to find software that's appropriate
need to support engineering
problems lead to in house development
Hard to keep college graduates interested High turnover due to career management concerns
Took a chance on a high school student who wanted a job. Took him on and trained him - worked well.
Finding candidates was hard.
Advertising hard
Recruiters don't do this
Tech school focused on certification and hop topics
Technical college didn't help
High school was a good choice
Tips
Work with schools to find students
Attend career fairs
Industry groups help
School to career committee for students who aren't planning on going to college.
Networking
Important: get coordinated within the company. Employment policies are unusual for this kind of arrangement - eg. hiring someone well below salary range and after 6 months give them a large raise to bring them up to the normal salary range. Not well understood by corporations.
The kids normally don't have resumes. Different hiring practices needed
how do you like to learn?
can you learn by working with another person?
why are you graduating from high school and not working?
past successes?
what technology are you familiar with (probably games)
long term goals (probably games)
Explain and agree on expectations. Explain salary - they start below the market level. Do 6 month reviews and salary review for 2 years. Not bound by HR guidelines. Short term goals must be clearly defined. Leave an escape route - pack to the pizza shop if it doesn't work. Long term goals - if you want to pursue college you can and our company would reimburse you.
"Contract" - failure is not an option. This is going to work. You have to accept the fact that you are not bringing in a qualified person. What you ask them to do is necessary. They are not put on useless projects. Differentiate between personal style and company policy. If this person moves to a larger organization, they should have experience in things that are normally expected. Work assignments must be meaningful. "Can you manage multiple assignments?" - hard question for kids to answer. It's an important issue since they may need some of your time to continue on one assignment when you don't have the time. They can switch assignments. Some assignments are aimed at their interests. Have a project path in place before you bring on the students. Start with less technical longer duration projects. There is more business input than technical input. Follow by a small utility they can do on their own.
Move into a small project for a few users.
Gradually increase complexity.
Design tasks introduced slowly.
Remove the nets and let them fly on their own. They may need to scrap small failures and try again.
Should have 6-8 weeks of work ready to give them. Prepare to give them coding on day 1 - they don't care about pension plans, etc. Use laptops that they can take with them. Keep them in their own library - they don't understand impacts on other parts of the system. Expect that they want to learn and won't stop learning. They may move much faster than you expect. Hard to get out of the comfort zone of things they know how to do. Don't understand competing interests. Less concern for traditional amenities. Student may not even realize how much he makes. More concern for technical amenities. More concerned about the kind of laptop he uses. Security risk - may have a hacker mentality. May see nothing wrong with pirating software. Problems with objects. They haven't had exposure to objects. It's hard to sell the value of objects. Reuse is unknown to them. The class library can be intimidating. Let some things get rewritten. Explain the business side of the business objects first. Then show objects used.
Working with Smalltalk
cookbook of scripts is useful. Sometimes they don't want to use it, sometimes they do
Introduce common objects. Some are very old so you may need to review it yourself ahead of time.
Critical elements of Smalltalk are hard to introduce (eg, blocks, events, collections, etc) - best to introduce them at the time they are needed rather than explain in advance.
Question their questions - why are they asking that question. Need to ask why they are asking the question.
Review their code frequently. Don't let them get too far along with something that's not right.
Introduce UML through documenting their own code.
Keep leading them with more and more difficult things.
Non technical learning required. They may need to travel but don't have credit cards.
Don't put them on accounting projects - hey, it's only off by 2 cents - it's good enough.
Work close by. Constant feedback. Keep everybody in the loop. Don't hide weaknesses. Everybody realizes that he'll mess up from time to time but you have to let him learn from it. Don't force classroom training.
Summary Had 4 kids do this. 4 successes. Kids still excited about coming to work!
Previous Topic
