How to Give Job-Winning Answers to Interview Questions

This post is copy from

Human Resources personnel, professional recruiters and various other career experts all agree: one of the best ways to prepare yourself for a job interview is to anticipate questions, develop your answers, and practice, practice, practice.

There are plenty of websites that offer lists of popular job interview questions, and knowing the types of questions to expect can be very useful. But knowing how to answer those questions can mean the difference between getting the job and getting the “reject letter.”

How to Answer Questions

First, know these important facts:
1. There is no way to predict every question you will be asked during a job interview. In other words, expect unexpected questions–they’ll come up no matter how much preparation you do.

2. Treat any sample answers you find, such as in discussion forums, books or on Internet job sites, as guides only. Do not use any sample answers word for word! Interviewers can spot “canned” answers a mile away, and if they suspect you are regurgitating answers that are not your own, you can kiss that job goodbye. You must apply your own experiences, personality and style to answer the questions in your own way. This is crucial, and it will give you a big advantage over candidates who simply recite sample answers.

3. Job interview questions are not things to fear, they are opportunities to excel. They allow you to show why you are the best person for the job, so instead of dreading them, look forward to them! The key is to give better answers than anyone else, and that’s where your preparation comes in.

Now, take these actions:
1. Make a list of your best “selling points” for the position. What qualifications, skills, experience, knowledge, background, personality traits do you possess that would apply to this particular job? Write them down and look for opportunities to work them into your answers.

2. In addition to any sample job interview questions you find through various resources, you absolutely must develop your own list of probable questions based specifically on the job for which you are applying. Put yourself in the hiring manager’s shoes� what kinds of questions would you ask to find the best person for this job?

3. Write down your answers to likely questions. Study the job announcement carefully. (If you don’t have one, get one!) Note the phrases they use when describing the desired qualifications. You’ll want to target these as much as possible when developing your answers. For example, if the announcement says they want someone with “strong customer service skills,” make sure you include “strong customer service skills” in at least one of your answers. That will make a better impression than saying “I helped customers.”

4. Review and edit your answers until you feel they are “just right.” Read them over and over until you are comfortable that you know them fairly well. Don’t try to memorize them; don’t worry about remembering every word. Practice saying them out loud. If possible, have a friend help you rehearse for the interview.

Here are some more very important tips:

1. Be a (Short) Story Teller
Make use of this old marketing tip: “Facts tell but stories sell.” During a job interview, you are selling yourself. Whenever possible, answer questions with a short story that gives specific examples of your experiences. Notice I said “short.” You don’t want to ramble or take up too much time; you want to be brief but still make your point.

For example, imagine two people interviewing for a job as a dog groomer are asked, “Have you ever dealt with aggressive dogs?” Candidate Joe answers, “Yes, about 10% of the dogs I’ve groomed had aggressive tendencies.” Candidate Mary answers, “Oh yes, quite often. I remember one situation where a client brought in his Pit Bull, Chomper. He started growling at me the moment his owner left, and I could tell from his stance he wasn’t about to let me get near his nails with my clippers. I think he would’ve torn my arm off if I hadn’t used the Schweitzer Maneuver on him. That calmed him down right away and I didn’t have any problems after that.” (I know nothing about dog grooming; I made the Schweitzer Maneuver up for illustrative purposes.)

Don’t you agree that Mary’s answer is better? Sure, Joe answered the question, but Mary did more than that–she gave a specific example and told a quick story that will be remembered by the interviewers.

In today’s job market where there are dozens of highly qualified candidates for each opening, anything you do that will make you stand out and be remembered will greatly increase your odds of getting hired.

2. Keep the Interviewer’s Perspective in Mind; Answer His “What’s in it for Me?” Question
While many questions asked during job interviews appear to focus on your past accomplishments, here’s an important tip: they may be asking about what you did, but what they really want to know is what you can do now, for them.

