End of this month is my last day at Microsoft. I didn’t plan this. My original plan was to keep being a representative of that company and work on the amazing products it builds. Market forces, however, caused yet another reorg and as there was no other department with openings for remote work in Germany, we agreed to split. Who knows? Maybe things will change, but given the current trend of all big tech companies to “healthshrink”, I looked around for smaller, local companies.

Having been focused on my employer for 8 years without any interests in other opportunities I dived into the job market, brushing up my resume and using my network of great folks I interacted with over the years. So after a month of unemployment benefits, I will start a new role on the first of July.

All in all I sent out 19 applications, 11 of which got offered to me by contacts, recruiters, or the companies directly. Yes, I am a lucky person with a lot of privilege. But I also have a 20+ years track record I worked very hard on. My main source was LinkedIn but I also paid for two more services, both of which were pointless, but at least the payment is tax deductible.

I had a stressful time finding and choosing, mostly because of the people I met in the process. Everybody was nice and exciting to get to know. The offers, too, were really good and some made impostor syndrome hop about like a mechanical cymbal wielding monkey in my head. I had a hard time disappointing some dedicated people and hope I didn’t burn all bridges. In short, recruiters are people, too, so treat them like you want to be treated.

I also want to point out that the list I’m about to write feels weird as it may make me come across as a spoiled brat – at least to me. But I think it might be helpful for companies to know which things can cause someone like me to say no, even when all interactions were positive up to the last moment.

So, without more beating around the bush, here goes:

Work from office / bonkers hybrid work demands

With the hiatus in the pandemic it seems that most companies remembered that they have expensive offices their employers should use. Often they also had bad experiences with people working remotely. And I get it. Working face to face in a small company is a lot more efficient. I’m looking forward to working from an office from time to time again. But I don’t see the point of being a lead of a distributed team and having to do this from a place with a one hour commute when all my interactions would be virtual anyway. One company even asked if I could work from their office 400 kilometres away twice a week.

Remote work in tech is the most obvious thing to do – so don’t force people to waste time on the road who don’t want to.

Complex and rigid application processes and systems

Bureaucracy and red tape in companies is generally mentioned as one of the main sources of employee dissatisfaction. Therefore it is baffling to see how many companies made me jump through rows and rows of hoops – some of them burning – just to get to the first interview. I get it, at Microsoft we were also swamped with applications and there are many SaaS offers out there that promise a company to deal with that in a convenient fashion for the recruiters.

But having to replicate all the information in a secondary system after people found me on LinkedIn and got my CV through the “Easy Apply” process was always the first indicator that we won’t get to where we both apparently want to.

I keep my LinkedIn profile tidy and up-to-date, same with my CV. So having to fill in multi-step forms, some of them with two factor authentication and CAPTCHAs with the same information is not only a colossal waste of time, but also worries me as it means there is a copy of my information that will not get an update when I change my CV.

Other companies made me sign an NDA to get information about the job. Well, as an open source advocate this doesn’t bode well to what I will create in this role.

I wrote in more detail about one company asking me to answer a lot of questions in a written interview. They then sent me an online test to assess my skills that I had to do within a week and took three hours, demanding a full block of that time as you couldn’t pause and continue.

As stated in that earlier post, I get the idea of treating every hire equally, but treating me like applicant number 2324234 instead of catering the test to my skills and the role was another big flag for me.

I have to mention one special case though: one company asked me to do a case study showing my skills and explaining how I solved issues and paid for my time. This was a very interesting approach which gives the company something to work with and the applicant a feeling of not wasting time.

Super aggressive timelines

Starting a new job is a big decision and nobody likes to get badgered. I understand that it’s also a lot of work for companies to hire new folks and get them up and running.

I explained in each communication when and why I can start and that I needed some time to stomach the change and get ready for the new job. And yet seven companies asked if I could start weeks earlier as things are broken and it would need my amazing fixing skills right now. This is flattering, but also a big red flag.

Another thing several companies did was send me a contract that I needed to digitally sign that had a fixed offer expiration date two days later. Sometimes these came on a Friday and I was asked to sign by Monday. Huge, 9-10 page contracts full of boilerplate not enforceable or even applicable.

This isn’t “I read the terms and conditions” before downloading a demo app. This is our professional work agreement. Companies and applicants should expect that there is a necessary review and alteration period.

Automated responses and processes with no context of your application

Especially with US companies but also with agencies and government affiliated companies I had a few run-ins when it comes to automated gatekeeping. Although the job offers mentioned “degree or comparable experience” many had forms where adding a degree was mandatory and I got automatically filtered out.

