Skywest
Holding
Joined APC: Jan 2012
Posts: 208
I know of at least three 5-6+ year FO types, 4 year degree, ~6k tt. Clean civilian backgrouns, all hired by UA in the last few months. I wouldn't count on it by any means, but it is starting to happen. They all hit the job fair circuit pretty hard and had things going on outside of line flying.
As far as commuter FOs in ORD, I can't say for sure, but I think the bottom 50% of FOs in ORD are there temporarily just waiting to transfer out to another domicile. Of the remaining top 50% I get the feeling that most live in the Chicago area.
Also, once you hit the 50% seniority range the pairings in ORD get wayyyy better.
just past ETP
Joined APC: Sep 2012
Position: Cruise Captain
Posts: 495
oh no, I'm fine... I work for a legacy now, and furloughed from another one... just shocked at how much things have changed from when I had to have 1000TPIC to even interview at AA back in the late 90's.
Personally glad to hear it as I have a friend whom I want to see succeed and she lacks a lot of those requirements that I though were hard and fast.
Personally glad to hear it as I have a friend whom I want to see succeed and she lacks a lot of those requirements that I though were hard and fast.
Nothing in this industry is "hard and fast" anymore, things are changing on an almost daily basis. HR is becoming less important as it's "formula" is shown to be less than ideal.
In a year or 2, hiring will be done by phone and "poaching" from other Legacy carriers will start as well. UAL has had LUV guys in class already.
In a year or 2, hiring will be done by phone and "poaching" from other Legacy carriers will start as well. UAL has had LUV guys in class already.
Line Holder
Joined APC: Mar 2014
Posts: 72
Also, anyone in ORD notice 166 lines for 165 pilots this month. PBS doesn't even show a 'RESERVE' link to bid.
just past ETP
Joined APC: Sep 2012
Position: Cruise Captain
Posts: 495
Nothing in this industry is "hard and fast" anymore, things are changing on an almost daily basis. HR is becoming less important as it's "formula" is shown to be less than ideal.
In a year or 2, hiring will be done by phone and "poaching" from other Legacy carriers will start as well. UAL has had LUV guys in class already.
In a year or 2, hiring will be done by phone and "poaching" from other Legacy carriers will start as well. UAL has had LUV guys in class already.
The world economy is already starting to show signs of another economic slowdown (China being in the lead) and while oil is still cheap, that won't last either as supply and demand match up.
Give it two years and who knows what will be happening... I remain cautiously optimistic.
Gets Weekends Off
Joined APC: Sep 2006
Position: ERJ CA
Posts: 1,082
Other than my Mesa classmates are starting to be awarded upgrades...no, no regrets. Talked to a buddy there last night, my paychecks on 1st yr pay here are bigger than his on 2nd yr pay there, and I have yet to break guarantee.
The NavTech PBS engine Mesa uses is the same one Delta and Hawaiian use, only without the graphical interface (costs extra). So you build up a list of commands that the engine runs through in order when the bid is run, and can organize them into as many groups (or "layers") as you want, limited by a max of 200 command lines total. While the learning curve is steep, being a programmer in my former life I mastered it pretty quickly and built some pretty complex bids (see sample at bottom). Here are a couple examples where the NavTech PBS was more flexible:
More control over movement between "layers". NavTech's bid groups work basically the same as layers here, but I had more control over how the software moved between them. For instance, if I had days off that were essential and some that were optional, if it couldn't build a line based on my preferences in that "layer", I could tell it to drop the prefer-off for the optional days and loop through my set of bid preferences again to see if it can build a line without those optional days off. I could take those optional prefer-offs out incrementally or all at once. If it couldn't grant my essential days off within the constraints/properties I'd set for that "layer", I could force it to move on to subsequent "layers", gradually lifting the constraints/properties and/or waiving contractual limitations like "min 2 days off between pairings" "no same day pairings" or "1 day off in 7" along the way.
More control over report/release times. Say I were trying to bid for commutable trips. I could tell it to give me trips with report times after 2 pm and release times before 5 pm. If that didn't work, I could loosen up my report and release times either separately or together. If that didn't work, I could tell it to give me trips commutable on one end or the other, or a couple of back-to-back trips that taken together are commutable. And I could do all of this all within the same "layer".
For the morbidly curious, here's a sample of one bid group/layer out of a bid from last year. The NavTech system would go through that list of commands in that order (which I could change). If it couldn't find any trips that satisfied every condition in a given line, it'd move on to the next line (and so on) until it had build a complete line for the month that reached the credit window. Some of this I can do with SKW's PBS. A lot of it I can't (or haven't figured out how yet).
More control over movement between "layers". NavTech's bid groups work basically the same as layers here, but I had more control over how the software moved between them. For instance, if I had days off that were essential and some that were optional, if it couldn't build a line based on my preferences in that "layer", I could tell it to drop the prefer-off for the optional days and loop through my set of bid preferences again to see if it can build a line without those optional days off. I could take those optional prefer-offs out incrementally or all at once. If it couldn't grant my essential days off within the constraints/properties I'd set for that "layer", I could force it to move on to subsequent "layers", gradually lifting the constraints/properties and/or waiving contractual limitations like "min 2 days off between pairings" "no same day pairings" or "1 day off in 7" along the way.
More control over report/release times. Say I were trying to bid for commutable trips. I could tell it to give me trips with report times after 2 pm and release times before 5 pm. If that didn't work, I could loosen up my report and release times either separately or together. If that didn't work, I could tell it to give me trips commutable on one end or the other, or a couple of back-to-back trips that taken together are commutable. And I could do all of this all within the same "layer".
For the morbidly curious, here's a sample of one bid group/layer out of a bid from last year. The NavTech system would go through that list of commands in that order (which I could change). If it couldn't find any trips that satisfied every condition in a given line, it'd move on to the next line (and so on) until it had build a complete line for the month that reached the credit window. Some of this I can do with SKW's PBS. A lot of it I can't (or haven't figured out how yet).
Other than my Mesa classmates are starting to be awarded upgrades...no, no regrets. Talked to a buddy there last night, my paychecks on 1st yr pay here are bigger than his on 2nd yr pay there, and I have yet to break guarantee.
The NavTech PBS engine Mesa uses is the same one Delta and Hawaiian use, only without the graphical interface (costs extra). So you build up a list of commands that the engine runs through in order when the bid is run, and can organize them into as many groups (or "layers") as you want, limited by a max of 200 command lines total. While the learning curve is steep, being a programmer in my former life I mastered it pretty quickly and built some pretty complex bids (see sample at bottom). Here are a couple examples where the NavTech PBS was more flexible:
More control over movement between "layers". NavTech's bid groups work basically the same as layers here, but I had more control over how the software moved between them. For instance, if I had days off that were essential and some that were optional, if it couldn't build a line based on my preferences in that "layer", I could tell it to drop the prefer-off for the optional days and loop through my set of bid preferences again to see if it can build a line without those optional days off. I could take those optional prefer-offs out incrementally or all at once. If it couldn't grant my essential days off within the constraints/properties I'd set for that "layer", I could force it to move on to subsequent "layers", gradually lifting the constraints/properties and/or waiving contractual limitations like "min 2 days off between pairings" "no same day pairings" or "1 day off in 7" along the way.
More control over report/release times. Say I were trying to bid for commutable trips. I could tell it to give me trips with report times after 2 pm and release times before 5 pm. If that didn't work, I could loosen up my report and release times either separately or together. If that didn't work, I could tell it to give me trips commutable on one end or the other, or a couple of back-to-back trips that taken together are commutable. And I could do all of this all within the same "layer".
For the morbidly curious, here's a sample of one bid group/layer out of a bid from last year. The NavTech system would go through that list of commands in that order (which I could change). If it couldn't find any trips that satisfied every condition in a given line, it'd move on to the next line (and so on) until it had build a complete line for the month that reached the credit window. Some of this I can do with SKW's PBS. A lot of it I can't (or haven't figured out how yet).
The NavTech PBS engine Mesa uses is the same one Delta and Hawaiian use, only without the graphical interface (costs extra). So you build up a list of commands that the engine runs through in order when the bid is run, and can organize them into as many groups (or "layers") as you want, limited by a max of 200 command lines total. While the learning curve is steep, being a programmer in my former life I mastered it pretty quickly and built some pretty complex bids (see sample at bottom). Here are a couple examples where the NavTech PBS was more flexible:
More control over movement between "layers". NavTech's bid groups work basically the same as layers here, but I had more control over how the software moved between them. For instance, if I had days off that were essential and some that were optional, if it couldn't build a line based on my preferences in that "layer", I could tell it to drop the prefer-off for the optional days and loop through my set of bid preferences again to see if it can build a line without those optional days off. I could take those optional prefer-offs out incrementally or all at once. If it couldn't grant my essential days off within the constraints/properties I'd set for that "layer", I could force it to move on to subsequent "layers", gradually lifting the constraints/properties and/or waiving contractual limitations like "min 2 days off between pairings" "no same day pairings" or "1 day off in 7" along the way.
More control over report/release times. Say I were trying to bid for commutable trips. I could tell it to give me trips with report times after 2 pm and release times before 5 pm. If that didn't work, I could loosen up my report and release times either separately or together. If that didn't work, I could tell it to give me trips commutable on one end or the other, or a couple of back-to-back trips that taken together are commutable. And I could do all of this all within the same "layer".
For the morbidly curious, here's a sample of one bid group/layer out of a bid from last year. The NavTech system would go through that list of commands in that order (which I could change). If it couldn't find any trips that satisfied every condition in a given line, it'd move on to the next line (and so on) until it had build a complete line for the month that reached the credit window. Some of this I can do with SKW's PBS. A lot of it I can't (or haven't figured out how yet).
Gets Weekends Off
Joined APC: Sep 2006
Position: ERJ CA
Posts: 1,082
True, but *how* it accomplishes that is entirely up to PBS. With the NavTech software, the process by which it would do that is dictated by the order you have those lines, "redo from" loops, etc. This allows you to prioritize the possible solutions according to your priorities, not the company's.
Thread
Thread Starter
Forum
Replies
Last Post