The key is to talk about your past accomplishments in a way that shows how they are relevant to the specific job for which you are interviewing. Doing advance research about the company (such as at their website or at and the position will be extremely helpful.

Here’s another example with Joe and Mary. The interviewer asks, “What is the most difficult challenge you’ve faced, and how did you overcome it?” Joe answers with, “In one job I was delivering pizzas and I kept getting lost. By the time I’d find the address, the pizza would be cold, the customer would be unhappy, and my boss was ready to fire me. I overcame this problem by purchasing a GPS navigation device and installing it in my car. Now I never get lost!” Mary answers, “In my current job at Stylish Hounds, management ran a special promotion to increase the number of customers who use the dog-grooming service. It was a bit too successful because we suddenly had more customers than we could handle. Management would not hire additional groomers to help with the workload. Instead of turning customers away or significantly delaying their appointments, I devised a new grooming method that was twice as fast. Then I developed a new work schedule. Both efforts maximized productivity and we were able to handle the increased workload effectively without upsetting our customers.”

Joe’s answer shows initiative and commitment (he bought that GPS gadget with his own money, after all). But Mary’s answer relates specifically to the job they are applying for (dog groomer). And Mary had done research about the company and discovered it was about to significantly expand it’s dog-grooming operations. So she picked an example from her past that addressed an issue the interviewer was likely to apply to a future situation in his company. See the difference?

Here’s one more example. Joe and Mary are asked, “What’s your greatest accomplishment?” Joe answers, “I won two Olympic Gold Medals during the 2000 Olympics in the high-jump competition.” Mary answers, “I was named Stylish Hounds’s Dog Groomer of the Year in 2003 for increasing productivity in my section by 47%.”

Joe’s accomplishment is pretty spectacular. But remember the interviewer’s perspective. He might be impressed, but he’s thinking “What’s in it for me? What does being a world-class high-jumper four years ago have to do with helping me to increase sales in my dog-grooming department?” Mary’s answer is much less spectacular than Joe’s, but it’s relevant to the position and indicates that she has what it takes to be successful in this particular job. It tells the interviewer, “I have what you’re looking for; I can help you with your specific needs.”

Looks like Mary has a new job!

3. Do Not Lie
Last but not least, tell the truth. It’s sometimes very tempting to “alter” the truth a bit during a job interview. For instance, say you quit instead of being fired. But the risk of being discovered as a liar far outweighs the potential benefit of hiding the truth.

If you are thinking about telling a lie during the interview, ask yourself these questions (this technique has helped me make many major decisions): “What is the best thing that could happen? What is the worst thing that could happen? Is the best thing worth risking the worst thing?” In this instance, the best thing would be getting the job. The worst thing would be getting discovered as a liar, which could lead to getting fired, which could lead to unemployment, which could lead to more job searching, which could lead to another interview, which could lead to the stress of deciding whether to lie about just getting fired, and so on� a cycle that can go on indefinitely. Is all that worth getting the one job, perhaps on a temporary basis?

Always consider the consequences of your actions.

In Summary, Here’s What You Need To Do When Preparing To Answer Job Interview Questions:

1. Study the job announcement.

2. Research the company.

3. Anticipate likely questions.

4. Prepare answers to those questions that are relevant to the position and the company.

5. Promote your best “selling points” (relevant qualifications, capabilities, experience, personality traits, etc.) by working them into your answers.

6. Practice. Practice. Practice.


美国面试的问题基本上都是behavioral questions(简单的说就是让你举例子),尤其是在第一轮面试,根本不涉及任何技术性问题,不管你应聘什么样的职位。这也许和那些对技术性及专门知识要求比较强的工作面试有所不同。通过behavioral questions,面试者主要想要了解的是应试者的软性技巧 (soft skills), such as communication skills, personal skills, self-promoting skills and personalities etc. 根据这些了解,面试者给出几个判断:应试者的工作经验和skill set是不是fit这个职位,这个人的沟通技巧是不是足够好,这个人的性格是不是fit公司的文化,是不是一个和同事能team work的人等等。

面试,尤其是第一轮面试,通常是半个小时到一个小时。在这么短的时间里,面试者的考察当然不可能全面,有时甚至是很主观。所以在面试的短暂的时间里,最重要的是展现出自己最适合这个工作的特质,无论是hard skills(经验)还是 soft skills. 有时候,真实的你,真实的话,不一定讨喜,人家不一定愿意听。Fortunately, 越是大公司,越是正规的公司,面试的形式越程序化,越rigid, 所以只要好好准备,摸清了美国公司面试的套路,面试本身就不再是一个可怕的东西。


1。回答不要啰里啰嗦,没有structure, 没有重点,give too much details。如果一个问题你的回答超过3 – 5 分钟,你就已经死翘翘了。

2。认真听考官的问题。当答完一个问题时,不管答得如何,赶快move on。If you are not sure about the question, ask the interviewer to clarify it.

3。借一本专门指导如何面试的书。 图书馆里有很多种这样的书。先找一本薄一点的,简单一点的,你可以在短时间里读完的。目的是读过以后,你会有一个general idea关于职业面试的概念。然后分析你的具体情况,如果有必要再去找针对性强一些的书或内容。 推荐 “55 Interview Traps”。这本书只有60多页,言简意赅,有很多例子,可读性强。”55 Interview Traps”的下载网址是:。上面一些techniques 在拿到offer的面试中特别有用。一本general interview book 加上 Interview Traps应该可以对面试有一定academic的认识了。剩下的主要任务是do your homework about company research, work on your stories and sharpen your story-telling skills.

2)如何回答behavioral questions?

前面说过behavioral questions是在美国的职业面试当中最常见的形式。通常是面试者抛出一个问题,让你从你的经验当中举出例子。而从你给出的例子当中,面试者得以对你的skills和personalities加以了解和判断。有工作经验的人,尤其是工作时间比较长的人,当然最好举你工作当中的例子。对于那些没有工作经验的人,可以举在学校和同学做project的例子,参加学校社团活动的例子,在community做 volunteer 的例子。


Tell me about your self.

Leadership example

Teamwork example

Project management example

Problem-solving example

Taking initiative example

What’s the most difficult decision you’ve made recently?

Why are you interested in this position/this company?

What do you see yourself five years later in this organization?

关于leadership,我们国人的概念是leader就是领导,就是有一定权力的人,有下属汇报的人。但要知道,有的人在领导的位置上,不一定就有leadership,而有的人不在领导的位置上,但他或她可能在工作当中表现出很好的leadership的素质和能力。英文这个所谓的leadership很抽象,很难具体化。但是,leadership can be demonstrated in different ways.

For example, sometimes, a leader needs to be a change agent. When you initiate something new to change the common practice or the status quo, you have to rationalize your ideas, convince others, motivate them to change, and overcome various obstacles etc. In this case, you are in a leadership role.

Another example. Sometimes, it’d be more difficult to lead people and have them work in concert when they are not reporting you. In my case, as an Export Sales Manager in charge of export sales to China, Japan and Korea, I need internal production, processing and logistic teams to work with me and to insure the production is in place on time, the product quality meets my customer’s requirement and the shipments to my customers are on time. It takes leadership and teamwork skills to get the job done.

Leadership can also be demonstrated in crisis management, for example, when there is a quality problem with your company’s products that may potentially cause a huge loss or negative publicity to your company or your customer. It takes leadership to act fast and decisively, so that the situation would be remedied and the potential damage would be minimized.

Leadership can be also demonstrated when you successfully carry out a project under the challenging timeline or with limited resource, or when you take initiative, identify a potential business opportunity and bring a new revenue stream to the company.

最主要的是不要把leadership理解的很教条和僵化。美国人可以把小小的或看似简单的事情给安上一个漂亮的名字。就象project这个词。只要是有这么一件事情,有一定的objective, 需要人力物力在一定的时间里完成,都可以称之为project. 你完成个作业都可以是个project. 所以你没当过领导不要紧。大家把自己的工作经历和人生经历好好想一想,找出关于leadership的例子应该是不难的。

关于teamwork的问题,有很多varieties. 面试者可能有不同的方式发问。比如:

Give me an example how you work with a team to solve a problem/carry out a project

Give me an example that how you encourage your team members to do their jobs.

Give me an example that how you deal with resistance in a team.

想提醒大家的是,这些例子之间不是mutually exclusive。你可能有一个例子,which may fit different settings, such as leadership, teamwork, project management, problem-solving or initiative-taking. 你也有好几个不同的例子可以展示同一个quality。一般来说,你需要准备至少8 – 10 个例子来回答我列出的这几个topics.

除了Tell me about yourself 这个问题,the most commonly used structure/format to answer behavioral questions is STAR – Situation, Task, Action and Result.