It also felt like a massive waste of time being contacted by recruiters because of your profile just to be asked by every single interviewer to repeat the information in the profile in interview forms. You can give an applicant a much better feeling of being in an onboarding process if information already provided gets sent on through the stages.

Boilerplate social benefits without insight into local or personal requirements

There is a big difference between a company providing a social benefits net to feel safe in and a company that tries to impress you with perk offers that seem great, but ultimately don’t apply to you.

Some companies I talked to obviously partnered with a third party provider that offered a US package that would make folks there happy but didn’t even cover the basic legal requirements in Germany. Workplaces need to contribute to the public healthcare fund or cover part of your personal insurance.

It is great that companies offer social perks, but the most grating thing I found in some of the offers is that they are a non-starter. Many social perks, like a personal pension fund partly covered by your employer, need years of accumulation to make sense. I had quite a few companies that offered them but when I asked about the average retention of employees in the company people admitted that most folks stay for a year and move on. This felt like a strange disconnect.

Aggressive haggling and the myth of competitive salary

There was no doubt that it would be tough for European companies to match the salary and compensation package of an 8 year career in a US tech giant. So I slashed 20% of what I had earned for the convenience of working for a company that isn’t confused about European tax, social packages benefits and support instead of perpetual growth demands.

However, some of the offers were just incredibly low considering the high taxation here. Even worse were offers that had no range or figure but offered “competitive salary” instead. When I offer “competitive skills” people probably would have questions, too.

I was very candid in my demands, which went down really well with all the people I talked to. When candid answers then told me that I would earn more than most of my peers or even managers I knew I couldn’t do it. It’s good to be clear.

Huge discrepancy between skills offered and skills needed without a plan to cover the gap

I was flattered by some of the offers as it would mean I had to push myself to learn new skills or transfer to have the ones I got into other environments. It’s also a concern when there was no mention of an adjustment period or introduction to internal systems and processes programs.

Sure, some skills are easy to transfer, but I remember vividly how much I hated dealing with managers coming in not knowing half of what I did and keeping things generic not to be found out. Maybe I was too chicken there, but it would be good not to be thrown into situations where you need to prove your skills to yourself and to the people you are supposed to lead.

No job offer will be a perfect match and it is a back and forth to meet in the middle. But it would be great to have clarity on what the process of getting to learn about the company environment is and how much time you have to get enough confidence to start running the team without feeling like a fraud.

Things applicants and companies can do to make this smoother

All in all, I had a positive experience on a human level but I found that there is a lot to be improved in the processes of finding a job in tech even on the senior level I am at. I can only imagine what it would be like to apply as a junior where the human excitement of your application isn’t as high. So here are some things I found any applicant should do and I could have done better.

As an applicant you should:

• Get ready to have a lot of demands, things to fill out and do. I was kind of rushing things in the beginning, freaking out that I will need to find a new job soon. This lead to me applying for a lot of things at the same time and feeling overwhelmed with the work this meant. Don’t panic. You will find a job eventually. It makes a lot more sense to focus on a few offers and prepare yourself thoroughly than casting a wide net.
• Have a clear goal what you want to do – there are a lot of exciting job offers, but if you apply for the reason of having a “cool” job, you ultimately don’t have the skills for and don’t feel you will get the time to learn them upfront, you are wasting people’s – and your – time.
• Have a list of “must have” benefits and perks you don’t back out from – that includes a minimal salary and work situation definition (remote, hybrid, on-site – in the latter case including the information how long of a commute you are ready to take on)
• Do your homework learning about the job offer, the company behind it and what you specifically can bring to the table. This includes a CV catered to the job application and role.
• Communicate clearly your earliest possible start date and availability for interviews and tests – I used Calendly for that.
• Communicate if you have other offers and by when these decisions are due – this is great to speed up the process
• Appreciate the efforts and time of people involved – recruiters and interviewers have to deal with a lot of applications. Be on time for your interviews, don’t leave people hanging with answers and have your materials ready for the different steps of the process.

Companies should:

• Value the work applicants put into the process. We spend a lot of time writing and optimising our CVs and LinkedIn profile, so use this information but don’t ask us to repeat it all the time or fill out your internal systems.
• Be aware of the fact that automated systems with arbitrary gatekeeping mechanisms are great to stem the flood of mass applications and fake applications but will make you miss out on great talent and start the process with a bad experience if there are false positives
• Value the time people need to ponder your job offer and give enough time read through contracts
• Be aware that a job application and how it is handled is a first impression that goes both ways. We always have the impression that applicants have to put their best foot forward and spruce up to get the job, but in a highly paid environment with a severe lack of talent this very much goes both ways.
• Give a sense of clarity of what the company wants to do in the next few years and how it would affect the applicant. Freelancing is always an option and people choose to join a company for the reason of having security, not help a company even find its place in the market.

