5 ms·

Senior engineers who don't code

24 points by mji 3y ago

cratermoon 3y ago
" It doesn’t matter that you think that coding interviews are useless. It doesn’t even matter if you are right or not. What matters is that the people who are interviewing you, and who are deciding if you are going to get the job, think good performance on a coding interview is important." I don't want to work for a company where people think performance on a coding interview is important for a "senior" role. Those people are wrong. Oh, except now "senior" applies to anyone with 3 years in the industry, and most likely those people don't really know what they are doing. My suggestion: stop with the title inflation. If you believe you need to know if someone is competent in trick coding problems you should not be interviewing them for a senior role. It means your concept of "senior" is wrong and you should feel bad.
- yieldcrv 3y ago
  listen to this, this person is about to improve the GDP by a whole percentage point
- boppo1 3y ago
  I dunno, I think passing a handful of 'easy' leetcode problems seems fair. I'm someone who programmed garbage-that-got-the-job-done with python for years, now trying to break into a real job and making an effort to actually grasp data structures beyond dynamic arrays. It has really notched-up how I think about the problems. I've managed before and what I found aas that I didn't need to be as good as my best reports at their functions, but I did need a solid working grasp of their fundamentals. That said, requiring mastery of 'hard'-level problems is silly.
  - cratermoon 3y ago
    > now trying to break into a real job and making an effort to actually grasp data structures beyond dynamic arrays OK, for an entry level to junior programmer trying to get into the mid-career levels it's possible that leetcode problems are useful for weeding out garbage programmers, folks who went to a code camp program and don't know anything about data structures and algorithms. These days what's called "senior" is, thanks to title inflation, really a mid-level job at best. For genuine senior work, which is sometimes called Staff or Principal level, the important skills are softer. There's a point where pure programming skills are complementary to the ability to understand and work with the business and understand how the organization generates revenue. At that point, whatever title it might have, the ability to solve an easy leetcode problem has no bearing on the ability to do the work expected. The challenges at that level are not "how do you code X", but rather "does coding X solve a problem that contributes to revenue, why or why not?"
- gedy 3y ago
  > If you believe you need to know if someone is competent in trick coding problems you should not be interviewing them for a senior role. Better yet - don't reach out to employed, senior devs for a role, then play these "gotta see if you're a faker!" games. It's like asking someone on a date, then asking for an STD test once they agree.
  - drewcoo 3y ago
    I would expect someone who has not been dating in a while would be less likely to have an STI than someone who has been in a relationship but is actively (surreptitiously?) looking around for something better. Maybe you should talk to the unemployed devs!
- nosefurhairdo 3y ago
  Coding interviews are proxies for IQ and/or work ethic. If you're good at coding interviews you're either reasonably intelligent, reasonably hardworking, or some combination of the two. They're not supposed to represent what you do on the job. They're just a screen for people incapable or unwilling to pass them. It's also easier to objectively evaluate coding interview performance compared to "softer" interviews, which is helpful to reduce bias in hiring decisions. It is not an accident that coding interviews became the norm. Many of the most successful engineering organizations in the world are known for their coding interviews. Just because you don't like them doesn't mean they're an ineffective tool.
  - cratermoon 3y ago
    SAT scores are the same thing. They measure an arbitrary quantity, allegedly a good proxy for real ability. News flash: some people test well but under perform, others test poorly but perform well. > objectively evaluate coding interview performance compared to "softer" interviews, which is helpful to reduce bias in hiring decisions. No, because those coding questions are themselves biased towards people who have the same experiences as those asking them. It's exactly the same as IQ and SAT tests: the bias is hidden in "objective" results. Men outscore women by an average of 37 points on the math section, and 7 points on the reading section. Asian students score the highest on average, with white students trailing them by 22 points on average, and black and hispanic students trailing white students by an average of 50 points. Finally, students who receive need based aid score an average of 20 points lower on both sections of the test. These results are held up as "proof" that white men are better than women of color. > It is not an accident that coding interviews became the norm. It's true. They became the norm because they allowed organizations to hide bias under cover of "objectivity" > Many of the most successful engineering organizations in the world I wonder how much more successful engineering organizations that didn't bias against applicants that score poorly on these tests would do. Unfortunately, we don't have a control group, so crowing about how great this or that company has done when comparing them to organizations with similar biases doesn't provide much insight.
    - nosefurhairdo 3y ago
