Understanding Society User Support

Many thanks for your enquiry. The Understanding Society team is looking into it and we will get back to you as soon as we can.

Best wishes,
Stephanie Auty - Understanding Society User Support Officer

Dear Liam,

In general, it seems useful to stress that for much of the annual employment history module, there are two parallel streams of information, stored in parallel sets of numbered variables, but where one corresponds to work spells and one corresponds to non-work spells. A lot of confusion could be helped by bearing this in mind and cross-tabbing to see the conditions under which participants have a ‘not applicable’ for a given variable.

Cjob is a binary classification of currentness, specifically for the first job after the fed-forward job. This is why, if you cross-tab with some other things, you will see that people only have a positive (i.e., not inapplicable) value for it if the fed-forward activity is no longer current. There is a currentness flag for further activities after this, but from the second activity after the fed-forward one the naming convention changes. So for example at wave 4, the remaining currentness flags are variables with the names d_currjob1 - d_currjob6, going forward in time if these are employment spells, but d_currstat1 - d_currstat6 if these are non-employment spells. So for any pair of w_currjobn and w_currstatn, only one should have a positive (i.e., not inapplicable) value. You can check this by doing some cross-tabbing.

In contrast, there is only one variable called w_jbsoc00, i.e, this is not part of a repeated loop, because this picks up the SOC code only of the activity current on the day of the interview.
Empstendd contains information on the date when the fed-forward activity ended, whether this was an employment or non-employment spell.

Apart from for the small group already discussed in your previous question, either nxtst or nextstat should be asked to the participant but not both, such that apart from that small group nobody should have a positive value for both.

As stated above, w_cjob is a currentness flag for whether the first EMPLOYMENT activity after the fed-forward one is still current at the later interview, so the participant will only have a positive value for this where they have values of nxtst or nextstat corresponding to work activities. For where the first activity was a non-employment activity, the same information is contained in w_cstat. For the second activity following the fed-forward one, the corresponding currentness flag variables change to two numbered sequences of the form w_currjobn and w_currstatn.

Regarding the second problem you mention with nextstat, yes, for a handful of cases that happens. Specifically, this can happen when a) the fed-forward activity was an employment spell, and b) the person is doing either the same job for a different employer or a different job for the same employer, i.e. (jbsamr = 2 | samejob =2), and c) they answered ‘not current’ to w_cjob, meaning that in some sense they regard the job as having ended even though it either the same job for a different employer or a different job for the same employer. In this case, there is no information in the slot corresponding to the first activity after the fed-forward one, but there is information in the slot corresponding to the second, third activity etc. after the fed-forward slot. But this is really a vanishingly small proportion of cases, so you can decide what they want to do with this. This can be conceptualised as the fed-forward activity being in effect current until the start of the next activity for which you have a start date.

Whether feed forward variables are calculated from proxy or only full interviews can be very easily checked by merging the relevant files and cross-tabbing to see.

The UKHLS team member who has spent a lot of time working with this data and provided the information for this response would like to share with you the attached code, which is from her exploration of all of the discrepancies and complexities. It was specifically for BHPS participants at wave 4 but you should be able to adapt the code for the waves you are using.

Best wishes,
Stephanie Auty - Understanding Society User Support Officer

Dear Liam,

You can see the wording of the questions on the questionnaires, here: https://www.understandingsociety.ac.uk/documentation/mainstage/questionnaires

The questions are asked in the order listed in the questionnaire so it is possible to work out the sequence. If the first-listed question was applicable then the respondent would be taken through that loop until completed and then, if the second-listed question was also applicable, the respondent would then be taken through that loop as well until complete. If a respondent was routed into being asked a question that really does not apply to them interviewers tend to quit the loops as quickly as possible.

A quick check looping through the waves shows that at each wave, roughly 5% of people who went through the empchk loop were also sent through the notempchk loop. As a proportion of the whole sample, this is more like 2.5% per wave.

You are correct that the people in this group are not random. The reason why someone gets sent through both loops is if at the previous wave they offered conflicting information in a particular way – if they answered jbhas or jboff in a way which indicated they were working, but gave an answer for jbstat which indicated otherwise. Thus, they are likely to be people in slightly non-standard working situations. Depending on the research question that may be something of particular importance or interest, but it is up to you to decide how to reconcile this discrepancy. The UKHLS team member I mentioned in the previous reply lets jbstat take precedence, since that seemed to pick up a more long-term aspect of identity, rather than reflecting an odd job in the previous week.

If you want to check this, my colleague used the following code:
use d_indresp.dta, clear
merge 1:1 pidp using e_indresp.dta
count if e_empchk!=.
count if (e_empchk==1 | e_empchk==2) & (e_notempchk==1 | e_notempchk==2)
fre d_jbhas d_jboff d_jbstat
list d_jbhas d_jboff d_jbstat if (e_empchk==1 | e_empchk==2) & (e_notempchk==1 | e_notempchk==2)

Mismatches between ff_jbstat and previous jbstat can occur because the feed forward file is created on the basis of unchecked and sometimes incomplete interview data: A small number of interviews for the concluding waves are returned from the fieldwork after data collection for the new wave has commenced. E.g. if an individual was employed in Wave 1 (a_jbstat==1), and b_jbstat==4 in Wave 2 but their interview came in too late, at Wave 3, c_ff_jbstat will be 1 but their b_jbstat will be 4. It seems that the important thing for you is that ff_jbstat is the information that guided the routing in the questionnaire. It is not edited post-hoc to match the information that is provided in the last wave’s interview.

If anything is not clear it may be easier to discuss by telephone. Please let us know if you would like to talk about it.

Best wishes,
Stephanie Auty - Understanding Society User Support Officer