一般来说,对每个问题的回答得控制在2-3分钟以内。在这很短的叙述例子的过程中,你的重点应该是强调Action 和Result,这是面试者最关心的部分。所以在时间分配上,对于Situation和Task你要非常简洁地一笔带过,交代清楚大概的背景就可以了。关于Result, 尽量用数字或百分比来表示。

如果原来工作的行业比较特殊,在面试当中常犯的一个严重错误就是在举例子时,没有把那些行业专业词换成人家能懂的,通用的词。因为人家听不懂,就试图想和人家解释,结果陷入给太多details的泥潭,纠缠在描述Situation 和Task上出不来。一个例子别说2-3分钟,就是5-6分钟也唠叨不清。

所以当你面试的工作是跨行业的,你一定要遏制住欲望,使用那些你耳熟能详的原行业的词或term。人家听不懂至少有两样坏处:听不懂,就没兴趣听了。而且还留下一个印象:你的经验离面试这个行业太远,你不fit。 不管是那种,你的面试已经完了。最好把你所有的例子写下来,严格按照STAR的形式写,然后反复斟酌记忆。有可能的话,找老美改下,要那些写作好的老美改。老美当中也不是每个人都擅长business writing的。面试的时候,千万不要让人感觉你在面无表情的背书。模仿老美讲话,抑扬钝挫,眉飞色舞。

很重要的一点是,你的例子不能用大白话写和说,要用professional business language来写和说。整个面试考察很重要的内容就是你的communication skills. 因为就算你成绩好,技术好,水平高,但你不擅长用business language 来沟通和交流,你的communication skills不好,sooner or later, 你的事业发展会受阻,尤其是在美国,这个非母语的国家。

记得有这样一句话,写得很好。”In business, communications are not only the way that we express ourselves, but also, more importantly, the way that we work with people.”

但如何提高自己的business communication skills 呢?

比如,随身带一个小本子。在日常学习中,读到任何一篇business的东东(可以是课本,case,报纸,公司的宣传材料等等),听到学校讲座里请来的那些公司头头任何一句讲话,只要觉得在我面试当中可以利用上,就把它记下来。现在在面试当中说得很多话,都可以学人家的,靠平时这样积累下来。 俗话说,好记性不如烂笔头。只有记下来,有空就看看,不知不觉你就记住了,那些professional business language就变成了你自己的了,到用的时候就可以随手拈来,运用自如。你如果注意观察一下那些成为公司executive的人,没有一个讲话没有水平的。如果有机会听他们讲话,可以观察他们的谴词造句,他们讲话的structure, the logic behind their speeches,还有他们的body language。还可以在各种场合观察美国人怎么interact, 怎么chitchat。这些技巧不管是在面试当中,还是将来工作当中,都是非常重要的interpersonal skills.

总结下,准备应对面试的那些behavioral questions,是临上轿才扎耳朵眼儿的事情。而提高business communication skills,对于在美国打拼的中国人来说,是需要constant, persistent and life-long efforts,需要learn smart and work smart,才能在美国的职场立于不败之地。

Tell me about yourself


但是你有没有想过,既然你简历上已经把你的经验也得很清楚了,why bother面试者要你再复述一遍?所以说,面试者肯定希望听到more than what your resume tells。 他们通过你的叙述,除了工作和生活经验之外,最想知道的是在你made every each transition along the way,是什么原因使你做这个决定的。比如,你换了个工作或行业,why; 你选择来美国读书,why; 你选择读MBA,why?有些公司不错,在问这个问题之前会告诉你,他们对你做的每个决定后面的原因感兴趣。有的公司根本就不告诉你,但他们会expect你在你的回答中告诉他们。

在回答这些原因的时候,you need to be very careful, you need to selectively choose a reason that would make sense from the interviewer’s perspective, not necessarily from your perspective.

在短短几十分钟的面试里,很重要的一项考察内容是soft skills。所以,如果可能的话,在陈述你做过的每一个工作时,简单的summarize what soft kills were developed。如果你有一个很好的progressive track record,随着你的职位升高,你的responsibilities变化,你可以向面试者展示在每个不同阶段你培养的不同的soft skills.

要强调的是,除了谈到你的responsibilities, 千万别忘了讲到results,tangible results。Again,

最好把结果量化,用数字或百分比。用百分比有个好处,有时你的成绩,如销售或节约的成本,合成具体金额可能不那么impressive, 但换算成总销售或总成本的百分比可能就听起来比较厉害。

还有,回答Tell me about yourself,时间最好控制在5-6分钟,不管你有再长的工作经验。就算你有10年的工作经验,你也得在5分钟里面把它讲完。这就需要你用的语言非常concise,需要很好的structure, 需要很流利地把它讲出来。试想,你如果吭吭巴巴,5分钟哪里讲得完。如果你做了若干个工作,但其中一,两个对你的事业发展起到重要的作用,或那些工作经验最接近你现在面试的这个,你需要highlight them,对于其他不重要的可以简单的说一下。

最好就是把你的回答写下来,反复研究修改,使的你的回答达到最简洁有力的程度,需要你大声的读出来,背下来。建议录音,自己听听,有发音问题的让别人纠正下,计算时间,别超时了。有条件的话穿的整整齐齐录像,最能看出自己的各种毛病了。可以和朋友,有经验的人,边看边讨论。俗话说,当局者迷,旁观者清。要不耻下问,不要怕丢丑,旁观者往往能看出你看不出的毛病。这个练习方法也适用于其他behavioral questions。


I would like to thank everyone for being here and interviewing me. I am going to give you a presentation about my resume.

My name is ~ ~. I got my bachelor degree at XXX University, a top-10 university in China. My major was Japanese. It’s funny that I ended up in the US, instead of Japan.

I got my first job at N Company, which was a top-10 Japanese international trading company. I was working as a sales representative dealing with import/export business between China and Japan. This job brought me a great learning opportunity. I learned how to work with different people, such as importers, exporters, suppliers and customers in both counties. I learned how to negotiate with them, and how to close a deal. My communication and interpersonal skills were developed greatly. During 3.5 years, the business I was in charge of grew from 1.5M to 5M. Then, it reached a point, where I felt that import/export business was too broad and general. I wanted to go to an industry and gain specific industrial knowledge and expertise.

