I'm also sure to fail googlable technical questions so I was wondering how others might approach this.
Don’t try to join startups or cool SV companies unless you have an inside track. Their recruiting and hiring practices are mostly geared to ensure “culture fit.” That’s code for young single male who will work 12 hrs/day and think free beer and pizza makes it cool.
Focus on measurable accomplishments rather than languages, frameworks, tech buzzwords.
Learn to solve business problems rather than “engineering problems.” No one needs 2,000 more lines of Javascript. Lots of companies need business problems addressed.
If you’re applying for jobs you’re hobbling yourself. If you have years or decades of experience you should have a large network of colleagues to get leads and jobs from.
See, there's a couple of things to remember. First, the biggest way to sell yourself in an interview is to demonstrate confidence. Not bluster, but gentle self-assured comfort in the face of being interviewed. The ability to answer questions you do know, and to say "I don't know. But I think I'd...." or similar in the face of things you don't. Even if that's to say "I'd have to Google that".
Second, the actual interview...yeah, you might get turned down at a FAANG. But I've had plenty of interviews that were far less algorithmic. Far more concerned with whether i could speak intelligently about things I'd done previously. Even coding; I've had the algorithmic questions...I've also had really simple toy functions that were there just to make sure I could write some code, and formed all of 10-20 minutes of the hour long interview.
The way to get better for both of those is practice. Literal sitting in an interview practice. The more you interview the less you care about any given one, and the more likely you'll stay calm and collected. That exudes confidence, makes you more likeable, and lets you put your best foot forward when it comes to any coding problems.
1) Don't over-filter. Take the time to manually skim each job posting on high-quality job lists, like the HN who's hiring. As a generalist I tend to be a good fit for smaller teams that have diverse problems and individuals I can connect with. Those individuals usually make more open ended job postings that don't sift well through most filters. Additionally, you'll get a better sense of where the job market as a whole is at.
2) Make extra effort in your initial outreach to a few positions. Surprisingly "cover letters" are still effective if they're presented in the right way and through the right channels. A form cover letter may be ignored, but a freshly written pitch for a particular job listing can stand out.
3) Don't copy-paste until you have your pitch figured out. If you're like me you'll find yourself rephrasing it slightly each time you write an initial outreach, and eventually you'll find the common elements that make their way into each. Try to make your pitch shorter each time while keeping those commonalities. A shorter pitch is more likely to be read.
The more areas of expertise you have mid/Sr.-level skills in the smaller the company you should try to work at.
For example someone who can code frontend, backend and run DevOps is invaluable to an early stage company as it means hiring 1 person instead of 3 (which they probably don't have the workload or budget to hire anyway).
At larger companies, your other skills won't net you much because they have 40hrs/week of frontend work they want you to focus on and continue to get better at.
The short answer is - I don't.
I accept that I have varied experience in many technologies, which makes me less attractive than the single stack experts. I hate my job, but I don't really have any options to leave since my true expertise was built in FileNet and Neoxam. I'm also quite limited since my wife refuses to relocate.
Disclaimer: my skillset includes a lot of non-software engineering, and I work for a company that does a lot more than software.
1) I'm a generalist and go wide but only surface deep.
2) I'm a specialist in multiple areas, I go deep and because I know how to do that I have done it multiple times and can also do it for whatever your problem domain is.
The first of these feels more like your full-stack web developer and the lack of depth usually deter me from hiring... the latter though, the latter feels like an interdisciplinary master that I would want to hire so long as I can see that the candidate is able to apply that to solve our business needs within a month or two of ramp-up.
I haven't seen your CV but I'd make sure that #2 was obvious at the top of the CV as that would provide context to the roles on the CV, each one enriching who you are.
The jack of all trades are making 7 figures building “DeFi” infrastructure
You just deploy a smart contract that helps people simplify a more complex task and your code takes a few percentage points
No overhead costs, incorporation, lawyers, banks etc necessary
Never been easier to make money
Basically the key concept that appeared this year is called “composability” where the outputs of one operation can be used as inputs of the next operation, so this is analogous to the interchangeable parts era of the industrial revolution
Smart contracts are extremely limited in the kinds of operations they can do, with most data structures algorithms being too expensive so you never have to employ the bullshit technical questions or any academic knowledge
But you probably should read a book like O’Reilly’s “Mastering Ethereum”. Ethereum introduces a concept called an “EVM” (like JVM) which is used on several more platforms that arent called Ethereum, so you should be familiar with that.
Oh! You also dont need to be distracted by:
“Consensus model ideology”
“I could use a database for this”
or any other self limiting thing.
because “you could also make money”
Lets be honest you were probably going to work for some ad tech startup anyway, all crypto projects have just as little utility for the world while possibly having the argument for much more utility, and you dont have to pretend like you are an investor that wont get zeroed out by VC liquidity preferences
2. Sharpen your skills in detail areas of specialization before interviews
3. Make a list of the coolest things you’ve done
4. Practice stories related to those things that you can bring up in response to various questions
5. Select different items from that list to highlight for different positions
6. Build an additional portfolio of work to support your capabilities to succeed in the positions you’re applying for
If you're having trouble getting responses, I help people (hate advertising on here but I do this for fun for free) by providing connections to hiring managers (https://foxrain.ai)
where compensation >= sufficient order by entertainment_value desc
The whole point of a generalist is to be that jack of all trades that management can just throw into any "high priority" project to get it shipped. These corporations are so big now that they've mostly wrapped all the existing tools or have developed their own, so the only skill you need is to learn a bunch of custom tools (with little documentation) sufficiently fast to be productive. So just learn the basic algorithms to pass the interview and then proceed to (probably) never use that knowledge at your FAANG job.
If you're on the older side, don't think about it. I personally know someone who's 65 working at a FAANG (anecdata but still). If you interview with a kid, they might ding you for "culture fit" because they're kids, but hopefully the hiring manager and the bar raisers are mature enough to see past that.
Your biggest hurdle will be the internal interviewer discussion that based on your experience you should be at level X, and, if in your interview you didn't show that level, that you might be unhappy at X - 1 or X - 2.
Tomorrow, I'll apply for other similar roles and I'll interview again and again until something sticks.
Now I'm in a job where I'm simply judged as a developer. I've noticed that even when I find vulnerabilities and show them to the dev team at the startup I work, they don't care. When it's a critical, they care a little. They actively dislike that I try to do more than just programming, since it isn't of my concern. And yet, this is the most graceful company that I've been at since they hired me, out of the 100 I applied to.
So yea, I'm floundering. I want to help out with marketing and recruiting. I want to help out with some data science. And I definitely want to hack the company I work at in order to harden your product against hackers. I know my main role is being a dev, but I hate being only seen as a dev.
If any company hires people based in Amsterdam and would like such a generalist dev, I'm for hire. I also speak English ;-)
I formally switched to product management in my last job. I have background doing startups, and this combined with jack-of-all-trades engineering, makes for a perfect technical product manager.
Every giant company is looking for specialization. If you like having your hands in everything and it’s where you add the most value, look for smaller companies where it’s possible.
Though I have done everything from kernel work to web development in my career I often end up working on or helping with the build and release engineering aspects. I will also frequently end up being the person who works on the product cybersecurity and security model.
It certainly isn't the most "fun" work but it is necessary and usually gives you a deep understanding of how the system works. This is especially true for older products.
Part of the problem you are facing is the assumption that by hiring smart people they are hiring people who can do anything, the people are interchangeable, fungible. Even if the "smart" part is true the willingness to work outside of their preference areas is not universal. Developers are often entitled, spoiled and fussy. And why not, with the variety of work opportunities and amount of choice available they can generally afford to be picky.
So it is not enough to say that you are a jack-of-all-trades, but that you are happier being that way and are explicitly willing to take on tasks/roles that may otherwise be hard to fill. This doesn't mean that they can assume that they will only give you the shit-jobs; it is still negotiated. If they want to you work on, for example, QA tooling and you REALLY hate that make sure to negotiate that the work is not open ended and for a specific project or time window. You are solving a problem for them, usually temporarily, and they still need to come up with a long term answer. Don't get yourself stuck in a rut of one particular assignment, it is too easy to wind up being stuck in that role for the rest of your time in the organization.
You can use staff turnover, particularly management turnover to your advantage. Every staff change creates a new configuration. Use these occasions to adjust your role and volunteer for opportunities which interest you.
That website also states that I'm open to offering reduced rates and/or becoming an employee. So far, all of my jobs started out as me being hired as a freelancer and the company later approaching me to re-negotiate to become an employee.
I've had only one regular job interview, but it didn't go well because they were not willing to guarantee me a room with a window and space to bring my collection of potted plants. My opinion is that the problem there was that we negotiated the employment contract too soon, before they knew why they should value my work.
Also, learn related topics. I've done documentation writing for patents and bookkeeping, which greatly helps when you're hired to solve an actual business problem.
Hiring managers are often faced with the same dilemma: "my job requires a little of this and a dash of that and a bunch of this other stuff. And I don't want a bunch of bums to apply, but I don't need rocket surgeons either." and we take a random stab at a job description and desired qualifications and post it.
Find a job that looks interesting, tailor your resume a bit to fit, and see what happens. If you get a call, strike up a conversation about your experience solving disparate problems and your interest. Hiring managers (usually) care more about that stuff than any specific skill set, even if the job description might imply otherwise.
I would do the minimal amount of studying that's required to pass this hurdle, and then you'll probably be great at acing the rest of the interview.
Pretty much no matter how good you are, you're going to have to pass some classic interview problems, so it's worth the hoop jumping investment. Leetcode is a good place to start on algo problems
Also would recommend refining your pitch / resume to 2-3 large technical problems you've worked on and the outcomes of those. Something a hiring manager reads and thinks "okay they know what they're doing". "Jack of all trades" is sufficiently vague for them to be like "i have no idea what this person works on"
I miss some programming, but do it privately on the side or sometimes for some odd-jobs at work when it's easier than asking someone to do it.
I will probably keep on switching industries when changing jobs (which I don't do too often though).
- phd in biochemistry, can do molecular biology, synthetic organic chemistry, etc.
- wrote a test framework for debugging the machine code for a chip that hadn't been built yet (it taped out shortly thereafter with bugfixes for a ton of critical bugs I discovered)
- designed research alternatives to IEEE floating point, cited by FB AI, live-demoed at a lecture at stanford
- wrote from-scratch orchestration software for linux containers (didn't hit prod) and virtual machines (went into production)
- assembled physical hardware to go into a rack that is a staging environment for the vm orchestration system
- network admin (switches, etc) for the above system
- wrote a layer-7 TLS-terminating reverse proxy server for jupyter notebooks
- several small-time web-ish things for myself, in various languages over the years, none publically hosted (so, yes I know the principles and basic howtos of a rest-ful server, and wrangle react, but I'll be slow at it at first).
Most recent experience (past 2 months):
I can't pass a standard FAANG interview for shit. I couldn't give a damn about finding mindepth for a binary tree. It made me angrier that they conducted the interview over coderpad and had disabled execution. I wasted precious time commenting-out the instructions that the interviewer pasted into the coderpad. (I'd given interviews in coderpad before, and the interviewer asked me if I'd used it before, so I assumed I knew what I could do).
In the past, all of my jobs I've gotten "because I knew someone"; this was the first time I applied to jobs via "normal employment track" and I'll admit I was a bit jaded about the process.
My strategy was to focus on companies that were hiring for the language that I was the strongest at. Relatively niche, so over the last couple of months I only really saw about 10-12 realistic opportunities go by. One strength is that I have a ton of open source libraries that I've written over the years and I made sure to pin these to the top on github. I also took care to make sure that the documentation is above average on all of these libraries (and the readmes all link to them). I figured I have some runway to apply to "other stack" jobs later. Might as well optimize for developer comfort.
Actually only got three interviews. A lot of the "bigger names you have heard of" that use this stack passed on me immediately, probably because I don't have any publicly visible webdev chops. First one kind of wiffed on me by trying to make me a contract tryout (and the team felt super strange, too). Second one, which was a fantastic interview, I failed the tech exam (debug this miscoded UX experience) because I had forgotten how one of the macros that I don't use in the web framework works, forgot to check the network pane in the web console (I don't do a ton of frontend so it's tool I reach for relatively late), and didn't notice that the central problem was a misnamed variable, even though I intuited (and verbalized) that this was likely the problem early on. Third interview didn't have a tech component at all. I guess they can see my output and they trust it? Anyways, got an offer after some short chats, it's in a vertical that I find very appealing, so I'll probably be starting there soon.
Pipeline ~12 -> 3 -> 1. Not bad. Definitely stress-free.
Specific advice:
If you think you will fail standard tech questions, focus on startups, I think they're bimodal in their attitude towards FAANG-style interviews, some cargo cult it like they're gonna try to scale to a billion users in the next year, and some avoid it like plague).
I would say, try to find a niche-but-provably-valuable (obvi don't shoot for "I can program in zig" companies) skills, especially if you would enjoy working in it - and try to find a company that matches this. Your life will be easier, you'll probably have a greater chance of avoiding the FAANG questions. Make sure your resume/github highlights real work done in this niche.
Finally, maybe a positive is that in an early screen, the CEO asked me, "do you know anything about X domain". I kind of demurred and said "not really" and then explained that I thought it meant " Disclaimer: probably a lot of this is stochastic, 12 is squarely still in the "statistics of small numbers" range, your experience and tech stack may not necessarily make this possible. For example if you're a java wizard, I suspect you might have a harder time pulling this off, just statistically due to cultural buy-in to the enterprise mindset.... It might be time to break out the cracking the coding interview in that case. Good luck!
I call it "Devops" and apply there. It's one (misnamed, but whatever) position that appreciates front- and backend development experience, and system administration experience.
I had a very challenging time getting a job offer the last time I did the interview gauntlet run (had 17 years experience at the time), because I kept talking about how many different skills I could bring to the table. I should have focused on listening to what they want.
Once you are inside the company, you can employ your jack-of-all-trades skills.
I’m pretty young and not an engineer but I’ve found that by being interested in a lot of things and seeking out people / companies rather than specific roles I’m always in high enough demand.
When I see or meet someone interesting I make time to talk with them about it. When I see a role online I reach out to someone in that role. I often write “cover letters” that are actually focused on what’s cool / challenging about the situation a company could be facing.
I think knowing people and being known is the best option.
My background is game dev. The typical “Jack of all trades” webdev has minimal overlap with game dev skills. Unless it’s working on the backend of a mobile game, in which case the overlap is enormous. The skill sets of a “Jack of all trades” AAA console dev and “Jack of all trades” webdev are extremely different.
Point is you do have speciality skills. Identify them, embrace them, and don’t sell yourself short.
Sometimes people pay for help with their resume, cover letter, whatever. Sometimes that's useful.
To be frank though, I consider still working with my own hands after XX years of experience to be a big, big failure.
If you're contracting though, you really want to sell what business problems you can solve rather than focusing on tech.
I have a good professional network but it's mostly local (Argentina). I've been planning to live here all my life but it's not a good place to live anymore. I'm planning to relocate to Europe so I had to start with the interview process again and being a "generalist problem solver with software" is getting difficult to get good job offers.
- I only talk to founders either through references or linked in - but before that I start publishing blogs and ideas so they get sense of my skillset. This includes points like how I learned a new skill on the go, how I converted an opportunity into feature that made impact, etc
Blogs have always got me good leads from 2nd degree network.
Stick to this simple routine. Good luck.
You can automate your resume-specialization by building a template in HTML, store role details in a DB (a JSON file would do), and generate unique PDFs with `weasyprint`. Something like `11ty` or `jekyll` makes this fairly doable.
Focus on your network and asking people if they know anyone who is hiring. Don't put people on the spot and ask if they are hiring, but ask if they know anyone.
When I last job hunted, I created three resumes--software engineer, devrel, devops engineer. The same jobs were on each resume, but different duties and accomplishments were highlighted.
I would also pick up some contract work if you can--the barrier is a lot lower and can often lead to a FTE conversation. If you are in the USA, use the ACA health exchange for health ins (not sure about other countries).
The Google type of questions is a pain, Companies are beginning to realize that.
yes, but more often than not, those colleagues best interest is not YOU but their employee referral :) .
At least in my experience, they often try to oversell the company they work at, as the best place to work, trying to get you to join, even if they know it is crap.
I do my own research and always take "ex-colleagues" advises with a grain of salt, basically I mainly trust my judgement, balance sheets for public companies and buzz around like glassdoor, blind, etc .. :)
1. I start by reaching out to people I know - bosses or teammates I've enjoyed working with, recruiters that have proved trustworthy and so on. People who now me and who have worked with me before know the value I bring, even though I don't really excel in any one area. (Early on in my career, this wasn't literally "people I know," this would be more connections through my school.)
2. Since a lot of interview technical questions skew towards Stuff We Learn in University, I usually skim over my college and grad school text books. That way, if someone throws something at me that I haven't really dealt with in 12 years, I can at least have enough freshness in my mind that I can problem solve through it.
3. I practice problems from a "programming challenges" book like the one by Skiena. I do some of these at a computer. However, since many companies do coding challenges on a whiteboard and these are timed, I try to recreate this by doing some coding problems with pencil and paper while timing myself. Whether or not it is a good idea for companies to do coding problems on a whiteboard is an interesting question, but in the course of a job search, but this is the world we live in. Writing programs while timed is particularly stressful, but by practicing beforehand I find I'm able to adapt to the stress better.
4. A lot of the value we provide (both as experienced engineers and as jack-of-all-trades) is best demonstrated through historical examples, and many companies ask about historical examples. So I make sure that I've gone through the important projects I've worked on in my career, and can talk about the situation I was in for the project, what I did, and what the result of the project was.
5. It's hard to know who looks at what in an application submission, but for any company I apply to I write a cover letter explaining why my unique set of skills makes me a good fit for the particular role I'm applying for. As a hiring manager, I saw people clearly copy and paste other cover letters (e.g., I was in advertising and I'd get cover letters ending "... and that's why I want to work in finance"). As an applicant, I write each of these from scratch, going through each item in the job description and saying something very brief about how that's a thing I've done before. (Earlier in my career, I would use examples from undergrad and grad school.) I've generally had pretty good response rates with this strategy.
6. Across all steps, I work in as much as I comfortably can that as a jack of all trades the value I provide is not that I can implement solutions in the area I'm hired for soon after being hired (although, I can), it's that I can handle the uncertainty that comes in many environments, and I can talk about examples where I've done this in the past. Some companies appreciate the value this brings, but some do not. The ones that don't will probably under value you.
I hope it helps!
I have been a professional job seeker for 11 years since I have left college. I guess I would call myself a front-end developer though I have never had a front-end job. I am able to find work here and there as a freelancer and I have worked one tech job in QA in my 20s. I am now in my 30s. I make the majority of my money flipping stuff and working in service industry jobs and occasionally find work as a designer, developer, photographer, videographer, video editor, and much more....I know how to do a lot of things, but finding a job isn't one of them.
This has developed a lack of trust in humanity for me and a great mental illness. I have and probably won't ever trust an individual again when one grows up trying their hardest to develop skills when skills don't matter.
So I would suggest you make it clear you want to work within a company's existing framework and not turn it into your personal technical debt playground.
Similar to waiting tables at a restaurant, 99% of people don't want a list of the ingredients, nor do they want the waiter to say "I like everything on the menu because im a food generalist". Customers want to hear "The burger is great because its cheesy and juicy".
The scope of how you are selling, whether its skills or physical objects, is very important. Calling yourself a generalist is just setting yourself up for failure for a job search. Sell yourself to the role, don't cast a "generalist" net and get upset when nobody thinks you are a correct fit for a role.