xyzzy4747 3y ago
Well as a senior engineer I spend most of my time building or refining user interfaces and passing data around, not trying to solve algorithmic puzzles under a clock.
lcnPylGDnU4H9OF 3y ago
> But, perhaps most importantly, for a senior software engineer coding is still supposed to be fun! I want every senior engineer to code because they think it is still cool, fun, interesting, and exciting. Coding is not a chore. I want you to feel guilty when you are coding during work time because you feel you are having too much fun at work and you should really be doing something more worthwhile. > Don’t have that feeling. Even for a senior engineer, coding is worthwhile. Just don’t do it so often and so much that there is no difference between you and a more junior engineer... This is rather incoherent. Am I allowed to have fun?
- quantified 3y ago
  Other recent titles: * Normalization of deviance * About losers, clueless, and sociopaths * Anxiety in the workplace * Try harder to suck less Grim reality
- sshine 3y ago
  > This is rather incoherent. Am I allowed to have fun? Yes, but you should feel guilty about it.
artyom 3y ago
Summary: coding interviews are terrible, the job will be all meetings, and the people running both of those are ignorant. It's your duty as a senior engineer to overcompensate for all of that. Pay will be the same wether you do it or not.
quantified 3y ago
> I want you to feel guilty when you are coding during work time because you feel you are having too much fun at work and you should really be doing something more worthwhile. As someone who has fun coding: this guy's a lunatic. Avoid them in a work setting.
- throwboatyface 3y ago
  I used to work with this guy and he used to send a bunch of these weird, rambling "thought leader" messages to the whole org.
- jbirer 3y ago
  Gives off "HR / manager who suffers from a personality disorder and has no workload so he comes up with random nonsense" vibes.
000ooo000 3y ago
Written as though it assumes coding challenges are the only way to demonstrate ability to code. Coding challenges where you complete a contrived task against a clock are certainly lame, but don't get it twisted - they are used simply because they require the absolute minimum effort from the employer, not because they are supremely effective. If you weed out a developer who can't code using an 'easy coding challenge', I have to wonder how your shortlisting process works.
gorgoiler 3y ago
Well said. The musical instrument analogy is apt. Your violin playing has to remain exceptional if you want to have a position of authority at the top of the violin playing pyramid. You maintain that by playing the violin a lot. When I ask you to implement and discuss an advent of code style solution in 50 minutes it is because there is an expectation you are an exceptional violin player and I simply want to enjoy listening to you play. We choose the members of our ensemble based on many criteria and one of those is a rather binary proficient / not proficient violin playing test. (As a senior member of the ensemble you will be expected to also show expression in your playing, be self aware of that expression, have an understanding of music theory at a large scale, an ability to communicate clearly and with confidence so that you can coach others in their playing, etc.) I’ve been a violin professional for 25 years. I find myself doing just as much violin review as I do violin playing. If a junior dev, sorry, violinist is having trouble with a piece then the best way to show them is to play a few bars myself to show them an abstract example of how their playing could be different and better. Who will listen to my advice if I’m ham fistedly scratching out a fiddle dirge, when doing so?
- AlotOfReading 3y ago
  It's probably worth talking about how radically different the typical orchestral audition process actually is though. You'll typically be told a large list of excerpts to practice weeks ahead of time. Some places may have you submit recorded samples ahead of time for screening, others you just show up. The day of, you'll be given a definitive list of "problems" and 30m+ to warm up/practice those problems before each of the rounds. Sight reading the way coding challenges are done is sometimes listed as a requirement, but extremely rare in practice according to my orchestral neighbors.
  - gorgoiler 3y ago
    The analogy was a bit hokey but this added a lot more to it, as a concept. Thank you. For coding interviews I do require that my recruiter tells the candidate pretty much exactly the way the day will pan out. If a candidate ever arrived and was surprised to be given a leetcode (lite!) challenge then something would have gone horribly wrong. An interview without signal is a waste of everyone’s time.