I hope this is helpful to some. It helped me, writing it down. I am happy to have met so many interesting companies and people during this last month and hope to keep in contact and work together in other capacities.

You can download the GPT model and interrogate local files using Python without having to send any data to the cloud.

PrivateGPT is a python script to interrogate local files using GPT4ALL, an open source large language model. It is pretty straight forward to set up:

• Clone the repo
• Download the LLM – about 10GB – and place it in a new folder called `models`.
• Place the documents you want to interrogate into the `source_documents` folder – by default, there’s a text of the last US state of the union in there.
• Run the `ingest.py` script – this can a long time. On this MacBook M1 it was 2 minutes though
• Run the `privateGPT.py` script and you get a prompt in your Terminal:

I asked it what the US president has to say about the situation in the Ukraine and it gave me a synopsis and where in the document the information is from.

Neat!

As part of one of the job applications I have going I was invited to do a frontend expertise exercise. The role I am applying for is head of frontend for a company. Whilst I found it odd to have to go through this, with my track record being highly visible, I thought, why not? After all it feels sensible to make everyone do the same work to get a job, should you want to compare directly.

Incidentally, this was a big no-no in Mozilla – we never compared applicants, we just measured them on their own results.

I was already confused about the format of the exercise. I had to go to a third party web site and start the assessment. I had all in all 3 hours to finish it. The first 25 minutes were a multiple choice survey that would cover the basics of web development, CSS and accessibility and the rest would be a JavaScript exercise. I already found this painfully askew and maybe a damning view of what web development is these days.

The frontend knowledge part

So I started and got a few multiple choice questions that should validate my chops as a web developer. The questions were:

• Which REST method to use for what action
• What a good REST URL structure would be to access an element of a collection by ID.
• Why JavaScript is a great language offering me four choices of its structure (event loop, object notation…)
• Why Python is a great language for the web
• What the benefits of Kubernetes are
• Defining what Docker is
• What accessibility should be part of (design, supporting screen readers, testing, all of the above)
• How to place a DIV to the left of an element (with float being the only option, no flexbox or grid)

This was nothing short of a mess. This was a frontend role. Why would Kubernetes and Docker be in there unless I’d also be responsible for the developer environment and setup. And the frontend related questions were borderline ridiculous. Sure, finding out that accessibility should be part of every step of the process is good, but the question was so vague and there were no details asked what it would need to make a product accessible. What are the main stumbling blocks? What are things we can not do easily and what would be a workaround to offer as an alternative. There was no question about HTML, structure of documents, semantics or interactivity of elements. There was nothing about performance, nothing about security, nothing about the DOM, nothing about CSS other than a hack we should not be using any longer.

The coding part – should I build something for the web?

OK, maybe the JavaScript test would make up for it. Maybe build an app, create an interface and show what I know about that and how to write code that my team later on would find easy to understand and maintain.

The product asked me to either use an in-browser IDE for the task (Monaco, it seems) or clone a GitHub repo and use my own setup. Of course, I chose the latter. It was a sample app with tests already set up and I needed to install it with NPM and use Node to test my solution. No interface at all. Nothing. Just a test suite and a task to complete. The task was to implement a calculator with an alternative syntax to the usual infix notation. I had to write a function that would take a string and return a number. The string would be a mathematical expression in prefix notation. So instead of 1 + 2 it would be + 1 2.

I was a bit confused. I have never seen this notation before and I have been a web developer for 25 years. I have seen a lot of things, but this was new to me. I had to look it up and found that it is a notation that is used in Lisp and other languages. I was not sure why I would need to know this, but I thought, OK, let’s do this. I have 2 hours left, so I can do this.

In the end, I wrote a 20 line JavaScript in 10 minutes and was done. A few gotchas were reversing the array of tokens and flip the order of operands when doing subtractions. How this relates in any way to a frontend role? No clue.

I do like the idea of giving applicants a GitHub repo to clone, set up the dependencies and work on the script until all tests are green. This should be a basic workflow we all are familiar with.

Hiring amazing frontend developers by giving them vague frontend task

The best frontend developers I ever worked with were in Yahoo back in 2006. The reason was partly because we hired people we already knew from mailing lists, conferences, people who wrote about frontend tasks and were keen to share their knowledge.