D Corporation presented me with a wonderful opportunity, where I could not only utilize my import/export experience, but also have greater responsibilities, such as strategic implementation and market development. I was reporting directly to the Asia Pacific VP. Since he was based in the U.S. and only visiting China 5-6 times a year, most of time, I was working on my own. It takes initiative, self-management and self-motivation to get the job done. From 1995 to 1999, I successfully implemented strategic plans, commercialized five products in highly regulated markets, recruited five exclusive distributors, and developed a strong distribution network. Sales grew from half million US dollars to 3.4M.

Due to my significant contribution to the company’s bottom-line, I was promoted again from China Office Manager to Export Sales Manager in charge of export sales to China, Japan and Korea. I was transferred from Beijing Office to the company’s headquarters in IL. In the meantime, D Corporation was acquired by M Company. We all became M’s employees.

As an Export Sales Manager, m

How to Prepare for a Behavioral Interview

  1. Study the job description for the position for which you’re interviewing.
  2. Visit the organizations website to gain an understanding of what type of candidate the organization is hiring.
  3. List the personal and professional attributes of the ideal candidate for the job.
  4. Think about which of your experiences can be used to illustrate you have these personal and professional attributes.
  5. Make up questions that demonstrate you have each of these attributes. Behavioral questions usually start with phrases like “Describe a time” and “Tell me about a situation” which force the interviewee to talk about specific experiences.
  6. Develop two or three stories for each personal or professional attribute, using experiences from your past to show you have each attribute.
  7. Try to use the SAR technique to tell these stories. Describe the Situation you were in or problem you were facing at the start of the story. Describe the Action you took or took part in as a result. Then describe the Result of your actions. Spend less time on the Situation and more time on Action and Results. This is what the interviewer cares about.
  8. Practice answering the behavioral interview questions you invented, using the stories you created, so your stories become second nature.

Behavioral Interviews Made Simple

This post is copied from

There are a lot of different ways to conduct an interview.

Some people use the same fixed list of questions for every candidate, others take a more casual go-with-the-flow approach.

Some interviewers are experienced and trying to make you squirm, and others might be more nervous than you are and appreciate you taking control of the conversation.

No matter who you’re talking with, though, you’re likely to get some form of a question that asks you to talk about something you did in the past that will pertain to the job at hand.

These are called behavioral interview questions, and they are probing for specifics about how you handle something the company thinks will be important in that job.

Behavioral questions usually begin by with a phrase like “Tell me about a time when…” or “Describe how you handled a situation when…” and then give you a chance to share about something you’ve done in the past that will give an idea of how you’d do in the job at hand.

Is the behavioral interview dead?

Someone in one of my LinkedIn groups recently put forward a thought that behavioral interview questions were dead. I completely disagree.

Any interviewer worth their salt will ask a candidate to talk about what they’ve done in different situations.

What you did in one situation is a very good indicator of what you’ll do when presented with a similar situation.

Asking someone “What would you do if…” can be helpful to see how someone thinks they might handle something, but asking them for a specific story about a specific situation in the past lets you see how they actually handled it. Behavioral interview questions aren’t going anywhere.

What are some behavioral interview questions?

These are open-ended questions asking you to share something that will show the employer how you’ve handled situations they believe are similar to theirs. For example:

  • Tell me about a time when you had a great deal of pressure and not enough time to get everything done, and how you handled it.
  • Have you ever been in a situation where you didn’t have enough work to keep busy? What did you do?
  • Give me an example of how you set goals and objectives, and how you keep track of your progress.
  • Describe a time when you had to make a difficult decision, and how you made the decision and got other people on board with your choice.
  • Have you ever had a difficult situation with a boss? How did you handle it?

How can you prepare for behavioral interview questions?

One of the challenges of preparing for these questions is that you don’t know exactly what they’ll be asking you about. But that’s OK, because you can prepare a few stories that you can then modify to suit different types of questions.

Here is how to prepare:

1. First, make a list of your key stories from your career.

Begin by making a list of five or six of the most interesting and challenging things you’ve done. This will become your story foundations, to use over and over again.

Did you help convert a software system in the middle of the year, and have to handle everything that went wrong? Did you join a company in financial trouble and have to manage a discouraged work force back to productivity? Are there special projects in your experience that you want to talk about?

2. Once you have your key accomplishments listed, prepare some stories about them to illustrate your ability to solve problems and get things done.

For instance, you can talk about how you recruited others to help with the software conversion, and got your manager to give you budget for hiring extra help. Or you can make notes of how you approached the situation when you realized your new boss had fired the last five people in your job, and you didn’t want to be the sixth.

3. Review the job description and the company to look for hints about what might be important to them.

If the posting really emphasizes attention to detail, make sure your stories show how you notice all the little things. If it emphasizes being able to quickly adapt, make sure you have a story about needing to change direction quickly.

4. Then script your stories out with three parts: situation, action and results.

First, give a sentence that talks about the situation and the challenge you were facing. Next, say what the actions were that you took in that situation, and finally, give the results of your actions.

Make it short and sweet to begin, and leave yourself open for more questions if the interviewer wants you to go deeper with your answer.

5. Adapt the same stories for different situations, and add or subtract details of the specifics.

As an example, here are three different questions, and you can see how the same answer could work for both:

  • Behavioral Question: Tell me about how you have set up a new office from scratch in the past.
  • Behavioral Question: Describe a situation with extremely high expectations, and how you met the challenge.
  • Behavioral Question: Give me an example of how you set goals and meet your objectives.

Answer: When I joined ABC Company in 2004, the CEO was working out of her home and there was no office at all yet. We had a very short timeline and a very limited budget. I called some of my commercial leasing contacts from my previous job, and got leads on several companies who’d had cutbacks so had surplus office space to rent out temporarily. By keeping a very detailed list of what needed to be done, and using my contacts and knowing where to get the best services for the best price, I had us in new quarters within six weeks, including being online, with phones, comfortable desks and all the basic services running.

You can see how you could easily adapt that answer to a question about a demanding boss, a pressing deadline, using contacts to get things done, or many other scenarios. By adding or deleting a few words, you can customize your answer to their question, while still using one of your foundational stories about your work experience to illustrate your abilities.

The behavioral interview question is alive and well, and with a little pre-planning, you’ll make the most of your answer and impress the heck out of the interviewer.

Multithreading with Core Data on iOS

This post is copied from