sublinear 3y ago
Why does this matter as long as you're serving your team as needed? That should mean you're fully capable of doing anything from writing good quality code to going to bat for them in a meeting, writing documentation, SSHing into a VM to put out a fire, etc. A senior dev should have done plenty of that before getting promoted to senior just not all at once. What's special about writing code and why are some people so afraid of "forgetting how to code"? No offense to anyone but sounds like a load of bs to me from someone who isn't ready and works at a place where that promotion is forced due to lack of choice.
sam_lowry_ 3y ago
I am one of those senior engineers who regularly code and dare I say produce optimal solutions quickly. I still fail at coding interviews, and I attribute it to the gamification fatigue and age. Please understand me. I have a leetcode account but I can not force myself into solving puzzles in my free time after solving them all day long at work. And puzzles at work are more interesting, because they are real people's problems. I avoid board games for similar reasons. Whenever I sit in and play, I enjoy being in the flow, the conversation, and the intellectual challenge. But dragging me in is damn hard. On the other side, I am much more into sports nowadays: running, swimming, skiing and hiking, as if I was making up for my younger years spent in front of a screen. I feel like I have to carefully choose where to apply my intelligence because I am not as resourceful as I was. But I am wiser. Would you hire me? No. Would I be a net positive for you business even if I cost double your younger self? Probably yes.
- thelastknowngod 3y ago
  > I have a leetcode account but I can not force myself to solve puzzles in my free time after solving them all day long at work. And dare I say puzzles at work are more interesting, because they solve real people's problems. The problems at work are also real, actual problems. I have trouble with the coding section of the interviews but I do know how to write code. If the coding section of the interview was like "build me a ci pipeline for this app" or "find all the workloads in this cluster which need X attribute" or "design a terraform module to do Y" then I would pass with flying colors. In the average SRE role, it has been my experience that there are very few situations where I would need to build out a perfect O(1) algorithm. Nothing I write is going to be so heavily used that this level of performance is something to be concerned with. These are the only code problems I really see when interviewing though.
  - sshine 3y ago
    > build out a perfect O(1) algorithm In my experience, the algorithm-heavy interviews happen at large companies that use it as an extended IQ test to filter out people who don't perform well on mathy problems, psychologically or problem-solving wise. The argument is that with their influx of applicants, they can afford false negatives (a good programmer failing an algorithm quiz) more than false positives (a bad programmer passing a personality test). I've had live-coding interviews where I consistently felt so dumb with flashbacks to my worst oral exams at uni. And I've had live-coding interviews where I aced it so much it felt like improvising teaching material.
