You should devote approximately one week to reading about how to interview better and practicing and then get as many interviews as you can at companies which are large enough to offer a competitive benefits suite. If I were in your situation I'd optimize for brand-name ones first, since the last name on your resume dominates people's impression of it. ("Worked for ten years at university IT departments and small software companies then Yelp" rounds to "ex-Yelp employee" according to basically every recruiter I've ever spoken to, and there are a lot of companies which round to Yelp.)

Even if one thought that one was below the supposed bar for large companies, they're sufficiently imprecise regarding interviewing that you have at least a 20% chance of an offer given ability to get onto a phone screen and pass the local version of FizzBuzz. Make it your mission to get failed out of their interview loop twenty times; it's virtually impossible.

P.S. One does not have to change one's personality to present differently for twenty minutes on a phone call if one believes that one's perceived personality is causing the phone rejections.

The compelling reasons 'patio11 offered were that it will cost a lot of money and years of opportunity cost. If you don't find those compelling, then that's your prerogative.

The whole NASA or Intel thing... I think you hit the nail on the head with "building valuable connections". I think you need to do this regardless of where you want to work. If you decide you want to work at one of these places or some place like it, make sure that you understand what is and is not required for the job. A certain degree may be required (explicitly), there may be age expectations (most likely illegal, but it happens), and/or there may be soft skills that you may not have yet and may never acquire (a very real requirement to get hired that is often overlooked by many people looking for specific jobs).

FWIW, 'patio11 has some high quality experience with the engineering hiring market and has written some seminal texts about it. Rather than blithely reject his advice (as you seem to do here), I humbly suggest that you engage with him in a more constructive way, perhaps by engaging with questions (e.g., about his thought process, about specific details on career direction that you failed to mention in your original post, etc.).

Also note, as a general rule, people with highly-informed and high-quality advice typically aren't looking for an argument, a debate, or (worse) a moving target of discussion -- you seem to have taken your reply one or more of these directions. The way you engage with people matters, and I wonder if this is a limiting factor of your career development.

Regardless, best of luck in your search. I hope you keep us updated with your status.

Your return on investment on a Masters CS degree will come over time.

For example, once you finish the degree, you should be in a better negotiating position in your current company when discussing promotions as you have demonstrated a willingness to follow through with personal development in service of the company.

If you lose your current job, having a CS degree is great future risk mitigation. While a portfolio and experience sounds good enough, you'd have to jump more hoops through HR without a CS degree. But once you have it you could get a job almost anywhere you want.

>FWIW, 'patio11 has some high quality experience with the engineering hiring market and has written some seminal texts about it.

This is important to know. However, I think it would be better of patio11 to open his comment by stating a short summary of this experience in order to lend more credence to his suggestions.

>there may be soft skills that you may not have yet and may never acquire

I'm curious about this. Especially on the "may never acquire" part. You mean that there are some soft skills that some people would never attain? That's interesting to me and I'd like to know why.

1. “Your return on investment on a Masters CS degree will come over time.” It might produce a positive ROI over time. It really depends on what you do, what you intend to do, and what you value.

2. Re: negotiation. Check out ‘patio11’s seminal text on this subject (other good articles on there as well): https://www.kalzumeus.com/2012/01/23/salary-negotiation/

3. Re: risk mitigation. A robust professional network is almost always more valuable and more resilient than a MS CS. I actually think that this is OP’s biggest opportunity/challenge.

4. Re: Summary of experience. I looked at your profile, and it seems like you’re relatively new here. ‘patio11 is one of HN’s most prolific posters. His posts have declined dramatically in frequency (due to work?) over the past year or so, but he is one of the grand hommes of HN. Check out this link: https://news.ycombinator.com/leaders. ‘patio11 is third, and that’s with a year plus of minimal commenting. Note that I have a very large scrapbook of smart things he has said in HN comments.

5. Remember that leader list, check out #1. ‘tptacek and ‘patio11 actually started a business together focused on the hiring of software engineers. It shut down for reasons unknown, but HN was (largely) rooting for them. It is still not entirely clear why they shut it down other than “hiring is broken” (i.e., employers claiming they want $TRAIT, but demure when a candidate with $TRAIT is presented to them, usually for something nebulous like an undeclared standard for culture fit). Anyway, both of these folks have a great deal of direct and indirect industry experience, and they have a habit of saying very smart things on a regular basis.

6. Re: soft skill limits. Short answer, cognitive biases. Slightly longer answer, first the problem needs to be acknowledged, and then — maybe — it can be solved. There are myriad psychological reasons (e.g, cognitive biases, mental disorders, etc.) for breakdown to happen at any step of this process. Is it possible to attain almost any soft skil, sure. Is it probable? Not for some people.

You are actually right about that. I do not have a robust network. It could be a negative, but I also learn that you don't have to allow negative traits to define you, or your worth.

I have learned this from someone else who works as a software professional, who is bipolar and depressed. He also works at a fortune 500 making 6 figures, and takes on leadership responsibilities. He says that he hates himself, but loves his wife, and that despite being antisocial, it doesn't have to dominate him.

He also says his personality and social network does not affect his ability to work, and he works hard for his team. If he can do it despite his shortcomings, so can I. Dwelling on your negative qualities are a distraction, and incorrectly convinces you that your negatives have to commandeer your self-worth.

I will need to follow in this guy's footsteps. Forget about my lack of a network as something that defines me. I have to play to my strengths, and downplay my weaknesses.

When these companies rejected you, it was almost certainly because of your interview performance, not your experience. The good news is that you can practice for interviews. There are many resources online. Good luck!

Kind of a like a farm guy trying to make small talk with someone who's only lived in a big city, it will be noticeable. It makes it harder for both people to find common ground. Does that make sense?

This has been a tough one in the past-interview discussion on many of the interview panels that I've been on. Given a bigger pond, would the candidate jump at the new opportunities and learn? Whether or not we decide to go that route often depends on a number of factors, both from the candidate and the current team dynamics (what's our internal junior/senior team ratio and what's our current mentoring needs/bandwidth?)

I have no way of knowing if this describes you, of course, but might at least be worth ensuring that during the interview you're not giving the above impression.

FWIW, I've interviewed hundreds of people at major silicon valley companies. I wouldn't presume to diagnose someone's hiring biases (we all have them) without more data than you can find in a single HN comment.

You may want to see if you can find someone to meet in person to discuss this matter. Such things may only come out in person. Someone who has been in an interviewing position at a larger corporation would be ideal. You may have to troll some meetups or something for this, which isn't exactly a waste of time when it comes to trying to get a job anyhow, so it's efficient.

This will be a function of one's company culture.

FANGS have a pretty high operational bar that's sometimes hard to grasp from the outside, without internships, friends and networks of exposure.

BigCos have varying levels of professoinalism etc.

But both tend to have specific expectations that can be hard to grasp when from a smaller company.

At smaller companies I find people tend to generalize, and work on smaller projects obviously.

At BigCos there's much more opportunity for specialization, and sometimes huge codebases and if you've never worked on something like that it can seem unwieldy.

I think a frame of reference is important for setting interview expectations etc..

Bingo. I think having an "inside" view of expectations is key to interviewing at these kinds of companies.

So without any insider info on how big companies operate on a high level all the way down, outside of reading web articles or forum discussions, I have to put the pieces together on my own. My personal network is pretty diffused and fragmented, too. I know a person I met at a tech meetup years ago, he now works at Amazon. But he's too busy to reply and doesn't seem interested in being a referral.

As silly as it sounds I thought the small-to-big company would be the most logical career progression, as I even compare it to a music career at one point. In that you first have to produce and sell for an indie label before getting picked up by big shots such as Sony. But my reality is me spinning my wheels in the small co/startup circuit still waiting to "make it big".

Given that, are you sure you're 100% on the technical side of interviewing...particularly algorithmic type questions? Whether you agree with the approach or not, they tend to be more common and given more weight with bigger companies.

All the other companies with some reasonable amount of public exposure, (like Zillow, Coinbase, ArenaNet, to give a few examples) interviewed me on more holistic and technical concepts, such as how would you use an API to build a website, or how would you design a database, etc.

Quick learners can cross the Y-intercept of knowledge of those that know more but learn less quickly.

care to elaborate? or is this the soda fountain in the cafeteria?

The big things that seem to matter are your experience, and interview performance. People at big companies come from all walks of life as well as small companies, there really isn't that much of a difference in that regard. As someone currently interviewing candidates, I really don't care if someone worked for a small company or big one - I mainly care if someone made the most of that experience.

As an example from myself, initially my answers were "too correct". If you tell someone what you think they want to hear, they pick up on that bullshit and they trust/respect you less. I then switched to more genuine answers, which has its own set of problems: sometimes people (mostly HR) actually do just want to hear the perfect answer, or they're judgmental and snobby about the genuine answer. However, at least I'm now actively deciding what impression I give.

Once you cut out the major errors in your interview answers, it just becomes a numbers game. After you interview with enough people, you'll just click with the right company.

If you've been in an enterprise environment and are interviewing at a smaller company, they're going to be concerned that you're a hidebound cog who just sits there and waits for someone to tell them what to do (in triplicate), so they'll be looking for signs that you have initiative, that you don't think of things as "someone else's department," that you have the flexibility to roll with things that deviate from a strict process; if you've been at small companies and you're interviewing at larger ones, they're going to be concerned that you've just been ignoring all best practices and doing stuff with bubblegum and baling wire in a half-assed way.

My suspicion is that in those interviews, you didn't really allay those fears. Maybe you seemed impatient with process, maybe you came off like a cowboy, maybe you said things like "yeah, I know you're not supposed to make live code changes on production servers, but sometimes that's just the most effective way to get things done, you know?"

Or... maybe the company size thing is totally unrelated, and you just didn't wow them, who knows.

But it's not at all impossible to go between different types of companies, you just need to be aware of what's going to be different between them, and how you can be an asset to that type of company.

I've had the same job starting at a small startup, through growth and acquisitions, and I've been involved in hiring through the entire process.

Here's the dirty secret: startups try to be selective; but they're really desperate to hire. This is because startups are so mismanaged and risky that they have a lot of trouble getting someone competent to interview. When we were small, most people we interviewed were either incompetent or incapable of the challenge. Anyone competent got an offer.

As part of a mature organization, hiring is different. Most candidates can do the job, and actually want to work for us. (Unlike a startup, we now have good management and won't go out of business tomorrow.) Thus, we're more concerned with behavior.

My "competency test" interview has now evolved to more of a "tell me what I want to hear" interview. It's very effective, because almost all hires do the job well without wanting to perform useless refactoring because I didn't pick their favorite framework or brace style. It's also effective because I know I can communicate about higher level design topics.

I suggest, at a certain level, to just concentrate on telling your interviewers what they want to hear. This doesn't mean lying, or misrepresenting yourself. It just means that you need to understand who is in charge and play along with the same game everyone else is playing.

I'm also very clear about that when I interview a candidate. I now say something like: "This is a short interview and I try to ask questions that fit into the time. Some of the coding questions aren't real situations. The goal is to have a conversation about code, so if something is akward, just play along and do your best."

That is a paradox I am still trying to figure out LOL.

Ostensibly, startups are huge on culture fit. But also at the same time they want someone who knows a certain stack in and out, and can't attract those people all the time.

So startups and large companies are selective, in different ways?

And that is really gonna be a game changer for me, in turning my interview strategy into something that satisfies subjective needs.

I guess it's because so many candidates, as you say, can do the job because they perform well on an objective basis that larger companies have to reach into other less objective criteria to filter them out?

This isn't subjective at all! It just means that a technical interview is more than getting a correct answer; it also means that a technical interview is demonstrating that you can behave in a mature environment. That's why part of my interview turns into "tell me what I want to hear."

Because startups are horribly mismanaged, you can get away with certain forms of immaturity as long as you produce results. Larger companies don't put up with that.

Why? Someone who can't figure out the ambiguous requirements will require a lot of handholding. I don't have time for that.

Someone who argues about the requirement to use an outdated API either doesn't get the point of the question, or will ask to refactor years of perfectly working code on the first day. The outdated outdated API goes through so many core concepts that it's an awesome interview question. Someone competent should move through it without any struggle!

Even worse is when I ask someone to write some manual SQL and they tell me that doing SQL by hand is outdated! Instant rejection! I want to know that you understand the underlying concept without relying on magic. Manual SQL is easy, if you're competent.

Or, I had someone tell me that passing values to a constructor in C# is outdated... Not when you're using immutables for thread safety!

That's what I mean by play along and tell the interviewer what they want to hear.

E.g. asking such bullshit vague questions that might work on a recent graduate because you could assume that's a software engineering 101 question but if you actually asked them what exactly they meant, even just the scope or language, or offering 3 different paths of which one you'd like to sketch out tot hem .. blank stare, repeating the question.

"I could use this as a way into a discussion, and see how people carry themselves in such a (vaguely work-like) situation."

Looks like that poster has a very similar interview approach to me.

It isn’t just small to big companies. I also had an problem moving from enterprise to a smaller web related company. In that case, I went back to college part-time and retrained. Hard work but it turned out ok.

I also did a series of government projects, which I really enjoyed, without thinking too much about it and then had a hard time moving away from that.

The truth is that whatever you do, someone is going to pigeonhole you. It is just human nature.

I try hard to build skills in what I want to do next and then try to work on projects that use those skills.

One other thing I did was to present papers at user group conferences – often about what I wanted to do in my next project!

I'm going to assume you're a developer. Imagine working with a team of 5 to 10 developers. Plus a team of QAs. Plus a team of Ops. Plus a team of DBAs.

There's usually a process like working on code in a feature branch, passing it on for code review and then merging the feature branch into a development branch, where the QAs will deploy it to a staging server to check your changes (unless they deploy off the feature branch alone), and then eventually the development branch is merged to master for deploy to production.

So basically people aren't merging code to master or development out of the blue. People aren't typically sshing into production servers and changing code on the fly. Developers probably don't even get any access. And so on.

Anyways, not sure if you're already familiar with all that or if it gives you new insights into how working for a larger company might be different.

Try to follow up with people that interviewed you, you might actually learn why you didn't make the cut. This might be harder with large companies, but even during the interview, a question like 'If this doesn't work out, I plan to apply again in 6 months or so, anything I should do in the meantime to have better chance of success' might tell you something you didn't already know.

Second, I heard that if you go through interviews, the chances to get a job can be quite low, I heard stories that went along the lines 100 applications -> 10 phone screens -> 1 onsite interview.

It might be easier going around meetups, open-houses or conferences and talking to people, you might learn about open positions that would fill sooner than they get to a public job-board :) Last job I got came from a conversation with a former high-school friend over a beer.

Let's say you work at a big company in an environment that does not prioritize testing. You are heading into an interview at a smaller startup that LOVES testing. When one of the startup interviewers asks you how you feel about testing, they want you to answer the question in a way that makes it sound like you'd be enthusiastic & competent at testing "all the things". If you say "I don't have time to write tests at work", you're almost certainly not going to get the job. If you say "I love testing, I write tests whenever I can, a certain employer I may or may not currently work for makes it hard to me to increase test coverage, and that's a factor in why I'm taking the time to interview with you", you're going to almost certainly get the interviewer's attention in a good way. The other part of selling yourself is that you, as far as this employer is concerned at least, really need to love testing.

Get it?

So what does it take for you to look & sound like the person who would get the job at Amazon, Cloudflare, or Coinbase? What does it take to be like what you sound need to sound like? Can you get that experience at work by taking initiative? For the experience you can't get at work, what can you do to get it outside of work? Do you need to buckle down and tear through Cracking The Coding Interview & LeetCode exercises? Do you need to work on a personal project that showcases the skills you can't develop at work? Figure those things out as best you can, push yourself super hard, and you'll get one of those shiny jobs that breaks you out of your current career paradigm.

Also, don't overlook the value of being really good at something people really need. That's a basic supply and demand thing. If you're a badass VB6 developer or MUMPS developer, those are simply not a hot skillset for almost any employer these days.

Bigger orgs often tend to want specialists while early stage cos love generalists who can do a bit of everything.

Also, scale invites challenges that someone in companies of < 20 will not have encountered.

Hard to know without more specifics but sometimes comes down to the “different wars need different generals” mantra.

Now a couple decades later, I have the problem that nobody believes anybody can be that good on the short offline tests. So I have to schedule skype interviews where the interviewers can see me and and verify that I know far more than they do.

The second problem is actually the more difficult problem to have, but there's a certain sense of accomplishment. I'll deal with it. :)