Another big part of it was the interview process and specifically how we tested people’s frontend skills. What we did was give them a design and a specification how the interactions in that design would work. There was a collapsible menu and a carousel. There was a form that we asked to add client side validation. The design had a few accessibility problems and some subtle inconsistencies.

Applicants could to this in their own time and send us the result (as a zip, most of the time – I had mine hosted on my server in my interview). We then invited them to come to the office and talk us through their solution.

We would ask applicants to:

• Talk us through their solution and why they chose it.
• Show us how they would debug a problem and how they would find out what the problem is.
• Show us how they would test their solution and how they would make sure it works in all browsers.
• Criticise the design. What would they change and why?

The crucial part was not the solution itself. The crucial part was how they explained their solution and how they would approach a problem. We were not looking for the perfect solution, we were looking for people who would be able to work in a team, who would be able to explain their work and who would be able to find out what the problem is and how to fix it.

I remember vividly one of the applicants not knowing that I was part of the interview process and them having used a script from my JavaScript book to solve the solution. I asked them to explain the code and they did. I asked them what they could think of to improve it and they did. The code was open source, so there’s no harm done and I did end up hiring that person.

That, to me, is a sensible test to see how someone approaches web development. What I just filled out is probably a good test to see if someone is a good developer, but it is not a good test to see if someone is a good frontend developer. Give people things to fix. Give people a product that has problems and ask them to improve them or explain why they are issues. Frontend is about building things people use. There is no single solution, there are many ways to solve the same problem. The crucial part is to understand the problem and to find a solution that works for the people who use it. And to understand the environment web products are executed in (browsers) and the technologies that power the interfaces of the web: HTML, CSS and JavaScript – not Kubernetes and Docker.

Hooray, Goto conferences just released the video of my talk on Developer Tools.

If you want to play along with the examples, they are available on GitHub.

First of all, congratulations. You managed to kick off the next step of computer and human interaction evolution. Of course we’re in the middle of a hype, but there is so much good in AI generated content and conversational interfaces, it’s pretty safe to say all things “computer” will have some part of this included going forward.

You have an issue though: relevance. Or, as some call it, hallucinations. Systems fed with lots of data that wasn’t quite quality controlled that manage to make even erroneous data sound like the best thing since sliced bread could turn out to be disastrous in the long run. Just because something sounds clever, doesn’t make it good.

Here’s the bad news: the wisdom of the masses will not save you. As someone who worked on products with millions of users and highly visible interfaces like browsers I can tell with great confidence that people will not downvote and report wrong results.

The idea of increasing the weight of results that were the end of a conversation is also flawed. It’s like asking your obviously miffed partner what’s wrong and they answer “nothing”. This is not the end of that conversation.

Dissatisfied users do not put an extra effort in to downvote the wrong result – they just leave as they feel that they already wasted enough time with your product.

How to make that better? Well, one way is to give your systems context and limit it to that one. GitHub Copilot for docs is a great example of that.

The other, and here is where I come in with my pitch, is to consider editors, writers and tech experts to flood your product with great solutions, downvote obviously wrong ones and annotate others to explain that whilst this is a solution, it may come with a caveat.

The great opportunity you have right now is that the market is saturated with laid off people who have some time on their hand. These are experts in certain fields: programmers, designers, product managers and many others. Ironically, you will also find a lot of technical writers to work with right now as they have been laid off as part of an overreaction to your success. Who needs authors when the machine can generate lots of text for free (or pennies in traffic)?

Of course, creating a community of experts to talk to your machines takes time and effort. Guess what? A lot of community managers were also laid off when companies closed their tech communities.

As an expert editor or “GPTeacher” I could get in addition to the upvote, downvote and copy icon also one that allows me to edit the response. This would go into a review process with two others and then back into the system.

As a developer known to you as a “GPTeacher” I could write code examples on GitHub and tag them with a special tag #gptfodder (or, whatever), and again, after a peer review with others it’ll get more weight to be shown in a higher frequency in conversations people have with your systems.

I know, all of this feels a bit old school and Wikipedia-ish. But, it worked in the past and it scales much better than hiring a lot of people in outsourcing markets to clean up things that are obviously wrong.

We are at a crucial point here. Some governments already work on laws to block your systems as there is no attribution or licence information in your results. It would be a shame if we let machines educate people the wrong way because we were not interested in giving the system human supervision when it was needed.

Want to know more? Let’s start a conversation and build a community of enthusiastic experts that are OK to teach the machine to do better rather than hoping people will be able to see the flaws in the conveniently offered, clever sounding solution.