Hacker News new | ask | show | jobs
by Inception 2072 days ago
I've been seeing this sentiment a lot on LinkedIn, particularly with new developers entering the field. Leaving aside the whole argument about whether or not we should really be calling software developers engineers, a lot of these same people are advertising themselves as full-stack. I'm sorry, but you going through a 10-week bootcamp or even getting a 4 year CS degree does not make you full-stack.

It's comparable to how we laugh at recruiters when they ask for 5 years in a given language that has only been around for 2 years. You clearly don't know what you're talking about.

I always tell the folks I mentor through bootcamps they should figure out which area they like best, focus most of their efforts in that area, and then advertise themselves as a front-end developer or back-end developer or whatever, not full-stack. The upside down T approach. Show recruiters and hiring managers you at least know enough to know what you don't know.

And stop complaining on LinkedIn about how unfair it is that you don't have a million job opportunities pouring in or about all the applications you submitted and didn't hear back from - yes it's annoying, but if you advertise yourself as something you're not, you've likely already wasted someone else's time, so understand they probably don't want to waste anymore giving you an explanation for why you were passed over.

5 comments

>I've been seeing this sentiment a lot on LinkedIn, particularly with new developers entering the field.

It honestly just amounts to "The most well compensating jobs with the most competition to attain them have a difficult application process, and that is unfair (to me) because of X, Y or Z". These posts are positively dripping in grandiose levels of entitlement.

If you can write a web page that submits a user form and a server that writes that data to a persistent database ... I'm failing to see which part of the "stack" is unfilled. This is what bootcamps teach.
Yes, bootcamps teach you the basics of each part of the stack. I would make the argument that you aren't proficient in any of these areas, so to advertise yourself as such is misleading. I file my own taxes, but I don't refer to myself as an accountant.

I've yet to meet a bootcamp grad that can efficiently architect a relational database, for example. I know plenty of Sr. level front-end developers who wouldn't think to call themselves full-stack even though they know how to submit a user form that persists to the database. Same with back-end developers who know HTML, CSS, and pick your flavor of JS framework.

If you've worked in the industry, you know things change too fast to stay up to speed on everything. It's not impossible, but it's unlikely and unrealistic to have that expectation of someone once they are employed.

Being full-stack does not mean you are a HTML and CSS expert. Anyone hiring a full-stack dev should know that. Full-stack means you can create a functional web application. It doesn't have to be in the latest JS library.

Many non-tech employers careless about your stack, as long as the application performs the tasks they want and the cost is reasonable.

A full stack dev most likely won't be an expert in any particular area but should have a good understanding of the web so they can pick up different JS libraries, web frameworks easily.

Just call yourself a web developer then. Does someone outside of the tech world really know what full-stack means without an explanation?

And also, I don't consider full-stack exclusive to the web. Desktop apps, for example.

"full stack" is a pretentious term web devs made up for themselves.
You're missing the edge, which is very very broad.

Suppose your employer wants your web app to interface with an industrial PLC, or fetch data from a car's CAN bus, or talk to a vending machine (ironically the sort of machine that Java was originally designed for).

Most bootcamps don't teach enough fundamentals for someone to figure out how to write both client- and server-side code for those sorts of situations.

Or on the other end of the spectrum, could you write hypervisor code to manage the sort of mass-scale VM deployments behind most cloud providers? It would be very difficult to be an expert on the "full stack", if you think about it.

So...tl;dr, most of the application layer? Probably the physical layer too, any how many of us really work with the link layer?

Yup. People don't realize how many applicants literally can't even pass FizzBuzz, or some slightly more complicated variant. It is not just a meme. Dunning–Kruger.
I see this a lot on forums, blogs, Reddit, etc. but after having interviewed many candidates, I have yet to see someone that incompetent.

My company is not a hot Silicon Valley tech company either. It's a dull, boring, investment bank. I am generally not impressed at the quality level of most of the candidates we get when we hire. But still 100% of them are able to code more than well enough to pass FizzBuzz.

Now throw anything beyond the easiest of leetcode easy level questions at them and the majority will struggle. But that is still a level above Fizzbuzz and the like. And most come from backgrounds where the last job they were hired for did not leetcode them, but rather relied on language/framework trivia type interviews.

I have, personally, interviewed a senior software engineer candidate, claiming 8+ year of experience coding, who could not write a simple 5-minute exercise, in any language of his choosing. It wasn't FizzBuzz exactly, but if I'd thought to ask FizzBuzz, he'd have busted that as well.

"Write a function that takes a set of numbers [array, list, or equivalent] and returns the average."

Couldn't even get started.

I was the third interviewer. He'd BSed his way past the phone screen and two others and I caught a whiff of "Johnny can't code" and decided to check by asking him one of our new college grad questions.

