We are hiring a UX consultant, had a broadstrokes session with the company, liked their work, think the candidates are ok and now want a more concentrated interview with the specific UX consultant that will be embedded into the scrum team.
What questions should be asking that could weed out any dead weight candidates.
Thanks.
Ask Tog has a good Quiz. I'd also ask stuff on the Gestalt principles, but that's probably because I have a masters degree in HCI (as in that might be a bit academic). That said Gestalt principles are very important especially for things like Form design.
I guess also you could ask them what their favourite book on UX design are, if they can't list any that would be very odd to me.
Personal Experience A good UX practitioner should be taking an interest in the things they use personally. I would ask them what they use personally - obvious technology items like phone and websites, and also less obvious things like kitchen appliances and vending machines. If a UX candidate can't tell me what they observed in their day so far (e.g. the car or public transport they used to get to the interview), that's a good way to weed out the dead weight right there.
Practical Problems As with programming, the best way to assess someone is give them a real-world problem you're facing (or faced) and see how they deal with it. Their thought processes are more important than the answer.
I am a UI Designer/Developer and once I gave an interview to Verizon for UX Designer position. By the way, it was a phone interview. I never worked as UX Designer before. The person who interviewed me asked me about my past work experiences, skill sets and asked me if have contributed as UX designer before. With regards to technical question, he actually sent me a document which had some brief information (part of an application) and then a small interface (it was like a table with some graphic based information, and based on this information, the call center people would respond to user request). I was asked to study this table carefully and then i was given 24 hour timefame to suggest a changed table/design and was asked to explain why would i suggest those changes. Just by looking at that single page document, I didn't understand the problem itself and didn't know what to suggest. I spent 23 hours just looking at the problem and on the 24th hour I did make a suggestion and send them my reply. But didn't work ..... i never heard back from Verizon.
As a UI Designer, I have worked wiith lots of UX Designer and all I know about UX design is that you have to understand the problem very carefully. You need to look for all posible solutions and use the one that would best satisfies the usesr needs. And then you must know how to create wireframes.
Ask them how they would go about designing the UI for some system. Tell them to design a solution for some domain which you know well (for example one of your recent projects), so that in the interview you can take the role of the user. Then the UX consultant will need to dig the necessary requirements from you, find out what is the problem that needs to be solved, and then designing and testing a solution.
Or if you want to make it easier/quicker, use a domain that everybody knows, so that he doesn't need to dig the requirements from you. For example design a system for finding out in which of the nearby restaurants you would like to eat a dinner. In one hour you should get some understanding of what the consultant is like.
Give them some screenshots* of example pages from a selection of sites, some of which you consider good, some bad, and in varying degrees. Ask them to point out good and bad features in each (and there is some good and bad in every site) and explain their thinking. If they fail to spot something obvious, prompt them with a neutral "what about X?" and see how they analyse it.
* finding these isn't hard, but a little time consuming possibly. Even better if you can give them access to an actual browser so you can go over the "live" elements
UX work is made up of two parts: Research and Design. You need to be clear which you want most emphasis on: someone who can grok out massive taxonomies and build wireframes in their sleep, vs someone who has hundreds of hours of usability lab experience. (You can find people who have both areas of expertise, but people often lean in one direction).
Beware of UX consultants who have never been embedded in a scrum team before. They will need some bedding in time. If they are used to working agency-side rather than client-side, they will be used to doing shortish research projects and then leaving. This kind of "skirmish" is quite different to the long-view you have to take when working client side.
Related
How do I go about explaining that I am a "Web Application Developer" and not a "Web Site Designer" to prospective clients - without talking myself out of the project?!
Often I am approached to "design a web site" for someone where it turns out to be more of a "brochureware" presentation site and less of a real web application.
While I am a highly skilled developer, I am not a graphic artist. That said, I would still like to be able to close deals with prospects without disqualifying myself. Simply stating, "I do backend work, not frontend" will quickly end the conversation, and along with it my opportunity for work.
Sure, I can just subcontract the project to a real designer and mark up his rate, but I would rather be up front with the client that I am not going to be the guy doing the actual work and they would be paying $120/hr for $60/hr work.
...and then they will ask price - is visual design often quoted hourly like app dev is, or will I get sucked into the oblivion that is fixed fees?
First thought: You sound like you're a good developer, which is a great foundation in this situation because people feel that we have a broad understanding of technology -- and they're right! You're correct in your insecurity though - a good developer is not exactly what they're after.
They want a solution, and if you can become the guy who knows how to navigate all the complexities involved in delivering that solution... Well, then you're the guy. And you're much more valuable.
And you don't have to stop coding, either. Which has always been my phobia.
So that's more or less how I present myself to my clients. I'm a developer, but I'm also a competent project manager. I know how to take your project from here to done even though it may involve designers, IT guys, additional developers, datacenters, etc.
Working with other professionals: You probably aren't in a position to hire folks. That's fine, but find good partners, and you can market your self as a shop or consulting group that is good at more than one thing. Believe me, people will appreciate that! For instance, we have a fantastic partner in Romania that we use for a lot of design, and we add value because we know how to get results from them and handle all the communication and so on. My customers don't want to talk to 3 to 6 people, they want a single point of contact who is accountable for all of it.
One thought here: try to find people who do this full time. Moonlighters and people doing side jobs have constantly let me down. I sympathize; I know what it's like to be spread too thin.
Fixed prices: You will probably have to deal with fixed prices, and you will need to hold your partners to fixed prices (or have some other mechanismf or controlling costs) if that's the case. Once the relationship becomes more comfortable, I usually try to give clients a range of what I think a job will take -- 5 to 8 hours, etc. And I let them know that fixed prices are a little bad for them because I have to assume some risk, which means they get charged more.
Most companies still want actual fixed prices for larger projects though and many large companies are shockingly comfortable with being overcharged in this situation. Fixed prices seems to be unfortunate fact of life in the contract development space.
First of all, I think you're exaggerating a bit - you don't really want to have a $30/hour designer working on a $150/hour website. If you do, and your client doesn't notice a difference, they deserve what they get.
And if we're talking about, say, $60 - $75/hour range vs $150/hour (which, IMO, is more realistic), you have to count in the time you spend working with said designer, so it's not like remaining $75-$90 goes directly into your pocked with you doing nothing.
If I am a client, I want a FINISHED PRODUCT and I'm paying YOU to deliver. Consider yourself a general contractor. I DON'T WANT to deal with designer / tester / technical writer / what have you myself - that's what I'm paying you for. My time may be a lot more valuable to me than $90 / hour difference. I may (will) get a second / third / fourth bid if I think you're too expensive.
That said, if you need to placate your conscience you can always bill couple hours less.
I tend to say something along the lines of "My job is to develop the stuff you don't see, but that make your site work"... And that is actually quite true.
... And you might add something that says that building a website is an activity that requires several very different abilities, like :
creating something that looks nice, and is usable ; that's a job on its own ; do your client have designed to logo of their company ?
integrating this nice looking thing into a dynamic application ; that one is your/my job ^^ Your clients send/receive e-mails every day, but do they know how it works ?
administration of the hardware / server : your clients use a computer every day to go in the Internet, use Word/Excel and the like, but do they know how to install those ? How to secure their network ? How to deal with security alerts the right way ?
You can use analogies with other processes ; designing / building / using / repairing a car, for instance ; some people understand better when we just don't speak about computers at all...
The way I always try and explained it, since I'm a Developer not a Designer is.
Developer -> Makes it work.
Designer -> Makes it pretty.
Of course there are vest generalizations, but for the most part they're true.
-> Developers creates the product
-> Designers create the package
Do you bill enough hours that you could consider hiring a program manager/product owner type person at least part time to do most of your customer interaction? Because if you do, you can abstract the "design/code" questions away from the customer; let the program manager really focus on figuring out what the customer wants built.
It sounds like your average customer isn't that technically savvy. If that's the case, figure out a way to speak their language (which most experienced program managers can do). They really don't care about the difference between a designer, a developer, and a tooth fairy that shows up and delivers the site that they want.
It's also worth considering whether you really want to take on projects that are mostly web design. If not, you should work on improving your marketing materials to focus on what you do best (interactive line of business web applications, or whatever).
You can steer the conversation toward what business problem the customer wants to solve, and propose the statement of work that best matches their objective. I think this will do the most good, and then it's never a question of misleading them. It's about packaging up a solution that matches what they want.
"I do backend work, not frontend" will quickly end the conversation, and along with it my opportunity for work.
This is not necessarily a bad thing. It's generally a good idea to be honest with prospective clients, and if they do not understand exactly what your job entails up front, then they may end up expecting too much from you when the job is done, or for future projects.
If you do really want to push your services on them, you could always try to point out exactly what kinds of benefits you will be offering to them. Make a point in explaining how much value can be added to the end-product by using your expertise.
A car may look great on the store floor, but if its powered by a lawn mower engine held down with duct tape and chewing gum, the only thing it's going to be doing is looking pretty and collecting dust in your garage.
I know there was a study somewhere that showed which places users focused on initially when presented with new interfaces, but I can't remember that study, nor remember exactly what behaviors could be assumed for most users of your program.
From what I do remember, it came down that users often shoot towards the corners of a software application, looking for context to help them make their decisions on how to use the interface, but I don't know that as a hard fact, and would like to find some resource that outlines some of these common usability rules.
Does anyone know the study I'm talking about, or could cite any sources that describe something similar to the above?
This post discusses the focus of user attention in new interfaces.
Here is a related presentation on designing effective user interfaces.
Are you talking about things like this, with the classic 'F' pattern in using the web?
http://www.useit.com/alertbox/reading_pattern.html
My first response on reading this question is: What do you mean by initial? Do you mean the impression the user gets in the first second? Ten seconds? Ten minutes? There have been many eye tracking and "information grouping" studies done, but you can always fall back to the good old Gestalt principles ... people will group information and focus on what is most prominent.
Another good article from useit.com:
http://www.useit.com/alertbox/timeframes.html.
And there are a lot of good studies linked from there. =)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Suppose you're working on an enterprise project in which you have to get management signoff in order for you to develop a new feature set. Usually your management has no problem signing off on some bright shiny new UI feature. Unfortunately they have a hard time appreciating some behind-the-scenes issues that are crucial to the application's well-being such as transactions, data integrity, workflow routing, configurability, security, etc. Since they're non-technical and these issues are not immediately visible, it's not obvious to them that this is crucial.
How have you convinced them that these infrastructural issues have to be dealt with and that it is important to their business process?
Every craft has its unsexy sides. Things that HAVE to be done, but nobody notices them directly. In a grocery store somebody has to organize how and when to fill the grocery shelves so they always look fresh. In a laundry you need somebody who thinks about how the processes should be optimized so that the customer gets his clothes in time.
The tricky part is: The customer won't notice when these subtle things have been done right UNTIL HE NOTICES THEY ARE MISSING! Like when the laundry is not ready on time but two days late, or the veggies in the super market have brown spots and look terrible.
Same goes for IT. You don't notice good transactions until your major customer knocks on your door and tells you that an important and expensive project has failed because the database entries of your product were mysteriously mixed up. You don't notice good security until customer credit card information shows up in Elbonia (and soon after word is in the national newspapers warning customers of your company).
The thing you really have to hammer in again and again and again is that software is NOT static. It has to be cared for even after its initial development phase is over. It is not just a product you buy once and forget about. Every car manufacturer knows that services is of prime importance to the products they build, simply because things WILL occur that have to be fixed and improved. It's the same with software.
So make a presentation, visualize, verbalize, translate your technical information into benefits. Business people don't care about your wish for code aesthetics in a refactoring project, but they WILL understand that your changes will help the product to become more reliable, gain a better reputation and reduce the amount of future service requests. Make them understand by showing them the benefits!
Same thing folks have been doing for thousands of years: draw pictures. Diagram the problems, use visual metaphors familiar to your audience, drag the problem into their territory.
Assuming they're not being intentionally obtuse...
A big +1 for analogies and metaphors. If possible, find one that will resonate with the personal interests of your audience (if it's 1-2 people). For general metaphors, I often find myself using commuter traffic or subways, for some reason.
e.g. We are currently migrating an app from an OODB to Postgres/Hibernate: the bulk of this work is done in Release '4'. Many domain experts have been asking why there are so few user-facing features in R4. I regularly tell them that we have been 'tearing up the city to put in a subway. It is very expensive and undeniably risky, but once it is done, the benefits in R5+ will be astounding, truly.' The true conversation is more involved, but I can return to this theme again and again, well after R4. Months from now, I hope to say "You asked for X and it is now very easy -- precisely because you let us put in that subway back in R4".
The surest way to get upper level management to buy off on development work is to present it in a quantifiable way. Ideally this quantifiable measure is in $$. You need to explain to them the consequences of skimping on data integrity, security, transactions, etc. and how that will affect the customer\user community and eventually the bottom line. You should be careful in these situations because sometimes management expects these non-functional requirements to "just work." If this is the case, you should either estimate high and work on these items alongside the visible UI work (ignorance is bliss) or you need to document these areas of need as you communicate with management so if things do go bad as you anticipate, it's not your job that is on the line.
Unfortunately, it usually takes a disaster or two before this stuff gets the attention it deserves.
It really depends what your management is like, but I've had luck with good old honest-to-goodness fearmongering. If you go through a couple of disaster scenarios, and point out someone's going to get blamed if they occur, that can be enough to make their arsecovering instincts kick in and finally pay attention :)
Car analogies.
Everybody knows that 'system' and it's sufficiently complex to depict the dire situation.
I'm battling with essentially the same kind of situation. Whether it is sign-off by management or acceptance by a user/sponsor, the problem remains one of different vocabularies, priorities and perspectives. I asked a simmilar question here.
I also got diverse answers, tantalizingly close to useful, but not quite definitive enough. Browsing and searching SO using relevant keywords led me to find usable insights in various answers spread out over many unrelated questions. To find and extract these gems led me to pose this question on site-mining.
It would have been useful to be able to flag the various answers and see them all in a single list, but alas, that functionality is not yet available in SO. I suggested it on uservoice.
Hope you find something you can use from the references I gave.
The right kind of countering question is the secret.
Is it okay to crash every 5 web pages?
Do we have to protect the credit card numbers?
Is is okay to have to pay contractors to deploy a patch every weekend?
Did you want it now or did you want it to work?
Robustness. When it comes down to it, you need to talk their language, which is how it affects their bottom line. If its a security or correctness issue, you need to tell them that customers aren't going to want incorrectly acting products, no matter how nice they look.
I like the idea of Technical Debt, because it enables technical issues to be translated (albeit loosely) into money issues -- and money is something most managers do understand.
Although the idea of technical debt was originally applied to architectural issues, it can be used more broadly for any type of situation where there is pressure to take a shortcut -- that is, go into technical debt -- rather than do it right the first time. (Doing it right is the equivalent to saving up to buy something -- it takes time -- rather than buying it on credit and going into debt.)
Just as debts can be good (e.g. home loans) and bad (e.g. credit cards), so technical debt can be good and bad. I won't try to characterise the differences completely, but good technical debt can be tracked accurately, so that you know how much in debt you are.
So, try to explain your important, non-UI problem in terms of technical debt, and the cost of not fixing it in terms of paying interest on that debt.
A descriptive picture really helps non-technical people understand what you are talking about. For example, below is an example from Sun describing how information is processed in one of their somewhat complex applications.
(source: sun.com)
Trying to explain this application in words would be impossible to a non-techy. Pointing at the diagram and say look, this part is our weak point, we need to improve it. That will make sense to them. If they feel like they have some understanding of what you are doing, they will be far more willing to support your request.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
A (non-technical) friend of mine has asked me how to make a website. I get this question all the time. After a few questions I found out that she has an idea that could turn into a commercial site. I described three options to her:
a) Get a book/enroll in a class/follow some online tutorials and learn how to do it. She's pretty smart and her personality seems like a good match for this sort of thing so I'm sure she could learn but she doesn't have a lot of time spare. Maybe if she started with one of those WYSIWYG editors at first? I stressed that this would take a longer than a couple of weekends of playing around.
b) Hire someone to build it. Ranges from ultra cheap to ultra expensive, crappy to good and everything in between. I didn't mention sites like Rentacoder because she hasn't worked on a project like this before and doesn't know what to ask for. At this stage she'd likely ask for a Youtube-MySpace-Google for a few hundred bucks because she doesn't yet understand just how much is involved.
c) Find someone technical and partner up with them. I explained that this can either work really well or be a disaster because she'd have to give up some of her ownership of the idea.
How do you respond in these situations?
Depending on the nature of the required website (ie whether she needs shopping carts etc) I often recommend first creating a blog, although it's often not the best format, it can be used to quite good effect at times. I've seen a number of small retailers for example, using a blog to advertise their wares.
It depends on the person and their motivation. Your friend sounds like she should take option b) or c). She's probably not so much interested in the technical aspects of making a web site as she is in seeing her idea come to life, or maybe running her own company based on the idea.
Well in general there are several steps:
Determine the subject of the website.
Determine the target audience.
Decide on a general layout and look and feel.
Decide which techniques to use.
Design the overall structure of the site.
Collect content and images.
Implement the site.
Most of the times, these steps are carried out by more than a single person. Because they all require their own specialization.
I think that the only realistic options are B and C. Non-techies will almost never come to grips with real web site development. With all due respect to those who have advocated technologies such as ASP.NET or PHP - it won't work. In fact, you are likely to be fielding questions for weeks on end as to why things don't work. You'll have to bear these questions until the person, having failed, gives up.
If they have the resources, then I would strongly recommend the "hire an expert" route.
In either realistic case, they must get a legal agreement in place. If she does hire an expert, be sure that the agreement expressly stipulates that this is a "work for hire". If your friend doesn't demand a work-for-hire clause then she will have no legal means to stop the developer from using the exact same code she just paid for in creating a competing site (at least in the U.S.). Just to emphasize: they would have no legal means to prevent the developer from starting their own competing site without a work-for-hire clause - the courts won't even hear the suit.
Now, if it is really just a brochure site or something similar, and they still want your advice, then it depends on whether they use a Mac or something else.
If they are a Mac user, I tell them to try booting up iWeb and using it to feed a .me account. Just plug in some pictures and some text, upload to your .me account and you are done.
If they are a Windows user, I direct them to Register.com or a similar online Web Site template-based site builder.
For your sake, don't volunteer to help unless you are really sure you have the time to essentially build the whole thing for them! You can ruin friendships this way: friends and family, having no clue what really goes into the construction of a site, almost invariably assume that it is "trivial" for you. If you delay or fail to get things done quickly enough, they'll almost always assume that you are blowing them off and they'll resent you for it (can you tell I've been there?).
It depends on how confident she is that this thing will succeed or, alternatively, how unwilling she is to share ownership. I'd definitely not recommend (a) for something that has commercial value. Beyond the time-to-market factor, initial impressions are something that is very hard to overcome. If she has the cash and is possessive of ownership, then (b) could work well. It's a bigger financial risk, though.
I'd probably go with (c), but then again I'm on the other side of the equation. There are lots of ways of structuring a partnership that would help her maintain ownership, though probably not complete ownership since no one wants to work for nothing. Some combination of b/c is probably best - some less pay in exchange for a small stake in the business. I'd definitely see a lawyer before doing (c) and maybe even before doing (b) just to make sure any agreement she has with the developer precludes them taking the code and running.
There are really two questions here: should she learn how to write a website and, if so, how.
If she has a commercial idea and she only wants to learn how to write websites to market it, I would suggest that she does not bother. Outsource instead.
If you have someone who to trust then only 3rd option is realistic. first one takes years to give out good result and with second one you never know what you get.
Buy her a book for her birthday on ASP.NET or PHP.
A bit of topic but here it goes...
We have ONE web designer at our company(we are about 10 programmers), we usually make some jokes like: "You do not work, you just sit there making drawings all day long" (just for the record, she is very competent and does her job pretty well).
So one time she stares at my monitor for about 2 minutes while i am working on a web application, and at some point she says: "Sooo that's what you do? Formulas and stuff?".
From that day on we all say "I do formulas and Stuff" when asked for what we do at work, as for most people, saying that and saying you develop web applications is the exact same thing.
Developing a web site is not as trivial as places like GeoCities or Google Pages would make it appear.
Here is a list of things you need to know about or consider when publishing a site.
If she owns a Mac or doesn't mind to acquire one, I would suggest her to have a look at iWeb. Otherwise, starting a blog on a platform such as blogger would be a nice first step for a non-technical person.
I always give the same answer, HTML. I say what it does and then tell them to get a book. If they get what it is about they will follow their own course of action.
Unless you're a web designer, 'how do I make a website' is a similar question to 'how do I make a television'. You don't, you buy one. So this question is probably 'How do I procure a website?'.
This breaks down into:
Working out what you want:
What user features do you want
What do you want the UI to look like?
What admin features do you need?
Do you already have a graphic design/logo/color scheme, etc.
Finding someone to make it for you
How do you find them? Referrals? Local web dev companys? Friends?
Do you care which technology they use?
Are you going to project manage it?
How do you know they're doing a good job?
Are you clear on issues like scaling, support, maintenance?
Ideally, find a single company who is comfortable helping you work through all the issues. Less ideally but also good, find a consultant or company that will help you with the top level stuff and assist with production of technical specs that you can then take to a development company to produce.
(Edited for formatting)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Does anyone have any suggestions on how to mentor a junior programmer ? If you have mentored someone did you follow any process or was it quite informal ?
If you've been mentored in the past what kind of things did you find most helpful ?
Try to set aside between 30-60 minutes a day to review their code together. If you can't do this, then try to get together to review their code whenever they make a code commit, unless it was very basic. Have them explain why they chose the approach they took in lieu of others. A process like this helps to establish a great relationship, as well as really stimulate the student to think on their own and be able to defend their decisions. Not only does the student end up with someone approachable whom they can trust, but you'll notice an improvement in their quality of code and logic almost immediately.
Edit: Also, If you are unable to commit this much time to co-review with your junior, then you probably shouldn't be mentoring them and instead see if anyone else has a schedule that would allow it. The whole point of mentoring is to actively aid in the professional development of the student, and they're not going to learn much if proper attention and guidance is not given to them.
I had the chance to work as an intern (one of two) in a small software company and had the opportunity to work on an "almost new" project they had. They had me set up with everything needed and gave me an introduction into what the project actually was (basic stuff like what the requirements were etc).
At first we got to do minor tasks like researching things that mattered to the project (they had given us a list of topics). This was, I think, to see how much we could handle ourselves, as the things we needed to look up and research were not that trivial and it took a good 2 weeks or so (counting the basic demos we had to create for it). That testing phase was actually done really without much 'coaching'.
However, after that period we could work on the actual project itself. This was also the moment we began to be coached together, in a similar style to pair programming, except there were three of us (2 interns and 1 'coach').
We learned a lot from him, but it was in an informal manner, and he didn't act like the 'all-knowing-listen-to-me' guy. When we had suggestions he would listen and think through with us whether they were any good. or give his view on why an idea should not be done in that way... Now that I think of it, he actively encouraged us to make suggestions, and to think about better ways to do things, instead of just sitting there 'taking orders' from someone who probably knows what to do better then you.
So in short:
Let the junior programmer work (mostly) on his own to study the materials at hand, give him a list of minor TODO things like looking up information, or building small demos.
Check the work he has done regularly and advise him if there are better ways to do things. Also point out the items he actually did well, that way he'll remember those for later.
Let him work on a real project, and mentor him by working together at the same project, giving him advice when he has questions.
The effort has to come from both directions: encourage him to ask questions, to challenge 'the way it is currently done'. Ask him questions on how he thinks it should be done and give him your opinion as well.
Make it 'enjoyable' - don't let it look like you are giving orders.
During an internship w/ a large company that had a lot of in house IT, I was paired w/ a mentor. The practice definitely aided my career development, both in terms of technical skills and business skills. Here are some of the reasons the mentoring worked out so well:
Credible: The mentor had 8+ years of experience and an accomplished background to draw upon in leading and training. He'd been through different challenges, worked in different environments, so he had a great perspective.
Genuine: The mentorship was encouraged by the supervisor, but not so formal as to make it an exercise in going through the motions. The mentor wanted to mentor, and I wanted someone to learn from.
Passion: The mentor loved the field he was in, the problems he was solving, and the technologies he was using. When I came under his wing, I found this to be infectious.
Sharp and Articulate: The mentor approached issues critically and framed them concisely. There wasn't a lot of fuzziness in our discussions; we got to the root of the matter and he directed me on wise courses of problem solving and action.
Meaningful: The work I was doing w/ the mentor was meaningful work, not just an exercise to keep busy or ramp up in a skill set. By jointly working on a task that tangibly aided the organization, that helped focus my interest and legitimize the mentoring process.
At my first place of employment there was this really patient dude that would always help me solve my immediate problem, and then teach me some important underlying principle. I loved this because he would help me stay productive while teaching me how to become a better programmer.
I'd be the junior, I guess :) I think I'd value an informal approach. It probably depends a lot on your and your mentee's characters, but I'd say that you learn best if you don't have egos in the way. Break the ice, make sure there's feedback in both directions. Things like code reviewing (both ways?) and occasional pair programming may work, and if there's a good match, it may be a lot of fun, as well!
Because I had to explain why I wanted to co-op (besides needing the money) during my interview, my manager made sure my first project allowed me to work on what I had identified as weak areas: very little Linux experience (I chose a Linux-only R&D team so I would be forced to learn), not knowing a useful text editor (I really wanted to learn Vim), and how to learn another programming language (very different approach than learning a language as you learn to program). He told me I was being paid to study for a while.
I learn best by reading books, so after chuckling over Unix for Dummies (yay! I wasn't the only one who thought this was obscure and knuckleheaded sometimes) I started with Unix in a Nutshell and Sobell's Practical Guide to Linux Commands. After that I printed out the Vim documentation and started going through it. Then I looked through a couple books on Python, the language of my first project. I was given all the time I needed to feel comfortable about these things (which was the real problem, as I now understand) and then began adding functionality to a previous co-op's project.
I realize now it would have been terrific to meet with someone every day or two for code review, as Kamikaze Mercenary said.
In my experience, when mentoring someone, it is very important for the mentee to really WANT to learn more.
Never ever spoon feed them. Instead point them towards things of value and have them utilize the new information they are learning in projects that they are using. Knowledge is useless if not put into practice. So encourage your mentee to code, code, code.
Here would be my short list:
Pair programming - This is helpful for many things, like reinforcing various ideas and practices. Getting used to Resharper is much easier when you pair with someone that uses it often.
Informal chats - This is where we would go get a drink, go outside for someone to have a smoke break, go for lunch together, etc. While away from the desks, the discussion may be related to work immediately being done or it may be abstract philosophical stuff that can help bring someone's game up a notch or two. Talking about various upcoming technologies or changes in what coming can be exciting and help form bonds as well.
Feedback and suggestions - This is what occured in both above cases. Books like "How to Win Friends and Influence People" by Dale Carnegie can help in understanding various human relationship dynamics, which while that sounds quite technical is really just about how to motivate someone else in various ways. A key point here is to know how to leave a trail of breadcrumbs to pick up some practices, like giving hint after hint about something rather than just give the answer. I have had various Math teachers that had a gift for this for how I developed some of this skill.
So part of this is merely motivating the other person and trying to guide them as when someone figures something out for themself it can be an empowering and enlightening experience. The, "I did it! That's right, moi, yours truly!" kind of self-talk is quite nice when it happens.
Ask them what would they try next to complete the task. This can give an idea of where from the "I don't know what to do" to "Well, I would try this but..." category are they in terms of having their own idea that may be useful for a starting point.
Take a quick look at what they want to do and offer hints so that they figure out the problem. This is rather than give the answer of, "Just take out this line of code," suggest they look at what is there and is it all necessary
I would recommend start giving parts of real assignments you have and make everything to be able to use his code. In other words train him as replacement for yourself.
This way you will commit yourself to allocating time to work with junior and he will be able to see "real life". By working on real assignments and hearing lively feedback he will be able to get p to speed rather quickly.
Drawback of this approach is that it is possible that it will have too narrow focus on you particular project. So be sure to show the trainee possible alternatives and encourage trade-offs analysis to widen his professional horizon.
Couple of years ago I worked for a small company, where on the first day I was given a list of small task to complete - do some little changes in code, find and fix a small bug in the project. It really helped me to ask the right questions from my mentor and familiarize myself with the environment, the code base. These tasks were easy to complete, so I had a little bit of self confidence, before turning to the bigger tasks.
This way of mentoring really worked with me very well, so I am planning to do the same with our new colleague.
I have mentored several junior people under me before. My approach varied slightly based on the person a bit based on how they learned.
In short, I gave the junior people small, self-contained projects when I could and gave them a relatively fixed time to complete the task. Once the task was complete I would review their approach, code and solution and made suggestions for improvements or a better way to handle the problem. I think this way they don't feel overwhelmed being part of a much larger project.
Hope this helps a bit.