I would, however, believe that you are presenting in such a way as to not harmonize with the expectations of the interviewer.

I've done a fair bit of interviewing on both sides of the table, with reasonable success - at least, I am mostly happy with it.

I am happy to talk to you 1:1 - email in profile.

You might have a personal marketing problem, or you might have an interviewing problem.

Small companies can be great. I tend to think "startup" when I hear small company, but I think the same rules may apply. Your tech stack is probably more fluid and you can learn new technologies more easily. These are great skills to have. But... if you are not clear about what type of work you want to do and how your skills apply to that work, it is easy to turn off a larger company because they can't fit you into a role (a "box"). A good recruiter will try to shop you around the company a bit, but there's a limit as to how much time they are willing to spend doing that.

Story: I recently had a set of interviews for a large company (the recruiting process was a mess and a joke) where I was bounced from place to place and nobody (myself included) could figure out where I fit in the company. I feel that company was very tight lipped or unsure about the roles they were hiring for, so I had no better answer than "I'd be happy in either position" to which one of the hiring managers said I would be a better fit for a startup. I came into the process very wishy-washy about what I wanted. Considering this didn't happen with any of the other companies I applied to, I blame this company. Everything was secretive and somewhat adversarial. I ended up at a much larger company with a much better reputation.

Point: If you are not clear about what you want, you may get stuck in the small company loop.

