I’m in the middle of switching jobs, so recently I had the opportunity to talk to a couple of companies. “Job interviews” was always a topic that I was very interested in, so I thought I summarize what I had learned over the years in a blogpost.
My goal with this is twofold. First to share some specific points that help me to find the company that could be a great fit for me. Second hopefully others can also learn from this. I see so many articles from the “other side”, namely from recruiters and HR people. With this post, I’d like to describe how a developer sees this topic. Obviously, recruiters and HR people deal with this topic daily, and we (developers) don’t, so maybe I can help the community with this.
My evolution with job interviews
I had my first job interview about 13 years ago when I wanted a summer internship as a high school student. I still remember that my approach going into the interview was something like this:
“Please, please don’t ask anything that I don’t know; it would be even better if you wouldn’t ask me anything. I know nothing, but please give me the job!”
Obviously, this is terrible, but most people start like this.
Now this time, about 13 years later, when I went into an interview, my approach was something like this:
“This is me, this is what I can bring to the table, these are the challenges I'm looking for. Tell me what your product is and where you need help with it! If it seems to be a fit, then show me your product, show me the code and I’ll tell you what I’d do. After that, we’ll see if it’s still a fit.”
Of course, there is more to it, but I think you already got the point: over the years I realized what’s important to me and how I should approach a potential future employer.
Let’s get a couple of things out of the way
One thing I’d like to clarify upfront is that this isn’t a review about companies that I interviewed with, so if you want to know which companies I talked to (this seemed to be an important question to people :) -which it isn’t!-- ) then you won’t find answers in this post.
It would be simply unfair to openly write about my specific interviews including company names. I expect those companies to not write public blogposts about me being in an interview situation either, so it would be simply unfair from me to do that.
The goal here is to share what I've learned over the years to help other devs find the right company.
All right; let’s get started.
1. General lessons
First of all, I’d like to point out that finding the “best fit” heavily depends on your personality and your specific situation. I think the whole point of interviewing is to figure out if a candidate with her/his technical knowledge is a fit for the company and (I guess more importantly) if this candidate personally is a fit for the company and even more importantly (and this is what HR people always seem to forget): if the company technically and culturally is a fit for the candidate.
2. Know what you want
I noticed that the more specifically I know what I want, the easier the job search is. And by this I don't mean that it's easier to find companies; I rather mean it's easier to filter out companies. Most of you know that I'm specialized on .NET and Microsoft technologies and, by reading this blog, you also know that I really enjoy creating content for developers. This includes blogging, creating tech videos, giving tech talks, creating online courses, etc. Consequently, I looked for a company that can use most of these skills, so I automatically filtered out companies that looked for devs, who sit in the corner all the time and just want to write code. Being a dev who only wants to write code is perfectly fine! It's just not for me. The point is: figure out what you really want and be as specific about it as you can.
3. Communicate clearly what you want
Once you know what you want, it's super important to communicate it clearly. My mission statement was like: "don't hire me for just writing code, hire me for making your product successful in the .NET/Microsoft world". Obviously, I'm a dev and I only applied to engineering jobs, so I always made clear that writing code is my primary skill, and I really enjoy doing it, but I also always stated out loud that I'd be pissed if I'd only have to code. I want to talk about the products that I create, I want to show them to the world and talk about them in videos, conferences, etc.
Again, you don't have to be the same – but you should communicate clearly what you want.
4. Start before you need a job
Now that you know what you want and how to communicate that the next task is to find companies that need people with your skillset and your "mission".
Finding "the right company" starts way before you realize that you are looking for a job. Some people suggest that you should maintain a good relationship with companies and colleagues from other companies because at some point you might need a job. I think this is a very selfish and bad approach.
What I do instead is that I maintain a good relationship with colleagues and companies that do interesting stuff, regardless of the fact that I might need a job later. I do this simply because I can learn from them. (Well, ok, I’m a meetup organizer, so maybe I do this because I know that at some point I can use their office space as meetup location, but please don’t tell them!)
I’m always open for learning new things, and I’m always happy to visit a company’s office, for example when they host a meetup. I think every developer should know what certain companies in the industry do and that way when you need a job you already know what companies could be interesting to you.
In my last round of interviews, I knew all the companies that I interviewed with. I knew exactly what they do, and I also knew people from those companies. So, none of my interviews start with “We are company [X], let me tell you what we do!”. I always skip that part and I think that is a huge advantage.
You can do the same: go to meetups, find interesting people on twitter and interact with them, contribute to open source projects, simply be part of “the community”! You will naturally end up with people that work on things that you find interesting.
5. Avoid agencies, talk directly to companies instead
Previously I had contact with a couple of recruiting agencies and it was always a waste of time, so very early in my career I decided to completely avoid them.
The business model of these agencies is this: since developer salaries are relatively high, it is a lucrative business to recruit developers. Usually, a recruiting agency gets the equivalent of a couple of months' salary per developer. So, their goal is to recruit as many devs as quickly as they can and generate a high turnaround in the area, so they can place those engineers to other companies.
The problem is that they have no interest in finding a place where you can be happy and productive, for let’s say, 10 years – that’s not a good deal for them.
Another fact you should consider is that sometimes companies give signing bonuses. Some people are hired directly, others through recruiting agencies. I have no data about the relation of those two groups, but I think we can have a very strong assumption that if a recruitment agency gets, let’s say, 5 months' worth of salary for you from your future employer, then the company won’t feel too motivated to pay you another couple of months' worth of salary as a signing bonus. Again: maybe I’m wrong, I don’t have data about this, but this is definitely something you should think about!
Also, you should know that most top tech companies don’t even accept applications through random 3rd party recruiters.
This one is for example from Google:
Here is what Amazon says about this:
And I can go on with other companies. The fact is: if you go to a recruitment agency you won’t end up at those companies, simply because those companies don’t need the services these agencies offer.
One exception is that some of those top tech companies work with “Recruitment partners”, but in those cases, they usually talk to you as the company itself and don't even offer jobs at other companies – but this is a whole different story; this is more like recruitment outsourcing.
Plus, there is a final reason I don’t work with agencies: our job is a fairly significant part of our lives. We spend more time with our coworkers than with our family. Therefore, it’s super important to me to talk directly to a potential future employer early on. I see no point in outsourcing this to an agency. Seriously, it’s like: do you send someone for the first 2-3 dates to precheck a potential partner? Well, maybe some of you say “yes”, but let me tell you: that’s not normal! :)
Maybe there are good IT recruitment agencies out there and maybe there are scenarios where it makes sense to use them, but to me it never seemed useful, so I simply avoid them.
Facts are: a) they generate costs for your employer and it’d be naïve to think that you won’t pay anything for that service and b) you will never get employed by a top company through a recruitment agency.
6. Some dealbreakers
There are a couple of things that count as red flag to me. One typical example is when a recruiter wants to know my current salary early in the process.
It’s important to talk about money, but in the first 20 minutes of the very first call it’s just simply a sign that the interviewer wants to collect data. This is definitely something you should be prepared for. I think there is no right approach to this, the best thing to do is to be prepared and consequent.
Here is what I do: I’m absolutely against this practice. If this happens very early I simply say: “To me, this is a red flag. Collecting such data is against my values. Thanks for your time, but this interview process is over” – and I simply drop out from the process.
Btw. just think about it like this: as a dev you usually have access to sensitive customer and company data. I, for example, have had access to memory dumps from customers (yes, probably containing passwords!), to the whole source code of the company, potentially also code from customers. As a dev, you also usually know who the customers and prospects are. So, if devs give out their very own relevant private data so easily, then I don’t even understand why those companies think that they can trust them with the company’s and customers’ sensitive data.
One last point to giving out salary information: usually if someone asks me about my previous salary then I simply ask their salary. Keep in mind: you don’t break the law by asking questions! It's the opposite: the whole point of interviewing is to ask questions, and that is true for both sides. Asking the same question that the interviewer asks is also fine!
I still remember when I was interviewed by 2 people with very high, fancy titles and they asked me what I earn. I simply said: “What an interesting question! Let’s talk on an equal footing! What is yours?” and I simply pointed my finger to one of them. Of course, there was 30 seconds silence and none of them gave out this information at the end. I didn’t do it, either.
If they had answered my question, I would have been happy to talk about it myself, of course. Again: there is no law whatsoever that says you cannot do to them what they do to you. Almost every job offer nowadays says things like “transparency, openness, equality, open-door policy, flat hierarchies”. Well, based on the story above, all of those were bullshit at that given company – it’s nice to find this out way before you sign your contract.
The other dealbreaker for me is, when during the interview process they forget to ask who I am and what I look for. Lots of interviews are carried out by other developers and they want to know whether the applicant is a good developer. This is absolutely a good thing, the only problem is that it’s not uncommon that you have a 1-hour interview scheduled and then you talk about technical stuff for 90 minutes (which is super cool btw, I always enjoy that!) and then they say “Ok, this was really good, we are overtime, do you have any question?”
And then I’m like: “Yes, sure! What problems do you have currently? What are your values? Why do you hire? Who do your devs work for? -For a team lead? Product owner? CTO? For the actual user? (How radical that’d be!) Why do you have only white dudes in your management? Is everyone white dude? Do you want me to only write code? If not, then where can I help other than coding? Btw. I would like to talk about your product at conference [X], are you ok with that? Can I make YouTube videos about it?" ...the list usually goes on... "And all that btw. you should answer in -30 minutes”.
The point is: if the interview is structured in a way that the only thing they want to figure out is whether I’m a technical fit, then I automatically drop out voluntary. Again: we spend more time doing our job than with our family! It must be way more than “technical fit”!
I realize that lots of candidates don’t care about these kinds of things, but if the interview has a fixed structure with “~99% of the time: we ask the candidate, and ~1% of the time: the candidate has the option to ask questions”, then to me it’s not a fit. Good interviewers can deal with this very well and they can spot if someone would like to have more than just an average 9-5 job. Side-note: looking for an average 9-5 is absolutely fine! The point is: offering simple 9-5 jobs and listing all the catchy buzzwords is bullshit and that you should spot during the interview process.
7. Don’t try to change their processes
There are different approaches that interviewers use. Some of them grill people on hardcore algorithm questions, some of them ask more behavioral questions, some of them have a set of values and try to figure out if the candidate shares the same values, and some of them prepare some random technical questions.
Unless you talk to a very small company, or you are some super famous person, there is no chance that they’d be willing to change anything in the interview process just because you ask for it.
Therefore, I usually let them do whatever they want to do with me - unless it’s physical torture. If they want to grill me on hardcode algorithm skills, I’ll play the game, and similarly, I’m also fine if they want to find out my values.
Some candidates for example simply refuse to do whiteboard interviews.
I think you should figure out if there is anything which is not uncommon in the industry that you are unwilling to do (like algorithms, whiteboard stuff, pair programming), and if there is something, then you should tell this upfront and drop out of the interviewing process very early. I’d suggest never going into an interview and then saying, “Well, I don't do whiteboard interviews”. – Discuss this upfront!
On the other hand, I make sure that everything I want to cover gets covered (see my 2nd deal breaker). So, I never ask companies to change the interview process, I simply ask for doing additional things on top, if they don’t cover important issues/questions.
Maybe a couple of words on whiteboard interviews and typical “Cracking the Coding Interview” style questions: I know that lots of candidates hate them. I think those interviews are good for identifying pure brain power. You can figure out if someone is plain smart by asking those questions. However, you won't be able to figure out if someone writes maintainable code, would be willing to mentor other people in a team, and you won’t find out if this person can ship a software product that actual users would be happy to use, either.
And to me, the most troubling part is that sometimes companies completely misuse those types of questions. They simply think that those are ready-made questions and by asking those, you can completely assess a candidate. Now you, the candidate, can easily spot if an interviewer falls into this category.
I repeat: there is no law whatsoever that says you cannot ask questions in an interview!
Many times, a person with a fancy title comes in and asks questions that are literally in that book. I never judge interviewers, but sometimes I have a feeling that managers who haven’t coded in 10 years try to assess candidates’ coding skills, and I think that this is problematic.
I simply call this “fake interviewing” – where there is nothing that you or they can learn in an interview, it’s simply doing it because some process says that it must be done and since there is this book, they quickly choose a couple of random questions. The problem is, the person with the fancy title won't read the bad code that a person with great algorithmic skills, but no empathy for working on a 1mio lines of code codebase writes.
Just to make sure this is not the case, I usually also prepare a couple of questions and I usually also ask something. Nothing big, I say things like “Ok, what if we have multithreading here and we have, let’s say, 10 threads doing this? I’m sure you as [fancy title] deal with this on a daily basis! Have you seen this problem? Would you mind talking about this for a minute and tell me what you’d do?”.
Of course, I’m not stupid and I don’t try to generate conflict in an interview. I only do this if I have a feeling that the interview really has no clear goals. And of course, if I’m proven wrong, then even better!
8. Look at the code!
This, to me, is the most important part of a developer interview process! Yet so many companies and candidates forget about this – I also did early in my career.
Today, one of my rules is that I don’t sing a contract until I don’t see the code – or at least some code that my future team wrote. Simply because I think if you work in an organization that deals with software, then the software must be a central point of the interview process. Not some non-real-world question from a book, or a discussion about how to clean all the windows in Seattle (*they usually substitute Seattle with their local city), or whether I use tabs or spaces – all those can be important, but not as important as the real product itself.
To me, the most important question is: can I understand the code that the team wrote before I join, and, is there a potential for accomplishing some significant contribution in the future?!
Also, I want to identify things that I can improve, or at least things where I can help. First, I try to understand the architecture and for that, I ask questions. I never blame people, and I usually literally say “I’m not here to blame, I’m just trying to figure out where can I help” multiple times. So, if the interviewer can’t explain the architecture then it’s fine, I simply move on and try implementing something – only a very small change or a tiny feature – and for that, I again ask questions.
One thing I like doing – and this is probably a little bit mean – is that I simply plain-text-search for the word “todo” in the codebase. This is definitely a point where I loudly repeat that “I’m not here to blame…” – especially if I have 100s of hits in a ~5000 lines project that was already shipped to production (yup, that happens!).
I usually also ask questions like: “Here is this constant, what’d happen if I changed it? Well, you know what, let’s change it and commit it with your user! What’ll happen? Do we automatically deploy into production? Will I see a failing test? Do you get an e-mail? When do you get response? In 1 minute? 1 hour? 1 day? Really 1 day? Don’t you think we should work on CI/CD first, instead of adding .NET support? – btw. I’m happy to help with that!”. Again, here the point is to figure out the dynamics within the team and to see how the team works. I’m clearly unhappy if there is no CI/CD, but instead of blaming, I simply offer help and see if they are willing to take that.
Doing these kinds of things on a codebase gives you a very good impression about the overall quality and about how people in the company work.
Also, if you are interviewed by senior engineers, architects, some kind of leads for a normal engineering role and you see that their code is full of TODOs, no one can explain you the architecture, and they don’t even have a proper CI/CD system, then they clearly have a title inflation. If you think you can really establish much better software engineering practices, then in such a situation, you can communicate clearly how you’d help them and what organizational changes that’d require.
Of course, it can also be the other way around! Maybe you learn a bunch of new things, you see a super cool CI/CD system combined with containerization, which tests your code in countless environments. In those cases, the answer to my question “What if I change this constant and commit?” is usually something like this: “In less than 1 minute I get an email and that commit can never end up in master, feel free to test it!” – that’s a good sign and no “Cracking the Coding Interview” question can give that feeling!
Now, probably most of you think: this sounds nice, but doing this is very hard and timeconsuming! Well, yes! Guess what, interviewing is very hard and timeconsuming! The question is, do you spend time faking stuff or do you want to talk about real things? Also hiring someone after a “fake” interview, and then figuring out after, let’s say, 5 months that this person can’t really add value is significantly more timeconsuming.
Also, there are open source companies or companies that opensource at least some part of their code. This means you have full access to the codebase before the interview. Sometimes issue tracking, including interaction between team members, is also in the open! From the candidate’s point of view, these companies are like wonderland! Of course, they already realized this and it’s not uncommon that open source companies hire contributors. In that case, the interview process is usually exactly like what I described above – the difference is, it doesn’t start as an interview.
9. Get to know the team, not the [fancy title] manager you’ll never work with!
This point again goes back to the fact that we spend more time within the company than with our family.
Very often interviews are carried out by some manager you’ll never work with. Plus, there is the Google-style of hiring, where you don’t even know in which team you’ll end up.
However, there are companies where the whole team interviews the candidate and the candidate also interviews the whole team.
I think the clear consequence of the first approach is that you will still have no idea about the dynamics within your team when you sign your contract. Also, you cannot assess your level within the team if you don’t talk to the team, and believe me, the high-ranked manager can’t do that, either, because this person never works with the team – definitely not on a daily basis, spending hours with them every day as you’ll do.
Maybe the team member who will sit next to you is a terrible person, or isn’t a terrible person, but this is someone who you’d never work with – people can be incompatible! It’s very bad to find this out on your first day.
The other problem is bias: if the decision is in the hand of a couple of people then the team setup will reflect their biases. – Just a personal note: you, dear reader, were with I'd say 90% probability selected by a white dude. Most of your co-workers are also white dudes. You get the point.
Think about this: if you are within a team, you look for someone that can help you solve the team’s problems, write code you can easily understand, and can also understand your code easily. You don’t care about all those “Cracking the Coding Interview” questions, because you look for someone that can build a product with you. Also, if people with less experience have a vote, than they will naturally look for people that can teach and mentor them.
The high-ranked manager cares about very different things. If the code of the candidate is not readable, then their daily life is not affected – it’s very different, if every team member votes!
Now what does this mean for you, as a candidate? This means that if you see an interviewer then try to figure out if you’ll really work with this person or not. If the answer is no all the time during the interview process for every interviewer, then try to ask them to introduce you to your future colleagues before you sign your contract.
I think you already figured out my opinion: I have a clear preference for an interview style where the candidate meets the whole team and everyone has the same vote, no matter what title they have. Why? Because the decision directly affects the lives of people making the decision! – If you see “flat hierarchy” in the job advertisment and they don’t do this, then that catchy phrase is an obvious bullshit.
10. Make jokes
Besides technical fit it’s very important to figure out if there is a cultural fit between you and the company. To figure this out, I usually make some jokes in the interviews and carefully observe the reaction.
It’s very common that the recruiting department advertises the company with things like “we like to have fun while we work” – well, almost everyone wants that, but very few people have it!
You can spot people who don’t have fun by not being able to handle jokes while they are working.
One of the best experience in my recent rounds was when I told a potential future boss that they “can have very high expectations if they hire me, but definitely not on Monday mornings”. This is not my best joke, but in a dead-serious interview, this is really unexpected – the result was that we had to make a short break, because they laughed so hard, they were unable to speak.
This, to me, meant that people in that company really can have fun – and obviously they also noted that I’m not a morning person.
So, my suggestion: try to create “unusual” situations during the interview to figure out the real personalities of your future bosses and colleagues. This is useful information, plus very few people do this. If the “we have fun” propaganda is true, then you prove them you really like having fun. Of course, I assume here that you really do like having fun.
11. Ask unpleasant questions
Besides having fun, I also try to make sure that my interviewers can take criticism. This goes back to the catchy words like “flat hierarchy, openness, equality, transparency, blah, blah, blah”.
Before one of my interviews I went to glassdoor.com and noticed the company had very bad reviews. This was clearly a bad sign, but I always try to make sure that I don’t judge too early, so I decided to use those reviews as my “unpleasant question”. I told them I have seen lots of bad reviews and I would be super happy to help make sure that people don’t feel so bad within the company. Then I started quoteing a review and saw that the face of the [fancy title] interviewer started turning red.
The reaction was that “all those reviews are stupid” and I “should ignore them”. Based on my values, this is clearly the worst way a management can deal with criticism. Furthermore, you should also keep in mind that if you got hired, then probably you will also bring up a couple of things if you truly want to achieve something – and probably the reaction will be the same: it’s “stupid” and everyone should “ignore it”.
Btw, glassdor.com reviews aren’t the only way to do this. Big companies usually had some scandals in the past, it’s also good to bring those up.
Another problem that almost every company has, is the so called “white dudes only management, except the head of HR”-problem. If you think this is not ok, then simply bring it up!
These are all things where there is no good or bad answer, the important thing is the reaction itself. Are they open to discuss it? Sometimes they are aware of the problems, and they even try to work on them. Saying “It’s stupid; ignore it!” is very different from saying: “Yes, this clearly is a problem, and we would like to solve it! Would you help us? We have a task force working on it, would you join if you got hired?”.
12. Salary
Salaries is a huge topic on its own and there are other people who know more about salary negotiations than I do.
Here is what I usually do: by doing some research, you usually know what developers earn in your area. During the interview process you can also identify where you can help the company and where you would fit based on your knowledge and experience.
If you think you can really fill a gap, then you are probably worth more money to them.
I always make sure that I don’t price myself out of the market, so I always tell a realistic number. Just to be clear: unless you are in Silicon Valley, or you do some quantitative finance development at a hedge fund in Singapore, you won’t have a 300K USD base salary as a developer.
However, if the reaction to the realistic number is that they automatically start negotiating down with some fake arguments, then I simply say: “Thank you, but I’m afraid we won’t reach an agreement here” – and I end the discussion, because I don’t want to work there. My idea behind this approach is that today we have a market where almost every company has to fight for good talent. If I stay within the current market rate, and they are still not willing to pay that amount, then they won’t raise my salary after 1-2-3-4 or 10 years later either, plus, my collogues probably also earn below average and that’s not a good sign.
For the sake of completeness: a non-fake reason for offering less than you asked for would be if they’d give you the compensation list and they say: “well your interviewer is on level X, we think you are a little bit below that, and the top salary we give on that level is 5% less than what you ask for”. Do companies do this? 99% of them don’t. But there are some real pioneers: for example, StackOverflow has an open compensation scheme, and Buffer also publishes its salaries. Now that is what I call transparency!
13. Job titles
I see a huge chaos in the industry when it comes to job titles, with a little bit of title inflation on top of that. Therefore, I usually ignore titles at the beginning, and I simply ask the interviewer to define what they mean by a specific title. This seems silly, but so many times I see sales and marketing people running as "engineers" and people doing administrative things as "managers". There is nothing wrong with this, as long as everyone speaks the same language. So, make sure you speak their language!
A typical example for this is the title "architect". I had my first internship when I was 15, and after 14 years in the software industry I still don't really know what an architect does. At the beginning I thought that they deliver architectural design and documentation but let me tell you: in 14 years I have never got anything architecture related from an architect, so I'm probably wrong. If you ask me "what an architect does?" I'd say it simply depends on what the definition of an architect is in a given company. Btw, I know that there are different kinds of architects, but to me those specific "architect" titles don’t mean too much either.
So, the bottom line is: title doesn't matter and doesn’t guarantee anything; you can be called "code monkey" and still do awesome things! Your job during the interview phase is to figure out what the meaning of certain titles at the given company is – with that you can avoid huge disappointment later.
Another thing I noticed recently is that some people go by multiple title. Usually when they talk to customers, they are something with "senior", or "lead", or something catchy, but internally they have a totally different title.
I suspect that those people are paid by their "lower" title, and I find this a very annoying practice in general. If you see this at the company that you interview with you'd better clarify this upfront.
14. Seniority
My goal in an interview process is to identify people who are somewhat above my level (aka I can learn from), but also to find people who are somewhat below my level (aka I can teach) when it comes to technical abilities – btw. this is not black and white! Sometimes you learn from someone and in the next minute you teach something to the same person, so don’t be too focused on that, the point is: figure out where you’d fit compared to your interviewers.
I don't really care about the title "senior", but it's important to me if the company has a hierarchy, then I end up on a realistic level.
Btw, being senior also means different things at different companies. Some companies call almost everyone senior and some other companies don't even have "senior" titles.
To me, the easiest way to find a common vocabulary is this: try to figure out what is the average developer salary in your region. If they offer a salary below that, then you deal with a junior position, if they offer something that is near the average, then it's a regular developer job, and if they offer significantly more than the average, then it's a senior position.
Of course, they can call you a "senior engineer" with a below-average salary, but in that case, you should know that they have title inflation and considering the market you aren't really senior and it will be hard to find a "senior" job at another company – unless you are really senior, but in that case: leave NOW!
Similarly, being a "junior engineer" with an above average salary means that they have very high standards, and you can have a higher title at another company with high probability. Is this bad? I don’t know, not necessarily. If you are happy, and your position in the organization is realistic then I don’t think this is tragic. To me, title doesn’t matter, the question is: does it matter to you?
Now one exception where my theory breaks, is early stage startups: they probably won't be able to pay above average developer salaries, even if you are clearly "senior". And by the way asking for an above average salary at a startup isn't a good idea, either, since those usually don't have the cash flow to pay it and it’d put the finances of the company at risk. So, my theory doesn't apply for startups. Btw, if you feel you are "senior", then in case of a startup you can ask for equities. In Europe, we have terrible moral when it comes to equities in startups (aka: none of them wants to give equity), but I see some positive signs, and if you are good, they have to compensate you somehow – so shoot for more equity!
Another thing to be aware of is that consulting companies usually have a staff where basically everyone is senior. It's not uncommon that services done by senior people are sold on a higher rate than services by non-senior people, and the consequence is that – guess what! - everyone is hired as senior.
I personally would not play this game, so if I don’t feel that I'm good enough for the title, I then wouldn't go to a customer and bill the higher rate – this is just plain wrong. But again, this is just my opinion. The point is: be aware of this and prepare upfront.
15. Have money!
The goal of all my points above is definitely not to find a company as fast as possible. They are all about finding the right company. In fact, by being consequent in all those points, you will probably drop out from multiple hiring processes.
If you live paycheck to paycheck, you cannot afford to look for a job with the proposed approach, simply because your goal will automatically be to find a job, no matter what – and not finding the right job.
“Having money” again is a topic that can easily fill a whole book. What I want to say is that it definitely makes sense to “invest in your freedom”, and by this I simply mean that you should always have enough money so that you can survive without a job for a certain period of time. The length of this time-period is up to you. Some people feel safe if they have enough money for 3 months without a job, others shoot for a sum that covers 10 years without any income. There is no universal answer, the point is: make sure you never accept a job or a job interview process just because you need money.