A while ago I recommended not to multithread at all with Core Data. That was true during Snow Leopard’s days. But with the advent of context hierarchy and the pervasive use of blocks on Lion and iOS 5, multi-threading with Core Data becomes approachable.

As I was working on Resonate, I discovered a number of lessons on writing multithreaded applications on iOS. A lot of these lessons were discovered “the hard way” – through misguided attempts and many crashes. I’d thought I share this with you so that you don’t need to go through the same mistakes.

Even though I use the word “multithreading”, chances are you won’t need to deal with threads directly. Using operation queues is the way to go for most of your multiprocessing mechanisms. Simply package your algorithms into distinct units of work and then let NSOperationQueuemanage them for you. Don’t create NSThread instances directly unless you have a pretty damn good reason why.

Use UIManagedDocument for Core Data apps on iOS.

Really, when you’re writing iOS 5 applications that uses Core Data, you’ll want to use UIManagedDocument. At a bare minimum, use this class to manage your Core Data stack. That is, let core data manage your instances of NSManagedObjectContextNSPersistentStoreCoordinator, and other parts of the Core Data stack.

Even if you need to share your Core Data classes with your Mac app, you can still separate your entity classes that will work accross both platforms. If you think that UIManagedDocument isn’t good enough for your app, you’d better have a damn good reason why.

When you use UIManagedDocument, you’ll get a set of interrelated NSManagedObjectContext instances. Amain context that you use as per normal with your GUI objects and the root context, which is the main context’s parent that are used for asynchronously saving data to persistent storage. When dealing with object contexts created by UIManagedDocument you should not save them directly – you’ll bypass undo management and a lot of other behind-the-scenes stuff. UIManagedDocument will periodically save these for you in the correct order.

Use the managed object context hierarchy

From this building block, I go further to recommend a pattern for using the new context hierarchy. I discovered this works nicely on iOS when I was working on Resonate.

  • Use the root context for saving data obtained by network refreshes.
  • Use the main context for GUI components and others that needs to be in the main thread.
  • Create individual worker contexts as children of the main context for background data processing tasks.

Core data context use

Use the Root Context for Network Refreshes

Being a Twitter client, Resonate often need to ask Twitter for the latest tweets and other data. When Twitter returns and Resonate parsed the resulting JSON data, it then invokes the root context’s operation queue to store the parsed JSON data into managed objects.

You can use this pattern yourself. You run network operations asynchronously, parse the resulting data, and then when you’re ready to store it you call performBlock on the root context.

You can see the pattern in the sequence diagram below. Typically the user initiates the refresh from an action in the view controller. If you use ASIHTTPRequest for your network I/O, you can make it run asynchronously. When the request is complete, you pass the raw data into an operation queue for parsing (note that +[ASIHTTPRequest sharedQueue] is convenient for this). When the data is parsed, you make use of the root context’s private queue to update the data to your managed objects. Upon completion of the update, you pass the object IDs of the updated objects back to your view controller in the main thread. Please take care not to pass the actual managed object instances between operation queues as this will certainly cause problems.

Network Refresh Pattern

One caveat of this approach is that you need to separate network-sourced data with user-edited data. That is attributes that can be updated from the network should not be editable by the user. This is to prevent conflicts when UIManagedDocument tries to saves your contexts.

Use Multiple Child Contexts for Worker Queues

If you need to do some long-running data processing, you should run those in a background operation queue and not in the main thread. But really to make your app responsive, anything that may take longer than half a second should be taken off the main thread – especially important in iOS devices where the CPU is a lot slower than the one found in OS X machines.

Those background operations should use their own private NSManagedObjectContext instances. I also recommend that these contexts are set as children of the main context. Why? Because when the operation completes and the context is saved then the results are “pushed” into the main context. This also rescues the GUI from having to refresh its NSManagedObjectContext to get the updated objects. Since you create these contexts yourself, you are responsible for saving them – unlike the main and root contexts that are owned by UIManagedDocument.

How to use it? Refer to the interaction diagram below. Typically the view controller creates the worker operation class (which is an instance of NSOperation). As part of the worker’s initial setup regime, the view controller provides its context as the parent context for use by the worker object. Then when the worker starts it creates its own private NSManagedObjectContext instance and use that context as it’s scratchpad data store. Just before the worker completes, it saves the context to push its changes to the main thread’s context.

Core Data for Background Processing


You now know how to multi-thread effectively in Core Data applications. Although this article focuses on iOS, you should be able to apply the same principles to OS X. You have learned about:

  • Using UIManagedDocument for managing your Core Data stack
  • The new NSManagedObjectContext hierarchy (nested contexts)
  • How use each level in the context hierarchy for different operation types (network refresh, main/GUI thread, worker operation).

Multi-Context CoreData

This post is copied from

When you start using CoreData for persisting your app data you start out with a single managed object context (MOC). This is how the templates in Xcode are set up if you put a checkmark next to “Use Core Data”.

Using CoreData in conjunction with NSFetchedResultsController greatly simplifies dealing with any sort of list of items which you would display in a table view.

There are two scenarios where you would want to branch out, that is, use multiple managed object contexts: 1) to simplify adding/editing new items and 2) to avoid blocking the UI. In this post I want to review the ways to set up your contexts to get you what you want.

Note: I am wrapping my head around this myself for the very first time. Please notify me via e-mail about errors that I might have made or where I am explaining something incorrectly.

First, let’s review the single-context setup. You need a persistent store coordinator (PSC) to manage talking to the database file on disk. So that this PSC knows how the database is structured you need a model. This model is merged from all model definitions contained in the project and tells CoreData about this DB structure. The PSC is set on the MOC via a property. The first rule to remember: A MOC with a PSC will write to disk if you call its saveContext.

Consider this diagram. Whenever you insert, update or delete an entity in this single MOC then the fetched results controller will be notified of these changes and update its table view contents. This is independent of the saving of the context. You can save as rarely or as often as you want. Apple’s template saves on each addition of an entity and also (curiously) in applicationWillTerminate.

This approach works well for most basic cases, but as I mentioned above there are two problems with it. The first one is related to adding a new entity. You probably want to reuse the same view controller for adding and editing an entity. So you might want to create a new entity even before presenting the VC for it to be filled in. This would cause the update notifications to trigger an update on the fetched results controller, i.e. an empty row would appear shortly before the modal view controller is fully presented for adding or editing.