The good news is that you are getting phone interviews at larger companies. Before you take an interview, research the company and its culture, don't just rely on what you know about the company. Focus on what you have accomplished at your companies, and not the tech stack you use. I've heard a lot of candidates tell me about the complexities of the open-source stack they've worked with, and that's great, but I want to know how they will help us in our mission. Those types of nitty-gritty answers would better fit smaller companies, in my opinion (unless I am specifically asking about how they did something).

Also, larger companies have a pretty standard interview process. Data structures/algorithms and coding phone interviews. You need to practice, practice, practice on Leetcode or some other platform and even re-read an algorithms book. Smaller companies tend to be more holistic and use take-home projects, have you participate in a hackathon, whatever, but to get into a larger company, you need to learn how to play the interview game rather than just being a great coder (irony intended).

In particular the paragraphs where you talk about how larger companies want you to be a specific fit for a role. I've noticed that a lot of times my enthusiasm for working at a company comes out like "put me anywhere you feel is best, I won't let you down!" and it never occurred to me that some managers don't like filling in a lot of the gaps themselves.

So if that comes across as being indecisive then it must be a clear sign that I do not know how I would fit in. Sometimes I do get a manager saying they want to hire for a specific department and I just roll with it. And when you describe your experience, then it sounds like going with a "just put me in wherever" attitude ironically makes you sound disinterested even if that was not the intention.