There have been many more who bombed terribly in a manner that leaves me doubting whether they could solve FizzBuzz given an hour.

I don't doubt your beliefs, but I am surprised that you've not found any candidates who cannot possibly code at all. That probably speaks well to whatever upstream filtering process your firm is using (it would be ironic if it was "coding FizzBuzz using this online coding platform").

My priors for “is nervous in interviews and gets flustered” are significantly higher than for “can’t code fizbuzz and somehow kept their previous jobs”.

This meme has been going around for ages (at least since Spolsky wrote about it) but I really doubt it is as common as people think.

I think it’s still rational to pass on someone who got stage fright, since in that case you have no signal on which to make an assessment. But I think the “can’t code” rationalization does candidates a disservice.

Interviewing is really stressful for many candidates! I encourage interviewers to remember this and treat candidates with compassion; maybe they can tell you think they can’t code, and that makes them more flustered. Vs. a joke about how interviews are stressful that might put them more at ease.

It's quite common but how common depends a lot on where you get your candidate stream from. In my experience it's never to do with stage fright. The candidates don't seem flustered. They just cannot program. Even if it was stage fright, so what? Instant no hire. Your work will be evaluated by people post-hiring too: you have to be able to perform the job you are hired for when asked to do so. Panicking the moment you're asked to do your job is an excellent indicator you should not be in the team.

At my current firm, I hired most of the engineering team. In the early days we relied heavily on website applications and external agencies. A non-trivial number of candidates would struggle with a task like "read a text file into memory and print out the lines". Not FizzBuzz, if anything that's even easier: FizzBuzz trips up some inexperienced candidates because they don't know about the modulo operator, which is relatively rarely used. But almost any kind of program will use files.

At some point we started pulling sourcing and recruiting in-house. We also dropped some bad agencies and got a bit more savvy about which ones were cheating. The candidate stream got better at that point and total failure became less common. Unacceptably poor performance was still a frequent issue though.

Disappointingly, to me, a lot of candidates and even people we hired would try to claim that asking candidates to load a text file from disk was somehow unfair because "real programmers" don't work with files anymore, they just use web frameworks to do everything. Needless to say, that was not the kind of software engineer we were trying to hire.

Usually the candidate pipeline is:

1. External recruiter shotguns out candidates to my team manager. Having been on the other side of this process myself, any vetting the external recruiter does is pretty minimal and purely behavioral.

2. Our manager passes around resumes to the team, and we collectively review them and give a thumbs up or down based on how subjectively we are impressed by it.

3. Manager assigns the more senior members of the team to conduct phone screens. Typically we throw some of the easiest of the easiest leetcode questions, or very simple "implement this in JS" questions. I personally have failed people at this stage mostly for communication or behavioral issues.

4. On-site. Combination of easy leetcode questions and "implement this in JS" questions. I can honestly, proudly, say that my team does not look for hyperoptimal perfect leetcode solutions - we genuinely focus on the communication process more. Part of the reason for this is, as I mentioned before, most of the candidates we get would struggle at all but the easiest leetcode questions and we cannot afford to be picky. We're not a hot tech company. We're a boring investment bank.

Very, very rarely we get a candidate that has worked at a hot tech company - even a FAANG occasionally. Their candidacy gets treated like a celebrity. But so far all such candidates have been turned down by my manager's manager because "they don't have enough business (finance/trading) knowledge". Never mind that most of our current team has extremely little to no such business knowledge too. In any case I doubt we could match the level of compensation they might be wanting.

Is your workplace hiring? Sounds like a relaxed process.:)
Are you saying 100% of your applicants could write FizzBuzz at step 3 or at step 4?
Well, it is not FizzBuzz, but the challenge I ask as a "evidently bad" filter ( http://challenge.paystand.mx/challenge ) is just a couple of GET / POST requests .

You would not imagine how many people (fortunately) get filtered by this step.

I can imagine an embedded developer unable to do that, they never do HTTP requests and it's a nightmare to implement in C or C++, a web developer in python/ruby/node should do fine.

It's selecting for languages and candidates with built-in support for HTTP and json and base64. It's far from a 1h problem if the candidate has to find working libraries for each of that.

Depends on an embedded developer. It is very handy to know TCL or Python so you can script your hardware or create provisioning/testing scripts. And with the whole IOT thing, HTTP requests in C became much more common.
Deffinitely right. This is for positions in a SaaS company where the developer would be mostly doing backend or frontend code.
That looks like an excellent exercise, going to save that :)
Thank you! yeah. I designed it with a thought in mind: A lot of the "exercises" or "challenges" that I see people ask for interviews are mainly stupid leetcode type puzzles that do not really reflect what you will be doing on the job.