The second problem would be apparent if the updates accrued before the saveContext are too extensive and the save operation would take longer than 1/60th of a second. Because in this case the user interface would be blocked until the save is done and you’d have a noticeable jump for example while scrolling.

Both problems can be solved by using multiple MOCs.

The “Traditional” Multi-Context Approach

Think of each MOC as being a temporary scratchpad of changes. Before iOS 5 you would listen for changes in other MOCs and merge in the changes from the notification into your main MOC. A typical setup would look like this flow chart:

You would create a temporary MOC for use on a background queue. So allow the changes there to also be persisted you would set the same PSC on the temporary MOC as in the main MOC. Marcus Zarra put it like this:

Although the NSPersistentStoreCoordinator is not thread safe either, the NSManagedObjectContext knows how to lock it properly when in use. Therefore, we can attach as many NSManagedObjectContext objects to a single NSPersistentStoreCoordinator as we want without fear of collision.

Calling saveContext on the background MOC will write the changes into the store file and also trigger a NSManagedObjectContextDidSaveNotification.

In code this would roughly look like this:

dispatch_async(_backgroundQueue, ^{
   // create context for background
   NSManagedObjectContext *tmpContext = [[NSManagedObjectContext alloc] init];
   tmpContext.persistentStoreCoordinator = _persistentStoreCoordinator;

   // something that takes long

   NSError *error;
   if (![tmpContext save:&error])
      // handle error

Creating a temporary MOC is very fast, so you don’t have to worry about frequently creating and releasing these temporary MOCs. The point is to set the persistentStoreCoordinator to the same one what we had on the mainMOC so that the writing can occur in the background, too.

I prefer this simplified setup of the CoreData stack:

- (void)_setupCoreDataStack
   // setup managed object model
   NSURL *modelURL = [[NSBundle mainBundle] URLForResource:@"Database" withExtension:@"momd"];
   _managedObjectModel = [[NSManagedObjectModel alloc] initWithContentsOfURL:modelURL];

   // setup persistent store coordinator
   NSURL *storeURL = [NSURL fileURLWithPath:[[NSString cachesPath] stringByAppendingPathComponent:@"Database.db"]];

   NSError *error = nil;
   _persistentStoreCoordinator = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:_managedObjectModel];

   if (![_persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:storeURL options:nil error:&error]) 
   	// handle error

   // create MOC
   _managedObjectContext = [[NSManagedObjectContext alloc] init];
   [_managedObjectContext setPersistentStoreCoordinator:_persistentStoreCoordinator];

   // subscribe to change notifications
   [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(_mocDidSaveNotification:) name:NSManagedObjectContextDidSaveNotification object:nil];

Now please consider the notification handler which we set as target for whenever such a didSave notification arrives.

- (void)_mocDidSaveNotification:(NSNotification *)notification
   NSManagedObjectContext *savedContext = [notification object];

   // ignore change notifications for the main MOC
   if (_managedObjectContext == savedContext)

   if (_managedObjectContext.persistentStoreCoordinator != savedContext.persistentStoreCoordinator)
      // that's another database

   dispatch_sync(dispatch_get_main_queue(), ^{
      [_managedObjectContext mergeChangesFromContextDidSaveNotification:notification];

We want to avoid merging our own changes, hence the first if. Also if we have multiple CoreData DB in the same app we want to avoid trying to merge changes that are meant for another DB. I had this problem in one of my apps which is why I check the PSC. Finally we merge the changes via the provided mergeChangesFromContextDidSaveNotification: method. The notification has a dictionary of all the changes in its payload and this method knows how to integrate them into the MOC.

Passing Managed Objects Between Contexts

It is strictly forbidden to pass a managed object that you have gotten from one MOC to another. There is a simple method to sort of “mirror” a managed object via its ObjectID. This identifier is thread-safe and you can always retrieve it from one instance of an NSManagedObject and then call objectWithID: on the MOC you want to pass it to. The second MOC will then retrieve its own copy of the managed objects to work with.

NSManagedObjectID *userID = user.objectID;

// make a temporary MOC
dispatch_async(_backgroundQueue, ^{
   // create context for background
   NSManagedObjectContext *tmpContext = [[NSManagedObjectContext alloc] init];
   tmpContext.persistentStoreCoordinator = _persistentStoreCoordinator;

   // user for background
   TwitterUser *localUser = [tmpContext objectWithID:userID];

   // background work

The described approach is fully backwards-compatible all the way down to the first iOS version that introduced CoreData, iOS 3. If you are able to require iOS 5 as deployment target for your app then there is a more modern approach which we shall inspect next.

Parent/Child Contexts

iOS 5 introduced the ability for MOCs to have a parentContext. Calling saveContext pushes the changes from the child context to the parent without the need for resorting to the trick involving merging the contents from a dictionary describing the changes. At the same time Apple added the ability for MOCs to have their own dedicated queue for performing changes synchronously or asynchronously.

The queue concurrency type to use is specified in the new initWithConcurrencyType initializer on NSManagedObjectContext. Note that in this diagram I added multiple child MOCs that all have the same main queue MOC as parent.

Whenever a child MOC saves the parent learns about these changes and this causes the fetched results controllers to be informed about these changes as well. This does not yet persist the data however, since the background MOCs don’t know about the PSC. To get the data to disk you need an additional saveContext: on the main queue MOC.

The first necessary change for this approach is to change the main MOC concurrency type to NSMainQueueConcurrencyType. In the above mentioned _setupCoreDataStack the init line changes like shown below and the merge notification is no longer necessary.

_managedObjectContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSMainQueueConcurrencyType];
[_managedObjectContext setPersistentStoreCoordinator:_persistentStoreCoordinator];

A lenghty background operation would look like this:

NSMangedObjectContext *temporaryContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType];
temporaryContext.parentContext = mainMOC;

[temporaryContext performBlock:^{
   // do something that takes some time asynchronously using the temp context

   // push to parent
   NSError *error;
   if (![temporaryContext save:&error])
      // handle error

   // save parent to disk asynchronously
   [mainMOC performBlock:^{
      NSError *error;
      if (![mainMOC save:&error])
         // handle error

Each MOC now needs to be used with performBlock: (async) or performBlockAndWait: (sync) to work with. This makes sure that the operations contained in the block are using the correct queue. In the above example the lengthy operation is performed on a background queue. Once this is done and the changes are pushed to the parent via saveContext then there is also an asynchronous performBlock for saving the mainMOC. This again is happening on the correct queue as enforced by performBlock.

Child MOCs don’t get updates from their parents automatically. You could reload them to get the updates but in most cases they are temporary anyway and thus we don’t need to bother. As long as the main queue MOC gets the changes so that fetched results controllers are updated and we get persistence on saving the main MOC.

The awesome simplification afforded by this approach is that you can create a temporary MOC (as child) for any view controller that has a Cancel and a Save button. If you pass a managed object for editing you transfer it (via objectID, see above) to the temp context. The user can update all elements of the managed object. If he presses Save then you save the temporary context. If he presses cancel you don’t have to do anything because the changes are discarded together with the temporary MOC.

Does your head spin by now? If not, then here’s the total apex of CoreData Multi-Context-ness.

Asynchronous Saving

CoreData guru Marcus Zarra has shown me the following approach which builds on the above Parent/Child method but adds an additional context exclusively for writing to disk. As alluded to earlier a lenghty write operation might block the main thread for a short time causing the UI to freeze. This smart approach uncouples the writing into its own private queue and keeps the UI smooth as button.

The setup for CoreData is also quite simple. We only need to move the persistentStoreCoordinator to our new private writer MOC and make the main MOC be a child of this.

// create writer MOC
_privateWriterContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType];
[_privateWriterContext setPersistentStoreCoordinator:_persistentStoreCoordinator];

// create main thread MOC
_managedObjectContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSMainQueueConcurrencyType];
_managedObjectContext.parentContext = _privateWriterContext;

We now have to do 3 saves for every update: temporary MOC, main UI MOC and for writing it to disk. But just as easy as before we can stack the performBlocks. The user interface stays unblocked during the lengthy database operation (e.g. import of lots of records) as well as when this is written do disk.


iOS 5 greatly simplified dealing with CoreData on background queues and to get changes flowing from child MOCs to their respective parents. If you still have to support iOS 3/4 then these are still out of reach for you. But if you are starting a new project that has iOS 5 as minimum requirement you can immediately design it around the Marcus Zarra Turbo Approach as outlined above.

Zach Waldowski pointed out to me that using a private queue concurrency type for “editing view controllers” might be overkill. If you use NSContainmentConcurrencyType instead on the child view controllers context then you don’t need the performBlock wrapping. You’d still have to performBlock on the mainMOC for saving.

The confinement concurrency type is “the old way” of doing contexts, but that doesn’t mean it’s legacy. It simply ties the operations of the context to a self-managed threading model. Spinning up a private queue for every new view controller is wasteful, unnecessary, and slow. -performBlock: and -performBlockAndWait: don’t work with the confinement concurrency type for a reason, because neither blocks nor locking are necessary when you’re doing multiple contexts in the way that you are in the “editing” view controller setup.

NSManagedObjectContext knows how to save and merge intelligently, and because the main thread context is bound to the main thread, its merges are always performed safely. The editing view controller is bound to the main thread just like the main view controller; the only way it’s a separate operation is just in a UI sense, which is why it’s appropriate to use the confinement concurrency type here. The editing context isn’t conceptually a “new” thing, it’s just deferring the change until later, while still allowing you to discard the changes entirely.

So it really boils down to your personal preference: private queue with performBlock or confinement concurrency without. Personally have a tendency to prefer private queues because of the warm fuzzy and safe feeling I get from using them.

Problems with nested contexts

This post is copied from

When Mac OS X 10.7 and iOS 5 were released, I was so excited about the new features in Core Data. The additions of explicit concurrency types, nested contexts, and iCloud syncing promised to make developing with Core Data even more delightful. After evaluating these features, our team decided that we were going to use them in the next major release of one of our apps. Unfortunately (as is sometimes the case), some of these features aren’t quite ready for prime time.

Today I’m going to discuss nested context support in Core Data and various issues that exist with them. Some of these issues are minor bugs. Others may be considered functionally correct by the Core Data team, but result in unexpected behavior. Regardless, they add up to nested contexts being a feature you should avoid completely (as of this writing).


So what are nested contexts anyway? To avoid a very lengthy explanation, I’m going to start by assuming that you understand the Core Data stack. Nested contexts allow you to set up a managed object context so that it accesses data from a parent context instead of from a persistent store. If you request an object from a managed object context that has a parent context, Core Data will first look in the parent. If the parent context has that object in memory, you’ll get a new managed object just like that one. So if there are changes in the parent, you’ll get the changed version of the object. If the object doesn’t exist in that context, it will keep going up through parent contexts until it finally fetches the data from the persistent store. Basically, retrieving data goes all the way up through all ancestor contexts. Saving, on the other hand, doesn’t traverse up through parent contexts — it only saves one level up. All of this is pretty well explained elsewhere, so I’m going to leave it at that.


Throughout the last 9 months, we’ve been using nested contexts in an attempt to simplify and improve some of the data processing that we do in our personal finance application, Koku. It feels like at every turn we’ve been finding issues in Core Data where nested contexts are to blame. Many of these issues are a bit difficult to explain because there is a lot of setup required to reproduce them. With that being said, here is what we’ve found so far:

Child contexts block ancestors

This is one of the most fundamental problems with nested contexts. When I was first told about this through some friends in Chicago, I didn’t believe it. Basically, when you execute a fetch request in a child context, it blocks the parent context while performing the fetch. What does this mean? Well it means that you can’t really use nested contexts to solve a lot of concurrency issues.

Here’s an example: you have a bunch of objects in your database that need to be fetched and have time-intensive code executed on them. The following code looks like it would solve your problems:

NSManagedObjectContext *asyncContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType];
[asyncContext setParentContext:mainContext];
[asyncContext performBlock:^{
    // create fetch request, execute, and do work

But executing that fetch request blocks the main context. Assuming that main context is running on the main thread, then this also makes your application stop responding.

I’ve commonly heard people using this setup for importing from some type of service. And this is where things start to get bad. Let’s say you’re importing a bunch of JSON objects and you need to check if each already exists in Core Data based on an identifier. You write code that loops and checks for an object in Core Data with that identifier, then creates a new object from the JSON data if it doesn’t exist (yes, that could be optimized). It may look like everything is going fine because your UI is still responsive through most of that import (especially if you’re reading from a stream since there will be a delay between each ID check). The truth is, though, that every time you check for an object with an identifier, you’re blocking your UI. It may only be for a fraction of a second, but no one is expecting this.

Now this in itself is not really a large problem. Once you understand it, it’s just another part of the framework that you work with/around. The real problem is that nothing in the documentation indicates that this will happen. In fact, the release notes read:

This pattern has a number of usage scenarios, including:

  • Performing background operations on a second thread or queue.
  • Managing discardable edits, such as in an inspector window or view.

Right there in the release notes, Apple is telling us to use nested contexts to do work in the background. But you absolutely should not use them for that. They will block the parent.


Making changes into a parent context can be slow

Sometimes the cost of making changes in a child context is outrageous. Simply changing a boolean value on a bunch of objects can be prohibitively slow. It seems that Core Data tries to do something while processing pending changes on the child context. A reasonable assumption is that Core Data is trying to negotiate changes between the two contexts. All we’ve been able to determine is that there’s a lot going on with dictionary lookup that can hang the app. Everything takes far longer than if you were doing the same thing in a context that was tied directly to a persistent store coordinator.

Fetch results are wrong in a child context

It’s possible that fetch requests will not return the right results. I cannot even begin to understand how nested contexts got released when something this fundamental is broken. (Ok, so it’s broken in a very specific way, but still.)

Here’s how you can get Core Data to return the wrong results: set up a nested context relationship just like they describe for UIManagedDocument. For those who are unfamiliar, this involves an asynchronous context that is connected to the persistent store coordinator. The main queue context sets its parent to be this asynchronous context.

With the contexts set up, create a new object. Let’s imagine this object represents a blog and its variable name is awesomeBlog.  Add a couple of articles to that blog. Now if you were to set up a fetch request for all of the articles with a predicate of [NSPredicate predicateWithFormat:@"blog = %@", awesomeBlog], you’d get back the right results. But if you save the main context and then the async context (so the data is actually persisted to the disk) and try executing that fetch request, you would get no results. And it doesn’t matter if you set up the fetch request before or after you persist the data. You’ll never get the right results. Without nested contexts, this works just fine!

There is a workaround for this issue. You can simply obtain a permanent ID for the object when you create it. But there is a catch. The async context (at least in the case of UIManagedDocument) exists so that you can write data asynchronously. By getting a permanent ID for each object you create, you’ve made it so that you’re doing synchronous writes more frequently.

Oh, and as an added bonus, everyone who uses UIManagedDocument will experience this bug.

This has been reported as fixed for an upcoming release of iOS (which means the same should be true for Mac OS X).

radar://11891033 fixed in an upcoming release

Cannot access relationship in a child context for unsaved objects

This is pretty similar to the issue above in that it deals with relationships of objects that have been created. The difference is in the context setup and that it doesn’t really involve saving.

Here’s what can happen: let’s say you’re working in a managed object context called mainContext. It doesn’t need to have a parent context; it can be hooked up directly to the persistent store. Insert a new object into that context. Let’s call it a blog again. Add a few articles to that blog. Now, create a new managed object context and set it’s parent to mainContext. We’ll call this new context editing context. It’s another one of those common workflows that Apple documented in the release notes for nested contexts — discardable edits. But here’s what happens: when you access your blog ineditingContext, it has no articles.

The workaround for this is the same as the last one. Just obtain the permanent ID of the object beforehand. This has also been reported as fixed for Mac OS X 10.8 Mountain Lion (which means the same should be true for iOS 6).

radar://10209854 fixed in an upcoming release

Sorting is not honored when there are changes in a parent context

Sort descriptors are important, right? Well they don’t seem to always matter when you’re using nested contexts. If you have changes in a parent context and you execute a fetch request in the child, sorting does not work. Mix that with some of the above issues and you may get out of order, incomplete results. Yikes!

NSFetchedResultsController deadlocks

You never want your application to deadlock. With NSFetchedResultsController and nested contexts, it’s pretty easy to do. Using the sameUIManagedDocument setup described above, executing fetch requests in the private queue context while using NSFetchedResultsControllerwith the main queue context will likely deadlock. If you start both at about the same time it happens with almost 100% consistency.NSFetchedResultsController is probably acquiring a lock that it shouldn’t be. This has been reported as fixed for an upcoming release of iOS.

radar://11861499 fixed in an upcoming release

Crash after obtaining permanent IDs

A few of the issues above could be worked around by getting the permanent ID of an object. This can actually lead to a crash in certain circumstances, though. Again using the UIManagedDocument setup, create a new main queue context, editingContext, off of the existing main queue context,mainContext. Create a new object in editingContext. Save editingContext. Obtain a permanent ID for the same object in the mainContext. Core Data will eventually crash when cleaning up resources no longer in use.

radar://10480982 fixed in an upcoming release

Wrapping Up

If you made it through all of those, you’ve probably come to the conclusion that nested contexts are currently something to avoid. If not, the bullet points alone may have been enough to cause some unease. And these are only the issues that we’ve experienced. I wouldn’t be surprised if there are more. In discussions with peers, I’ve found that there are many people who are discovering some of these same issues and finding ways to work around them individually. I hope this list helps you make an informed decision about using nested contexts before you go down the same road we did. Also, please consider filing duplicate radars for those that are listed above. If you have anything to add to this list, please reach out to me on twitter or send me an email.

Thinking back over the lifetime of Core Data, it’s pretty unfortunate to see so many problems with the recently introduced features. I remember back when Core Data was released that SenTestingKit was just making its way into Xcode. At some point, Apple used Core Data as a poster child for unit testing. They claimed they were able to tune and enhance the performance in Core Data, making it screaming fast because of the comprehensive tests that they wrote. Whether this was marketing or not, the framework has been pretty solid throughout the years. The issues that have cropped up with nested contexts (and don’t even get me started on iCloud) feel like huge oversights and problems that fall nicely into the comprehensive test coverage category.

With all that being said, nested contexts are such a wonderful idea that could simplify architecture issues that so many developers using Core Data face. I look forward to the day that they work flawlessly and we get to start using them to make the next generation of data backed applications.

Update 2012.08.08: Updated information on radars. Update 2012.09.16: Updated information on radars.