At the end of last year I wanted to change jobs but I was paranoid about my raw algorithm knowledge. I've been a consultant for over 15 years. The last company I worked at for a decade. I've developed software given a specification, worked with teams to design applications, lead teams, presented to management of companies, and even was part owner in a company -- but I never was good at rote memorization.
I know my limitations and I know how to find answers.
So, for 4 months I practiced online programming problems, read interview books, and had my wife quiz me nightly. The nightly quizzes were whiteboard answers and I had to explain the solution enough that my wife understood.
In the end, I was interviewed at 4 companies: Daugherty Consulting, Google, Amazon, and Target. (For Google this was my second interview in two years. The first interview was a shock, I froze during the preliminary interview, and for two years contemplated if I'd ever quit my job.)
Daugherty never had me do whiteboard programming but did ask me some algorithmic questions. These were much easier to answer verbally. In the end I was told I didn't have enough experience in consulting working with large companies. (This was a bit of a shock but whatever.)
With Google, I never got past the first round. I felt very good with my solution coding in a Google Doc, but, they had wanted me to implement the Python bisect_left function. Instead I just used it to solve the problem.
At Amazon I made it onsite, but again, I failed to whiteboard a hashing function to their satisfaction. They told me it could have been overlooked if my architecture skills were stronger. They did complement me highly on my communication skills, which I appreciated. (I had worked for two weeks rewriting my accomplishments journal using the STAR[1] format.)
Target (where I work now), was completely different. I was given a choice of real-world-like problems to solve and a couple weeks to code. Two were pretty heavily algorithm/math-focused but the third was right up my alley -- implement a microservice backed by a data source and a different (potentially flaky) service. I took my time, wrote code I'm proud of, deployed it on Google Cloud, and explained my solution in detail to a Principal Engineer. There were still personality and experience questions (and I think also some algorithm questions) but nothing like my other experiences. It felt much more grounded in reality. Are you a solid developer, good communicator, and good fit for the company. In the end I didn't get the exact position I applied for but I'm still extremely happy.
My takeaways:
1. Maintaining an accomplishments journal as more beneficial than I could ever imagine. I write down everything I'm proud of - when I'm proud of it even if it seems minor. I can always delete it later. Also, the STAR format is actually really good.
2. Don't stagnate in learning. Technology and methodologies are changing all the time. I don't follow every fad or code in my spare time but I feel strongly taking some time periodically to maintain a level of expertise is a good investment.
3. Knowing my strengths and weaknesses really helped me focus while preparing for my interviews.
4. Learning from interviews and maintaining confidence was big for me. I took notes immediately after each interview of what I wanted to work on. I asked for as much feedback as I could get. These notes made it back to my journals and are things I'll refresh time-to-time because I know nothing is a given. Who knows what I'll want in another 15 years.
Just quickly thinking of where there might be a lot of images/documents modified quickly: web browser cache, photo management software, antivirus software.
I think it'd be easier to isolate applications and data like Cubes OS instead of trying to create a universal rule set.
> Conspiracy theory: This change is dictated by the Google AMP team that wants to take over the world without us knowing
I was just about to write this but I don't necessarily think it's that far off.
With signed exchanges, AMP pages have the ability to hide the fact you're accessing content through Google [1]. In 2016 Google wrote about testing 'mobile-first indexing' because more people are using mobile devices than desktop browsers [2].
If you're thinking of learning CF, only do so with the understanding that it's now a niche product mostly used in government and large companies. Learn it either as a hobby or look at the Lucee source for educational purposes. Even my last company is moving away from CF.
About Lucee ...
I actually helped the company migrate away from Adobe ColdFusion to Lucee due to a chance in Adobe's licensing. We migrated a large, 10yr old, application and all clients over to Lucee in about 1 year.
Lucee is a nice platform but I'll warn that it's not as polished as Adobe CF and there's some difference in features. You'll run into rough edges in their documentation and language implementation (especially the scripting languages). One nice thing I really enjoyed was being able to download the source and figure out how my CF code was actually being compiled into Java. It took me a few days to understand the parts I needed but I actually figured out some issues I was having. I also was able to build Lucee from source, just for learning, which was really nice.
There should also be an explicit call out to both tooling and community. Even if a programming language ticks all the other boxes, Without a sizable and stable community to constantly push tooling languages will fade, not necessarily die.
In my past job I was ColdFusion programmer for 15 years. ColdFusion ticks all the other boxes.
* Created in 1995 and is a very mature platform
* Easy to learn and productive
* I was very comfortable hiring multiple ColdFusion engineers over the years
But, the community moved on and the tooling is now nonexistent compared to other programming languages. ColdFusion will live on, but as a shadow of what it once was. Which is unfortunate because I actually enjoyed the language and platform.
The points under "Cultural improvements" can't be stressed enough:
* When only one member of that team is remote, they often suffer a combination of isolation ... and organizational burden ...
And their approach to foster inclusiveness is a great checklist:
* We nominated a site lead ... to be responsible for the overall happiness and productivity of the hub.
* We ensure that our leadership regularly visits the hub via Zoom meetings to lead discussions, answer questions, and provide a sense of connection.
* We encourage virtual coffee chats to promote a sense of belonging.
* We survey the team regularly and review feedback and people data, so that we can understand both the shared needs of our employees and the particular needs of a hub.
Remote doesn't have to mean work from home, and I can attest that having too few remote employees and not enough cultural investment is a recipe for failure.
An ole employer had a satellite office with just a few employees. The main office was in a city in a different state. There were many occasions where we were in the dark about talks that'd happened at HQ, activities, and even some times when the owners would let folks leave early on Friday! Without dedicated leadership and effort to make sure employee are included, even a small satellite office can feel isolated and neglected.
In the end there were just 3 engineers total, all in different teams. I left a year after the company restructured, closing the satellite and everyone was WFH.
I would speculate that for companies these two statements will be exclusive:
• Company saves money by not having to hire Linux sysadmins
• Company saves money by not having to pay for managed cloud products if they don't want to
As a developer I want to right code, not manage a Kubernetes installation. If my employer wants the most value from my expertice they will either pay for a hosted environment to minimize my time managing it or hire dedicated staff to maintain an environment.
I worked for a brand & marketing company for 15 years and I observed that most of my clients had pretty short memories when it came to how they felt about me. If the last few milestones were really great they quickly forgot an incident. Obviously, the more impactful an incident, the longer/more positive milestones had to be. An incident too impactful got your fired - but, in general, this was my experience.
Even in their recent history Microsoft has repeated incidents, but also has some very big positive milestones. Also, keeping in mind, some customers will only see the positive milestones.
Dismissing a successful person but seeming "dumb" person is a benefit to them. Now, they can continue succeeding with less scrutiny.
For a long time I thought many politicians were "dumb" based on their public comments, propelled only by their connections. Now, when I look up some politicians who's spouting objectively false / misleading statements and find they've graduated a top-tier university and have a JD I realize these are not intellectually stupid people. They're skilled in their field, have drive, and less empathy/morals than others.
At the end of last year I wanted to change jobs but I was paranoid about my raw algorithm knowledge. I've been a consultant for over 15 years. The last company I worked at for a decade. I've developed software given a specification, worked with teams to design applications, lead teams, presented to management of companies, and even was part owner in a company -- but I never was good at rote memorization.
I know my limitations and I know how to find answers.
So, for 4 months I practiced online programming problems, read interview books, and had my wife quiz me nightly. The nightly quizzes were whiteboard answers and I had to explain the solution enough that my wife understood.
In the end, I was interviewed at 4 companies: Daugherty Consulting, Google, Amazon, and Target. (For Google this was my second interview in two years. The first interview was a shock, I froze during the preliminary interview, and for two years contemplated if I'd ever quit my job.)
Daugherty never had me do whiteboard programming but did ask me some algorithmic questions. These were much easier to answer verbally. In the end I was told I didn't have enough experience in consulting working with large companies. (This was a bit of a shock but whatever.)
With Google, I never got past the first round. I felt very good with my solution coding in a Google Doc, but, they had wanted me to implement the Python bisect_left function. Instead I just used it to solve the problem.
At Amazon I made it onsite, but again, I failed to whiteboard a hashing function to their satisfaction. They told me it could have been overlooked if my architecture skills were stronger. They did complement me highly on my communication skills, which I appreciated. (I had worked for two weeks rewriting my accomplishments journal using the STAR[1] format.)
Target (where I work now), was completely different. I was given a choice of real-world-like problems to solve and a couple weeks to code. Two were pretty heavily algorithm/math-focused but the third was right up my alley -- implement a microservice backed by a data source and a different (potentially flaky) service. I took my time, wrote code I'm proud of, deployed it on Google Cloud, and explained my solution in detail to a Principal Engineer. There were still personality and experience questions (and I think also some algorithm questions) but nothing like my other experiences. It felt much more grounded in reality. Are you a solid developer, good communicator, and good fit for the company. In the end I didn't get the exact position I applied for but I'm still extremely happy.
My takeaways:
1. Maintaining an accomplishments journal as more beneficial than I could ever imagine. I write down everything I'm proud of - when I'm proud of it even if it seems minor. I can always delete it later. Also, the STAR format is actually really good.
2. Don't stagnate in learning. Technology and methodologies are changing all the time. I don't follow every fad or code in my spare time but I feel strongly taking some time periodically to maintain a level of expertise is a good investment.
3. Knowing my strengths and weaknesses really helped me focus while preparing for my interviews.
4. Learning from interviews and maintaining confidence was big for me. I took notes immediately after each interview of what I wanted to work on. I asked for as much feedback as I could get. These notes made it back to my journals and are things I'll refresh time-to-time because I know nothing is a given. Who knows what I'll want in another 15 years.
[1] https://en.wikipedia.org/wiki/Situation,_task,_action,_resul...