As far as studying up on the data structures/algorithm specifics, I've been around enough big company discussions to have realized it. I go against the common grain in that I actually prefer whiteboard interviews over take-home test projects, too. Because everything about the interview is transparent and both sides essentially invest the same amount of time and progress with it.

Only big exceptions are TripleByte and Enova. They told me that I come across as too "junior" in giving explanations despite my years of experience. The smaller companies are probably holding me back in career growth.

This is a really useful factoid for you. You should at least try reviewing one of your past performances for "opportunities to have sounded like a senior engineer" and then, during your next performance, dial that signal to parody levels.

If how to do this is not obvious to you, a trick: explicitly verbalize more of your reasons for not doing obvious alternate approaches. Bonus points if you can make those reasons sound like they were won by working on systems operating at scale.

From your intro, my guess was that this would be a senior/junior mis-match. With 10 years of experience, employers will think of you as someone who should be a senior engineer, and they are likely to be evaluation you based on that expectation. That might be your expectation too - you didn't really say what sort of roles you were applying for, but if you're applying to "senior engineer" roles, then each company will have an implicit set of expectations about what a senior engineer can do. Some of those expectation might be made explicit in the role description, but many won't be. The role might talk about "mentoring junior developers" but there's an implicit expectation about the content of that mentoring - you have to know certain things in order to be able to teach others about them.