28304283409234 3y ago
You want me in your team. I am the voice of reason, of clarity. I will take your happy flow and make it sadder than a wheeping willow. I will write the tests, verify the work, highlight the blind assumptions. I can coach juniors into mediors and seniors. I build bridges across teams and companies, pave ways and smooth paths so other engineers have an easier time getting results. And I cannot pass a coding test. Because I suck at tests.
taylodl 3y ago
> I do not trust a design written by someone who couldn’t implement the system themselves. BINGO! I had been a developer for 20 years before becoming an architect - which was 20 years ago. You have to continue coding. It's an imperative. That's how you stay relevant and continue to provide good solutions and how to best apply new technologies. There's also the fact that developers respect those who can code and you can't call yourself a "tech leader" if your team doesn't respect you.
vaxman 3y ago
On one hand, you have self-absorbed assholes like this one (check out the titles of his "Wednesday Wisdom" posts on that same substack) and on the other hand, you have Big Tech shifting the platforms to intentionally cause their older engineers to fall behind (to circumvent EEOP, which is decades behind the curve) allowing those mature workers to be easily replaced with new brains that are perceived to be "better". Oh and speaking of brains, then comes the AI copilot (which they seem to be reigning in, despite lying through their teeth about doing so, though it's probably due to resource limitations than any desire to save jobs). Software developers should be paid like athletes, but instead the employers are going into public schools and [I Kid You Not] even into homeless shelters looking for anyone they can teach to learn how to "code" to keep feeding their insatiable appetite to exploit the fuck out of their fellow human beings. In other words: If you have the MIPS and RAM, why pay for a top software engineer to do things efficiently when you can simply hire a way cheaper kid, point them at something like SwiftUI and achieve the same business goal? The problem is, you can't just fire the software engineer if they're over a certain age without showing they're unable to keep up, which you do by shifting the rules of the operating platform. The strategy fails only when the MIPS and RAM become limitations (or when the EEOP enforcement agencies around the Country figure out what's been going on since the microcomputer vendors took control away from the established mainframe and minicomputer vendors during the late 1980s and initiate legislative and/or regulatory changes).

24 points by mji 3y ago

" It doesn’t matter that you think that coding interviews are useless. It doesn’t even matter if you are right or not. What matters is that the people who are interviewing you, and who are deciding if you are going to get the job, think good performance on a coding interview is important." I don't want to work for a company where people think performance on a coding interview is important for a "senior" role. Those people are wrong. Oh, except now "senior" applies to anyone with 3 years in the industry, and most likely those people don't really know what they are doing. My suggestion: stop with the title inflation. If you believe you need to know if someone is competent in trick coding problems you should not be interviewing them for a senior role. It means your concept of "senior" is wrong and you should feel bad.

yieldcrv 3y ago
listen to this, this person is about to improve the GDP by a whole percentage point
boppo1 3y ago
I dunno, I think passing a handful of 'easy' leetcode problems seems fair. I'm someone who programmed garbage-that-got-the-job-done with python for years, now trying to break into a real job and making an effort to actually grasp data structures beyond dynamic arrays. It has really notched-up how I think about the problems. I've managed before and what I found aas that I didn't need to be as good as my best reports at their functions, but I did need a solid working grasp of their fundamentals. That said, requiring mastery of 'hard'-level problems is silly.
- cratermoon 3y ago
  > now trying to break into a real job and making an effort to actually grasp data structures beyond dynamic arrays OK, for an entry level to junior programmer trying to get into the mid-career levels it's possible that leetcode problems are useful for weeding out garbage programmers, folks who went to a code camp program and don't know anything about data structures and algorithms. These days what's called "senior" is, thanks to title inflation, really a mid-level job at best. For genuine senior work, which is sometimes called Staff or Principal level, the important skills are softer. There's a point where pure programming skills are complementary to the ability to understand and work with the business and understand how the organization generates revenue. At that point, whatever title it might have, the ability to solve an easy leetcode problem has no bearing on the ability to do the work expected. The challenges at that level are not "how do you code X", but rather "does coding X solve a problem that contributes to revenue, why or why not?"
gedy 3y ago
> If you believe you need to know if someone is competent in trick coding problems you should not be interviewing them for a senior role. Better yet - don't reach out to employed, senior devs for a role, then play these "gotta see if you're a faker!" games. It's like asking someone on a date, then asking for an STD test once they agree.
- drewcoo 3y ago
  I would expect someone who has not been dating in a while would be less likely to have an STI than someone who has been in a relationship but is actively (surreptitiously?) looking around for something better. Maybe you should talk to the unemployed devs!
nosefurhairdo 3y ago
Coding interviews are proxies for IQ and/or work ethic. If you're good at coding interviews you're either reasonably intelligent, reasonably hardworking, or some combination of the two. They're not supposed to represent what you do on the job. They're just a screen for people incapable or unwilling to pass them. It's also easier to objectively evaluate coding interview performance compared to "softer" interviews, which is helpful to reduce bias in hiring decisions. It is not an accident that coding interviews became the norm. Many of the most successful engineering organizations in the world are known for their coding interviews. Just because you don't like them doesn't mean they're an ineffective tool.
- cratermoon 3y ago
  SAT scores are the same thing. They measure an arbitrary quantity, allegedly a good proxy for real ability. News flash: some people test well but under perform, others test poorly but perform well. > objectively evaluate coding interview performance compared to "softer" interviews, which is helpful to reduce bias in hiring decisions. No, because those coding questions are themselves biased towards people who have the same experiences as those asking them. It's exactly the same as IQ and SAT tests: the bias is hidden in "objective" results. Men outscore women by an average of 37 points on the math section, and 7 points on the reading section. Asian students score the highest on average, with white students trailing them by 22 points on average, and black and hispanic students trailing white students by an average of 50 points. Finally, students who receive need based aid score an average of 20 points lower on both sections of the test. These results are held up as "proof" that white men are better than women of color. > It is not an accident that coding interviews became the norm. It's true. They became the norm because they allowed organizations to hide bias under cover of "objectivity" > Many of the most successful engineering organizations in the world I wonder how much more successful engineering organizations that didn't bias against applicants that score poorly on these tests would do. Unfortunately, we don't have a control group, so crowing about how great this or that company has done when comparing them to organizations with similar biases doesn't provide much insight.
  - nosefurhairdo 3y ago

xyzzy4747 3y ago

Well as a senior engineer I spend most of my time building or refining user interfaces and passing data around, not trying to solve algorithmic puzzles under a clock.

lcnPylGDnU4H9OF 3y ago

> But, perhaps most importantly, for a senior software engineer coding is still supposed to be fun! I want every senior engineer to code because they think it is still cool, fun, interesting, and exciting. Coding is not a chore. I want you to feel guilty when you are coding during work time because you feel you are having too much fun at work and you should really be doing something more worthwhile. > Don’t have that feeling. Even for a senior engineer, coding is worthwhile. Just don’t do it so often and so much that there is no difference between you and a more junior engineer... This is rather incoherent. Am I allowed to have fun?

quantified 3y ago
Other recent titles: * Normalization of deviance * About losers, clueless, and sociopaths * Anxiety in the workplace * Try harder to suck less Grim reality
sshine 3y ago
> This is rather incoherent. Am I allowed to have fun? Yes, but you should feel guilty about it.

artyom 3y ago

Summary: coding interviews are terrible, the job will be all meetings, and the people running both of those are ignorant. It's your duty as a senior engineer to overcompensate for all of that. Pay will be the same wether you do it or not.

quantified 3y ago

> I want you to feel guilty when you are coding during work time because you feel you are having too much fun at work and you should really be doing something more worthwhile. As someone who has fun coding: this guy's a lunatic. Avoid them in a work setting.

throwboatyface 3y ago
I used to work with this guy and he used to send a bunch of these weird, rambling "thought leader" messages to the whole org.
jbirer 3y ago
Gives off "HR / manager who suffers from a personality disorder and has no workload so he comes up with random nonsense" vibes.

000ooo000 3y ago

Written as though it assumes coding challenges are the only way to demonstrate ability to code. Coding challenges where you complete a contrived task against a clock are certainly lame, but don't get it twisted - they are used simply because they require the absolute minimum effort from the employer, not because they are supremely effective. If you weed out a developer who can't code using an 'easy coding challenge', I have to wonder how your shortlisting process works.

gorgoiler 3y ago

Well said. The musical instrument analogy is apt. Your violin playing has to remain exceptional if you want to have a position of authority at the top of the violin playing pyramid. You maintain that by playing the violin a lot. When I ask you to implement and discuss an advent of code style solution in 50 minutes it is because there is an expectation you are an exceptional violin player and I simply want to enjoy listening to you play. We choose the members of our ensemble based on many criteria and one of those is a rather binary proficient / not proficient violin playing test. (As a senior member of the ensemble you will be expected to also show expression in your playing, be self aware of that expression, have an understanding of music theory at a large scale, an ability to communicate clearly and with confidence so that you can coach others in their playing, etc.) I’ve been a violin professional for 25 years. I find myself doing just as much violin review as I do violin playing. If a junior dev, sorry, violinist is having trouble with a piece then the best way to show them is to play a few bars myself to show them an abstract example of how their playing could be different and better. Who will listen to my advice if I’m ham fistedly scratching out a fiddle dirge, when doing so?

AlotOfReading 3y ago
It's probably worth talking about how radically different the typical orchestral audition process actually is though. You'll typically be told a large list of excerpts to practice weeks ahead of time. Some places may have you submit recorded samples ahead of time for screening, others you just show up. The day of, you'll be given a definitive list of "problems" and 30m+ to warm up/practice those problems before each of the rounds. Sight reading the way coding challenges are done is sometimes listed as a requirement, but extremely rare in practice according to my orchestral neighbors.
- gorgoiler 3y ago
  The analogy was a bit hokey but this added a lot more to it, as a concept. Thank you. For coding interviews I do require that my recruiter tells the candidate pretty much exactly the way the day will pan out. If a candidate ever arrived and was surprised to be given a leetcode (lite!) challenge then something would have gone horribly wrong. An interview without signal is a waste of everyone’s time.

sublinear 3y ago

Why does this matter as long as you're serving your team as needed? That should mean you're fully capable of doing anything from writing good quality code to going to bat for them in a meeting, writing documentation, SSHing into a VM to put out a fire, etc. A senior dev should have done plenty of that before getting promoted to senior just not all at once. What's special about writing code and why are some people so afraid of "forgetting how to code"? No offense to anyone but sounds like a load of bs to me from someone who isn't ready and works at a place where that promotion is forced due to lack of choice.

sam_lowry_ 3y ago

I am one of those senior engineers who regularly code and dare I say produce optimal solutions quickly. I still fail at coding interviews, and I attribute it to the gamification fatigue and age. Please understand me. I have a leetcode account but I can not force myself into solving puzzles in my free time after solving them all day long at work. And puzzles at work are more interesting, because they are real people's problems. I avoid board games for similar reasons. Whenever I sit in and play, I enjoy being in the flow, the conversation, and the intellectual challenge. But dragging me in is damn hard. On the other side, I am much more into sports nowadays: running, swimming, skiing and hiking, as if I was making up for my younger years spent in front of a screen. I feel like I have to carefully choose where to apply my intelligence because I am not as resourceful as I was. But I am wiser. Would you hire me? No. Would I be a net positive for you business even if I cost double your younger self? Probably yes.

thelastknowngod 3y ago
> I have a leetcode account but I can not force myself to solve puzzles in my free time after solving them all day long at work. And dare I say puzzles at work are more interesting, because they solve real people's problems. The problems at work are also real, actual problems. I have trouble with the coding section of the interviews but I do know how to write code. If the coding section of the interview was like "build me a ci pipeline for this app" or "find all the workloads in this cluster which need X attribute" or "design a terraform module to do Y" then I would pass with flying colors. In the average SRE role, it has been my experience that there are very few situations where I would need to build out a perfect O(1) algorithm. Nothing I write is going to be so heavily used that this level of performance is something to be concerned with. These are the only code problems I really see when interviewing though.
- sshine 3y ago
  > build out a perfect O(1) algorithm In my experience, the algorithm-heavy interviews happen at large companies that use it as an extended IQ test to filter out people who don't perform well on mathy problems, psychologically or problem-solving wise. The argument is that with their influx of applicants, they can afford false negatives (a good programmer failing an algorithm quiz) more than false positives (a bad programmer passing a personality test). I've had live-coding interviews where I consistently felt so dumb with flashbacks to my worst oral exams at uni. And I've had live-coding interviews where I aced it so much it felt like improvising teaching material.

28304283409234 3y ago

You want me in your team. I am the voice of reason, of clarity. I will take your happy flow and make it sadder than a wheeping willow. I will write the tests, verify the work, highlight the blind assumptions. I can coach juniors into mediors and seniors. I build bridges across teams and companies, pave ways and smooth paths so other engineers have an easier time getting results. And I cannot pass a coding test. Because I suck at tests.

taylodl 3y ago

> I do not trust a design written by someone who couldn’t implement the system themselves. BINGO! I had been a developer for 20 years before becoming an architect - which was 20 years ago. You have to continue coding. It's an imperative. That's how you stay relevant and continue to provide good solutions and how to best apply new technologies. There's also the fact that developers respect those who can code and you can't call yourself a "tech leader" if your team doesn't respect you.

vaxman 3y ago

On one hand, you have self-absorbed assholes like this one (check out the titles of his "Wednesday Wisdom" posts on that same substack) and on the other hand, you have Big Tech shifting the platforms to intentionally cause their older engineers to fall behind (to circumvent EEOP, which is decades behind the curve) allowing those mature workers to be easily replaced with new brains that are perceived to be "better". Oh and speaking of brains, then comes the AI copilot (which they seem to be reigning in, despite lying through their teeth about doing so, though it's probably due to resource limitations than any desire to save jobs). Software developers should be paid like athletes, but instead the employers are going into public schools and [I Kid You Not] even into homeless shelters looking for anyone they can teach to learn how to "code" to keep feeding their insatiable appetite to exploit the fuck out of their fellow human beings. In other words: If you have the MIPS and RAM, why pay for a top software engineer to do things efficiently when you can simply hire a way cheaper kid, point them at something like SwiftUI and achieve the same business goal? The problem is, you can't just fire the software engineer if they're over a certain age without showing they're unable to keep up, which you do by shifting the rules of the operating platform. The strategy fails only when the MIPS and RAM become limitations (or when the EEOP enforcement agencies around the Country figure out what's been going on since the microcomputer vendors took control away from the established mainframe and minicomputer vendors during the late 1980s and initiate legislative and/or regulatory changes).