I wanted to do a challenge that really reflected the stuff that we are doing at Paystand. When you are building a Web based SaaS application, the majority of time you will be a) Interfacing with crappy APIs. b) Doing simple processing in your logic (hence the string processing and sorting), c) Dealing with GET and POST requests in JSON

That's all I tried to present in the challenge. And if you read it, you will see that it gives A LOT of hints. There's even people who have asked me why do I give so many "clues". But on the other side I have gotten candidates that email me to ask me why they API call is returning an error (it is there in the notes that you must use the proper HTTP header). People are lazy, people don't read, and those are not suitable candidates for us.

Totally agree on all points. I don’t think it gives too many hints at all, in fact it feels very much like a half-baked product spec that you’ll probably have to deal with on the job as well :p

Also the point isn’t to demolish the interviewee with a difficult question, it’s to get a feel for how they are to work with (and of course, if they know the basics at all)

I haven't personally, but my ex-wife is a developer at a FAANG and she told me multiple stories of people she phone screened who couldn't actually write a simple for loop.
I don't think it's specifically FAANG but the staggering renumeration they offer IME seems to mean they [disproportionately] attract the naïve. It maybe doesn't help that the perception is that tech giants have very large numbers of developer jobs involving non-complex work that pays extremely well, and that very basic "coding" skills are valuable.

Anecdata, but from five years helping beginners through a popular online curriculum, this pattern is ridiculously common:

1. Beginner learns some HTML/CSS over the course of a few weeks.

2. Start on the JS curriculum, get stuck immediately.

3. Start to ask in forum if there are jobs [at a FAANG] just involve knowing HTML/CSS.

4. Very polite and detailed replies start to appear on forum of the form "well, it doesn't hurt to try but you might want to bear in mind that at entry level you're competing against people who have years of learning behind them", or "maybe just try to work through the slightly harder bits of the curriculum first (bearing in mind that even that isn't going give you a deep knowledge of the subject on its own)".

5. Few months later the beginner reappears talking about how they've applied to x number of jobs with no responses. And they start asking about how to get jobs working freelance. Moderators take some diazepam and start putting together more polite replies.

Anecdata as I can only see a tiny slice of self-learners via the forum; I feel for your ex though

I wonder how much of this is a FAANG problem only due to how much they pay entry-level jobs, and invite people trying to, effectively, win the lottery.
People don't realize how many forum commenters literally don't know what "Dunning-Kruger" means.
Eh, I think it's fine. If you're going in at entry level, your expertise won't be that deep, but full-stack just means open to joining a team that does front-end, back-end or both. The typical bootcamp grad can develop into a specialist or generalist as they go, given support and resources.
I think saying you are full-stack is misleading and it sets job-seekers up for failure. And I would argue it's not fine, since it's these same types of people whining about what terrible luck they are having (purely anecdotal of course).

A few ideas that I think would give these grads some better luck:

- Update your profile to say "Interested in joining a front-end or back-end team" or "tech generalist with a focus on X"

- Elaborate even further in your About section and let people know which of the two you are stronger in and what experience you have

- Swap out "full-stack" for "web developer"

Don't tell me you're something you're not. Under-promise, over deliver. Seeing full-stack on a resume sets my expectations for whoever I'm about to interview regardless of the number of years of experience.

edit: styling

This assumes that they are applying to companies with separate frontend and backend teams. My company only has one small team so we all do a bit of everything: frontend web, react native app, backend, ops stuff. We'd never hire someone who was only front-end or only backend because that would leave half the job they weren't doing. But we have hired junior engineers who have only a little professional experience.

Seeing full-stack on a resume shouldn't set any expectations other than they have and intend to continue working on both front-end and backend code.

I'm not sure if you're a hiring manager, but I am. In my experience, what someone writes regarding their "stackness" means nothing to me. It only matters to the extent that it matches recruiter searches. I care about someone's practical experience, their fit for my team's work, and their ability to learn and adapt.
I'm not a hiring manager, but I've interviewed plenty and given my opinions to the hiring managers. I've also discussed candidates with fellows developers and have heard "that's not a full-stack developer" more times than I can count, which leads to "I'm not sure they know what they are talking about."

The point of my response is to say, if something isn't working, change the formula. Here's some anecdotal evidence given my experience that might help. Stop complaining on LinkedIn about it. I personally look at LinkedIn and if I see multiple posts from you complaining about how unfair things are it's going to be an immediate pass.

full stack is a front-end engineer and they're willing to deal with the shitty JS stack.
My personal experience interviewing for "full stack" and "front end" roles.

Full stack interview tracks seem to be identical to backend/generalist tracks. Purely leetcode questions up the wazoo.

Some front end interview tracks are the same. But I'm seeing more and more cases where they will throw "implement feature X in JavaScript" type questions, not leetcode.

I always understood full-stack as "willing to work on both server and client side". In opposition from people who work only on frontend or only on server.