Those expectations will vary by company, and even by hiring manager. Some interviewers will think "A senior Java engineer must know spring+hibernate", but if you've spent your career working in the Hadoop ecosystem, then that's not likely to be true. Or "A senior engineer must understand the trade-offs of unit-testing vs integration-testing" (and be able to give the answer that they want to hear) but that's a question that is more relevant for certain project types, and not every engineer is going to have an opinion on that.

A likely problem here is that your 10 years of experience haven't given you the right set of skills to be able to answer their interview questions in ways that satisfy their (probably unreliable) interview filter. Maybe you really don't have those skills, or maybe you have them in some form, but not in a way that matches the interviewer's expectations.

Some time ago, when I was hiring into a medium/large bank, my expectations for a 10+ year engineer would be that you could be given a loosely defined problem, work your way through the details to understand the real task to be solved, design a solution (typically changes to be made to an existing system), implement and unit test that solution, assist in developing a system testing plan, assit in implementation, and understand the implications for support/operations. Each of those steps has a bunch of further detail that varies greatly by workplace, and interviews have "right answers" that assume you've done this enough times under similar enough conditions to be able to reach the same conclusions as they've reached.

As an anecdotal example. I remember hiring for a particular role, and one of the questions proposed a scenario where a particular business function was currently being driven from a spreadsheet, but they had outgrown that, and wanted to automate more of the workflow, and wanted to run a project to build a web-based internal system for that. How would you approach that? One of the candidates said something along the lines of "If they have a working spreadsheet, then I wouldn't want to change that. There's lots of risk in reimplementing it, so I would look at tools that could be used to put a web front end on top of the spreadsheet, and automate it that way." That was the wrong answer. It was a valid answer, and they explained why they wanted to take that approach, and "because risks" is somewhat reasonable, that team was not big on risk-taking. But whatever that candidate's experiences had been, they had led him to propose a solution that didn't fit with our expectations, and made what we considered to be the wrong trade-offs (and he persisted with that proposal even when we prompted him to go in a different direction). It's quite possible that some other company would say "Yes, that's exactly what we wanted to hear, you're hired!", but he wasn't the right person for us.

So - what's the solution?

You might try angling for a less senior role. It's hard when you have seemingly relevant engineering experience, to pitch yourself as a mid-level engineer, but you might need to find a way to do it. Then the expectations are lowered, you can get in the door, find out where your previous experience was leading you astray, and then be promoted to a senior role (or switch to a new company, now that you have the skills you need for the interview). You might need to trim your resume in the process so that you only mention the last 5 years of experience, and don't look too senior.

Alternatively, it might just be an interviewing issue. You might just need to translate what you do know from "small company" to "big company". Try something like https://interviewing.io/ and learn how to explain the skills you do have, in terms that big companies like.

--

edit: s/prompted/promoted

- It presumed that the existing spreadsheet would be flawless and bug-free. That is almost never the case; ad-hoc spreadsheets are often riddled with mistakes.

- It presumed that it would be a high risk/expensive task to replicate that spreadsheet in a technology that was more suitable for the job. Yet (if you assume that the spreadsheet was essentially correct in its function) it is one of the simplest implementations - you have a working specification for the behaviour you're implementing. If you are not confident in your ability to replicate a working spreadsheet, and then test that your new code behaves identically, then what are you going to be confident to build?

- It presumed that the technology used to automate the spreadsheet would replicate its behaviour faithfully. But that's only true if you use the same underlying application, so you'd only get the benefits if you automated Excel. If you used Open/LibreOffice, or Apache POI, or something similar then you still have all the risks that come with a reimplementation.

- It failed to account for the operational complexity of such a solution. Automating a spreadsheet is fragile. The resulting system would likely be a nightmare to operate.

- It failed to account for the long term maintenance cost of running a suite of business applications that are cobbled together from bits-and-pieces without any planning or cohesion. In that environment you should assume that an application will be in service for 7-10 years with the possibility of it running for 20 or more years. One of the biggest ongoing costs for that team was the number of bespoke applications we had, each using esoteric technologies and inconsistent design approaches. For example, a project to upgrade the underlying Operating System (or web browser, or database, or ...) would need to test each of those apps and potentially fix bugs. Which meant finding the source code, working out how to build it and package it, etc. Not to mention the cost of trying to stay on top of security patches for the underlying components and libraries. Consistency has massive value in that sort of environment.

You learn those lessons from experience - if your experience has been in a similar sort of working environment. I don't presume that every senior engineer has that same set of experiences and will agree on the same set of priorities and tradeoffs. But if I'm hiring you and paying a senior engineer salary because you have experience, then it needs to be experience that is applicable to the sorts of problems we face and the decisions we need to make.

What are some examples of this?

More importantly I want to know if you read the content of my post, and what are your thoughts on that content and your personal reflection of it.