When you first get out of college you can write a 500 line program, and you get dropped you into a million line program. You get assigned a senior engineer to help you over the hump this takes a few years while you learn things that "everybody knows" but are not taught in school. Hopefully you get the first part of this over as an intern, but there is still more to learn.
Once you get over that hump you can do okay on your own. You can be assigned to write code and you rarely need help (you will always need help, but this point not often). You are still learning, but overall you get things done.
Senior engineer is you have been around for a enough years for a few of the following. Different companies value different things, and I've surely forgot something. I know engineers who never made the senior level because they refused to do something on this list even though if forced they were proven to do well.
You start to teach the other junior engineers how to be better engineers.
You start to see the larger picture of the whole system and how it should be changed for the better.
You start to see how the work individual developers do fits together and get involved with planning on how it is done (breakdown and ordering) so that the project finishes on time.
You become a specialist in something that is important to your company. This can be company specific, or a generic skill that applies elsewhere. (note that if the company doesn't realize how important the area is you won't be rewarded - preventing a problem the company never knew they had won't help)
Mozilla engineer leveling chart is a good example.
There are probably other companies that expose the criteria they use as well.
I recent left a level 5 of 7 job for a title level 2 of 6 and still managed a 30% pay raise. On paper, it looks like a huge step back (Consulting Data Scientist to Software Engineer), but in practice, it's actually more of a technical leadership role.
The other possibility is that they have seen the problem before, fixed it, but didn't know it was called "calculating the Big-O bullshit of reversing linked lists while merge sorting"...
I have 25+ years of experience; in a month I will turn 46. I don't have a CS degree, nor even a BS. I'm one of those devs who started basically fresh out of high school, and made a career out of it. I'm not even sure that is possible to do any longer.
What I don't have is all of that CS knowledge and terminology. That isn't to say that I could solve all of those problems, or that I have encountered them, or come up with the correct or practical solutions. To be fair, I am always learning something new (and I like it that way). Also, to the "example" you give, I'd have to look up how to reverse a linked list and what a merge sort exactly was. Hopefully, there's some kind of standard library for both in the language I was using, but if I had to do it from scratch, right now off the top of my head, I couldn't do it.
But I would know how to figure out and ask the right questions on how to do it, and go from there.
And that's really one of the best skills as a developer to have, imho. There have been times where I have had a problem, tried to google for it - thinking it was a common issue - found that it was a common issue, with people asking the questions - but either no solutions, or worse:
...and so, by breaking the problem down, figuring out the answer to those questions (with either more googling, or implementing a custom solution), then pulling all those parts back into one coherent answer for the initial problem - that greater issue can be solved.
Then I find a forum or something and post the solution there, so that future coders can at least have one good reference point, for as long as the forum exists. Nowadays, I'd probably put it on my github repo or something.
Ultimately - there are a lot of "senior devs" (both in age and ability) who are currently in my place; people who didn't go the tradition educational route; people who were coding in their bedrooms on 8-bit home computers in assembler and BASIC because that's all we had at the time. We may or may not have run across those CS-level problems. If we did, we didn't know their names (much like not knowing the names for certain "patterns" - yet another similar thing) - but we still may have implemented solutions for them anyhow.
I have faith in your problem solving abilities. I'm 35 and have a CS degree. The only time I've needed to know Big-O or how sorting algos worked was in college and during interviews. I've literally never been in a situation where the code functionally worked, but ran too slowly because of an inefficient algorithm (and this is with 13 years as a C++ developer).
As for your situation, I suspect many shops would turn you down because you didn't rattle back the answer from memory. But the concern isn't that you aren't smart enough, it's that you're "old" and cost too much. The kid who memorized leetcode can be bought cheaply and discarded easily if it comes to light that he/she can't figure out how to solve a tech bug. If you "follow the money", these interviews could be seen as purely "cheap-but-comptetent people-filters". Because if an old programmer tried to sue them for age discrimination, they could point to leetcode as evidence that all the tests were administered "fairly".
1) Junior Engineer - can write basic code, but usually needs help for bigger projects or navigating a code base.
2) Engineer - Is pretty independent and can whip together what they need based on a design.
3) Senior Engineer - Can take a problem and build a design for it, can lead a team of lower-level engineers to properly implement the design.
There are higher levels like staff and principal engineer, these ones typically are the same as senior engineers but are at larger scopes.
At levels 3 and higher, you tend to write more English than code. You're there to decide what code gets written, rather than the specifics on how it gets written. That's what levels 1 and 2 do, they'll take your designs and implement them.
Been my experience with multiple SV startups now. In some cases went through back-channels to find out what happened (In one case - whole team loved you, CTO had your offer, CEO overrode at least minute and wanted a non-US contractor to avoid benefits pay)
Utterly absurd amounts of time and you still can't be sure!
My proposals -
#1) Companies that want take-home work or multiple day interview processes after initial screening /pay/ for them. You are already paying for your engineers to be inteviewing/etc. Pay the applicants. Keeps incentives aligned (you only advance ppl you really want to see how they work, you don't expect 40 hours + of work from me because I should feel blessed to get the opportunity to work for you...)
#2) More conversation. You can get way more ideas about someone's technical acumen by asking them how they know when to refactor, what they think about tradeoffs around technical debt, how they would think about data modelling something, etc than writing code. A brand new programmer maybe do some pairing, a person that has been writing production code for 3,5,10 years? Ask them the interesting questions and just talk!
#3) Hire quicker/Fire quicker - I think Riot for example will pay you money if you decide it isn't a good fit and you leave. Everyone is already employed at-will. I'd rather have a 3 month probationary period than try to find time for 40 hours of interviews while working my day job.
This is a cancer because many hiring managers will assign out these homework assignments to all the applicants, before doing almost any due diligence or getting to know an applicant.
If you want someone to jump through 8 hours of interviews and calls, then 8 hours of coding, you should be paying them at least for the coding.
Between hearing things like this, the way the internet is going, the way cell phones are becoming more closed up and walled in...just everything about the way the world is going...
...I honestly am beginning to think my best course of action would be to (somehow) change jobs entirely, move out to the middle of nowhere on 40 acres, drop off the internet, build my own cellphone (which I've mentioned), and just go back to hacking on my TRS-80 Color Computer. If I ever accessed the internet again, it would only be for email and maybe the occasional "telnet BBS" - and that would only be after a 50 mile drive into "town".
While I know and understand that despite 25+ years of experience I may not be at the same level as others with fewer years, that time should count for something. In my case, what I lack mostly has been any sort of opportunity for a "management" role; I have never been a team lead, for instance. It pains me. It does nothing for my self-esteem as a software engineer.
But that shouldn't count against me. Nor should being able to solve some rando problem concocted as a gatekeeper. I've worked at places for short periods, and I've stuck around at places far longer than I should have. But lately things have been hovering around jumping at 3 years, and that time seems to be coming up for me at my current place of employment.
The thing is - I don't want to leave. I like it where I'm at. I enjoy the problems. I enjoy my coworkers. I enjoy the development environment. But more often than not, it seems, outside forces seem to conspire to kick me out whether I want to go or not.
Maybe I'll get lucky once more and land a new position. Maybe I can use the fledgling skills I have in ML in some manner. Or I might have to drop my salary requirements down and take something lesser, just to stay employed?
But at some point in the future - the near future - it feels like it won't matter what I do or don't do, I won't be allowed to "make the cut" any longer.
Thank $DEITY I have no debt other than my mortgage...
In my mid-30s and this feeling is only growing stronger. I don't even have a demanding job, I never work more than 40 hours and I get to implement the latest and greatest (.NET Core, Vue).
In the last 6 months I've applied to several remote jobs. I always do well on the sample projects they give me and I have a good personality during the interviews... cracking a few jokes to lighten things up a bit. However because remote jobs are so damn competitive they always focus on one stupid question I didn't answer exactly the way they expected or something I slightly missed and I end up getting rejected. "We're looking for someone with more experience" - I have over a decade of experience, I've demonstrated as much and I can solve pretty much any business problem.
All of it just makes me feel defeated despite the massive progress I've made in my career, all the awards, back to back promotions... all feels meaningless anymore.
So, is it you are working on a project, and when the project is finnished there is no work left, or do you think thay you will get fired, or what am I missing here?
Well - that's always what I try to do, but the last several places I've worked, the decision was effectively made for me, either due to a layoff, or because the company closed down, or because it was bought out (and I was given a real stupid offer to stay), etc.
> So, is it you are working on a project, and when the project is finnished there is no work left, or do you think thay you will get fired, or what am I missing here?
> My first thought upon reading this was: "If you don't want to quit your job, then just stay."
Currently, it's because the client I work for, on behalf of my company (I'm part of a small team here, but the client is international, and the larger dev team they have in place is the same), has made a decision to outsource the work we do here in the USA for a different international team (who likely is cheaper). We will be training our replacements on how the system is designed/working. Once they are "up to speed" (we imagine), our team will be cut loose.
Our boss (owner of the company - it's a small boutique web application business) has assured us that we have an internal project waiting for us, which we've been told about and have discussed, for us to continue on with. It is supposedly fully funded, which I don't have any reason to doubt. The owner is a great guy, and has been up-front about everything going on, and I trust that this will work out. I've told him that so long as the paychecks don't bounce and I still have health coverage, I'll stick around. I really do like our team and environment. I also like the idea and concept of this new internal project.
But I've been doing this long enough that even that may not be enough. Things have a way of turning in business where at one point, things might seem ok, but then overnight a painful adjustment has to be made and you find yourself without a job. I've also told my boss as much, not to sacrifice his business on account of trying to keep us all employed, because I've seen in the past employers with similar small companies I've worked for completely implode because they kept trying to make things work and keep their people employed, when scaling back would have been the better option. It's noble and nice to know when an employer acts that way, but from a business perspective it really is the wrong decision at times. So I've let my boss know that I understand this, because he's that kind of guy - he doesn't want to lose us, we're a good team (talent-wise and such), but I don't want to see him lose the business either.
I'd rather he would stay in business, and maybe I could return in a few years or something when things are looking better.
But so far - there's nothing to indicate that anything like that is going to happen. We're all still employed by this client. The company I work for, itself, has other clients (I am part of a small team tasked to work with this singular client; there are other devs who work with other clients on other web application projects), and this new internal application could turn out to be something wonderful for the company, if we play our cards right.
But I worry because our team lead left for a new position, because he has a family and needed more stability. I worry that the remainder of the team may take that same option, due to similar reasons. I don't have to worry about such issues; I don't have kids - but I do need to be paid to pay my bills, and I need health coverage (more a necessity as I get older).
But there's the possibility - if the rest of my team leaves for "greener pastures" - that the internal project may be shelved, or that I can't work alone on bringing another foreign team up to speed on our current project, or whatever, and at that point, it may be more beneficial for my employer to let me go than to keep me (and, after all, I've told him that he should do as much, right?).
I wouldn't begrudge my employer making that decision, but it doesn't mean I don't worry about it, either. The one thing that keeps me from worrying too much, at least in the short term, is knowing that I am "debt free" (except a mortgage), I have plenty of savings (enough to cover 2-3 years of salary if needed), and that I don't have to provide for a family other than my wife and dogs. In short, I can make things work for a while, until I can find something else or do something else. But it doesn't mean I don't worry about the whole situation...
1. Everybody agrees interviews and tests have some signal, some noise.
2. Some interviews are systematically biased toward skills that aren't a good sample of what work is. But people just want to whine about it rather than propose a better solution.
3. Nobody can agree on what the important skills are for engineering anyways. Which is natural, since it varies situationally.
Likeliest scenario people say a bunch of vague phrases like "communication skill" and "culture fit" and "diligence" at each other, forget they had this conversation, and thread continues to happen every 2 weeks for the next 10 years (I guarantee this conversation has happened no less than 100 times here already).
Hypothetically not-meaningless form of collaboration that would never happen on HN -- people form a google doc and come up with concrete questions that they upvote/downvote to come up with a great engineering interview, and each new discussion adds to the list.
The main contention developers seem to have (in my mind) isn't necessarily all whiteboarding interviews. Its the ones with ridiculous problem complexity and timelimits of under an hour that require inordinate amounts of study every time someone begins their job search (Dynamic programming in 45 min comes to mind). I think there are plenty of good alternatives in this thread: take-home assignments, paying developers to study and take these exams, github code reviews, even just restricting the problem space of a whiteboard interview to less complicated problems are all good suggestions.
The other point I was trying to make was that generally the skills you want to test for in an interview are those applicable to the job. Others in this thread have argued that these whiteboarding problems do in fact test some important subset of the skills needed by most developers. Others have pointed out that at some point though, its gotten ridiculous, and knowing how to sort and array in O(nlogn) is not really applicable to all the jobs interviewing for that knowledge, and it would be a better use of everybody's time to instead test for some other subset of knowledge (SQL use, CRUD application construction, etc.)
Finally I just wanted to point out I am an interviewer at my current company. I do take a lot of these conversations to heart. I have tried to experiment with the interviews I give to make them better for the candidate, and better for the company. Anyways, just pointing out I do think these conversations have an impact :)
I've got a technical interview on Thursday, and they use Hackerrank for their coding platform. I'm seriously hoping that they have something that's specific to SRE tasks, because, if they ask me an algorithm question, I'm almost 100% certain I'm going to fail -- these weren't things that I studied in my EE degree, but, I've learned how to implement things from my positions over the last ten years.
I know what I'm doing, and I feel comfortable thinking and looking for solutions that aren't "inside the box" -- delivering an OS and DB upgrade to 8000+ stores via a USB Stick -- complete with a dashboard that I wrote, microservices soup to nuts (meaning: I worked with the developers to make better containers, and then wrote the ansible playbooks to deploy OpenShift in EC2) for a major hotel company, web governance/best practices for a top 5 Quick-Serve Restaurant chain. Asking me the difference between a Markov Chain and a B-Tree isn't something that I've ever needed to do...
On the other hand, when I was hiring in the Washington DC area, the number of Senior developers that I'd get from government contractors who couldn't count to 1000 by 5's in a language of their choosing really hurt my soul.
If you want to do well on the interview, you should brush up on recursion, binary trees and hashtables. If they are using HackerRank, it is almost guaranteed that the questions will be algorithmic rather than SRE based.
I realize that there are problems with it, but I'm a huge fan of take-home problems that are similar to real problems the candidate would face on the job.
I understand the attraction of simple decision metrics, more so if you're in the unfortunate position of having to make a technical hire with no experience of your own to guide you. But consider the referenced tweet that implied 250 resumes were too many to read. You're going to hire someone to do a highly complex job, spend months getting them up to speed, probably work with that person for at least a few years, and you can't come up with a way for your company to at least scan 250 resumes? I mean it's like pretty close to the one main thing you're there to do: find and hire the right people.
The antipattern here isn't that there are puzzles. The antipattern is using some external screening service using the same process for all candidates. There shouldn't even be a HR person screening before the team and hiring manager is.
(I completely get that this is unfair. If you went to MIT and have a high GPA, you are gonna make it past the gate more often. Community college, but an excellent coder? Unfortunately you will be rejected more often by HR. It's completely unfair, but companies can't reasonably interview every candidate who submits a resume.)
Honestly, command line Linux skills and a take home (<1 hour) “build an app in <relevant language> that does x” is far more relevant to my work than some timeboxed HackerRank contrived example.
My favorite screening tools have typically been “here is an app with failing tests, fix the failures.” I have been screened out of all manner of dinky companies from these contrived tools. A reasonable oral technical interview to ensure the candidate can communicate within the domain is far more valuable than contrived tests of solving problems unrelated to the actual job. I can learn more about a candidate asking about use cases of SOA than I can by watching them calculate prime numbers.
I started in software over 10 years ago. At that time all of the exciting jobs where for small startups and the best way to get hired was to have a great github profile or some cool projects to show off.
But small startups need a hand full of really talented devs who can solve a variety of problems, and quickly get up to speed on new domains and tech stacks. A few good developers could make a company. So hiring focused on individuals who stood out and had something unique they could bring to the team.
But FAANG companies want to hire engineers that they can treat as replaceable parts. The "rockstar" talent that was required a decade ago is a liability. This may sound like a critique but it makes perfect sense from the business standpoint, and while you can protest this all you want it won't change a landscape dominated by large software giants to one fill with disrupting startups.
It's just a different world and if you want to show that your "experienced" and not just "old" you need to show that you can adapt just as well as a decade ago. I had a moment of enlightenment when waxing nostalgic about github profiles to a really talented new engineer doing prestigious work in deep learning. I told them how much better profiles based interviews where and they reacted with horror. "How am I supposed to build a profile when I'm so busy with school, interning on the side and studying for interviews!?"
Software used to be dominated by passionate hackers, and now it's one increasingly of skilled professionals. The best work people just as hard but in a very different way.
Like it or not, software is not like it was a decade a go, and if you still want to be seen as a top tier engineer you're going to have to do it by the standard of today.
- A vast number of people masquerade as "programmers", "engineers" or "developers" who couldn't code their way out of a paper bag. If you don't believe me, you haven't conducted interviews.
- This was the key motivation behind FizzBuzz. Passing it doesn't mean you're a great programmer. Failing it means you're almost certainly not. So the ability to turn a super simple "algorithm" into code in [language of your choice] is an incredibly useful negative filter.
- Interviewers and companies fall into the trap of thinking "this problem is too simple; let's make it harder". In doing so you devalue the negative filter and gain NOTHING as a positive filter. Worse it can turn into a gamble as to whether you happen to know the particular trick for that problem. Tortoise and hare or O(log n) bit reversing fall into this category;
- Taking a problem and being able to reframe it in terms of standard data structures and algorithms like recognizing it's a particular graph problem is an incredibly useful skill. These don't always need to be turned into code.
I'll say it again: the biggest problem is people try to make whiteboard problems "hard" making them a useless signal.
- I'm dead against "take home" tests. I don't have time for that. This seems like a great way of getting mediocre candidates. Like, what makes you think if someone can't do it they won't "cheat"?
- Talking about robust systems design isn't done often enough;
Here's another thing I've pondered: how much of coding interviews and the notion of "cultural fit" is really thinly-veiled discrimination? I expect quite a lot and I expect this to blow up at some point.
It goes without saying that 60 minutes is too short a time to ask someone to solve a real life business problem, but real life business problems tend to be broken up into many small problems, which can in turn be simplified and presented to the interviewee.
The discussion I've been having with colleagues is how to do precisely this - eschewing the typical leet code/hacker rank problem, what problem can we come up with that has high fidelity to real life work, without being too complex for the 60 minute interview? I definitely think this is possible, and normally you get to that kind of question by working backwards - what is a real life feature I'd implement, and how can I ask a version of that during an interview. One example would be a graph of similar categories. Categorization is a common issue, and graphs are a common data structure.
Side rant - I've seen a lot of hate for things like data structure questions and algorithms associated with data structures. It's definitely possible to have an entire career of programming where all you do is build CRUD endpoints and design relationships between objects, but sitting down and learning about these amazing data structures that have been refined over decades of work can seriously improve a lot of code. A common problem I've seen is people building rigid object hierarchies (by composition, not inheritance) where a tree would have been way more flexible and easier to understand.
A hard problem with no practice is effectively impossible unless lucky enough to have faced the exact same on in the last month. Selecting for the lucky at that point.
Lets dispense with the fantasy we can select the "best" in an hour, and move toward short contracts instead.
I've used the last question from Stripe's last CTF for this. Roughly speaking: Given a 5 node SQL database cluster, how do I make it behave as a single server? I don't ask them to write code, I ask them them to walk me through how they would approach this problem and how they would deal with various failures (network interruptions mostly to keep it simple).
I have over 8 years experience as a developer and applied for a Senior .Net Developer role. I have plenty of experience in the technology stack and worked as lead developer on some high profile projects in my current role which have been successful. I'm no rock star but I get stuff done and I work well with others.
The company liked my CV and cover letter and send out a HackerRank link for me to work on. My first thought was "sh*t" as I struggle with these things but also how impersonal it was. The everything was weighted on the HackerRack test. At least speak with the candidate and get a feel for them. Even a phone call.
Hiring as they say is one of the hardest things you can do. It's time consuming and costly so I think they have these tests as away to cull the herd so to speak but it's obviously not ideal. Basecamp have a podcast called rework and one of their episodes called "Hazing not Hiring" deals with this. It's really interesting.
For me, I'm going to try to work on a side project and use this as another part of my application. Almost like a portfolio. Hopefully this will be enough going forward.
Other skills, such as multi-thread programming, debugging skills, get less coverage. Many whiteboard coders who know how to solve dynamic programming on a whiteboard, don't know how to use mutex and semaphore.
I think the whiteboard interview process is broken.
it's like recruiting warriors based on gymnastics skills. I think it makes more sense to look for street fighters.
On the developer side, whiteboards feel like having to study for the SATs again, which is doubly frustrating at the senior level because you know better than before how little these questions correlate to qualification. Irrelevant, spam-esque LinkedIn messages from recruiters confirm how sloppy the whole process feels. And you spend the whole time thinking, there just HAS to be a better way.
On the recruiter side, they have to wade through a horrifyingly-unmanageable torrent of unqualified resumes with the help of bad tools. When a great candidate fails their test and can't move forward through the process, the recruiter is almost as frustrated with the process as the applicant (management, I'm told, remains unwavering in their commitment to "establishing a baseline"). Even worse are the candidates who are filtered out from the process by Applicant Tracking Systems because their resume lists "8+ years of experience with a wide variety of NoSQL databases" and not "MongoDB"
I think both parties recognize the inefficiencies in the process. Where we've landed is the following:
- Developers need to learn to play the game. Understand how much of a black hole "Easy Apply" buttons can be and not rely on them, optimize their resumes for the role (including anticipation of boolean searches based on the job posting), and make meaningful connections with their local tech communities so recruiters know where to find them.
- Recruiters need to advocate for flexibility and transparency in the process. Workflows involving "shoving as many people into the funnel as possible and use an ATS to sort through the noise" are untenable. Reconsider systems that treat whiteboards or tests as requirements and not just data points. Offer up relevant information earlier, with the hope that good applicants will use that info, and their honesty, to help you figure out if they're a good fit.
I was rusty from traveling from 6 months and definitely wasn't prepared. But I finally landed a job at a place that was a little more old-school in their hiring process, and as soon as they could they converted me from contractor to full time. So I guess it's working out for them (and me).
If you want a developer who can rattle of a computer science algorithm, then whiteboard interviews are the way to go. I would rather ask the developer how she would create a password authentication scheme, and in doing so potential avoid a data breach down the line when they fail to apply proper security principles. Or I would challenge them on how they normally approach a problem, so that I could see how teachable they are. People who are not teachable are bad for business. I would also ask them to share a technique with me to see how willing to share information they are because IT people who don't like to share information are equally bad for business.
Lastly 'culture fit' is about finding more drinking buddies, if that's what you're hiring manager is doing you should fire him asap.
1. Initial video conf meeting to make sure he/she can communicate well. Talk about the role. Have a technical discussion covering candidate's past experiences to evaluate whether they really did what they claimed to have done. Discuss a technical subject that the candidate is passionate about. If satisfied, go to Step 2
2. If the candidate is a strong referral, go to Step 3. Otherwise, do a technical phone interview where the candidate solves a simple problem (more complex than FizzBuzz but not the standard algo/DS/string manipulation question)
3. Onsite Interview. Session 1 - write a simple service (todo list, twitter clone, etc) - 2 hours.
4. Session 2 - Ask the candidate to do a code review where the code in question has bugs and is poorly designed.
5. Session 3 - Candidate does a presentation of some technical topic to the team or at least a few people in the team.
6. Session 4 - Lunch
7. Session 5 - System Design exercise focusing on testing candidate's depth
Train interviewers to provide objective feedback. Calibrate scores for each question ahead of time. Interviewers should be calibrated as well. Ideally, same pool of interviewers for each question.
I'm not saying your process wouldn't be effective, but it is asking for a very big commitment for one interview for one position at one company. (And that same commitment would have to come from your company and all the interviewers involved!)
* Count the number of vowels in a string
* Transform a dictionary that's key'd on file name, with the value as the file owner into a new dictionary with owners as the keys and their value as a list of files.
* Deduplicate an array while preserving order in linear O(N) time
* Solve a simple problem using a closure (You can even google what a closure is)
We go out of our way to make sure the interview is conversational; we talk to candidates like they're our colleagues. Too often, technical interviews seem like interrogations and I absolutely hate that.
Candidates can code on their own laptops, ask us questions, and even google stuff. The only rule is no googling for the problem directly, but if you need to look up if some datatype has method X or forgot its signature it's not counted against you.
The point of this is to just to do a basic smoke-test of the candidates programming skills. They don't need to get them all correct, but they should be able to solve at least 1 or 2. If they can't, then we politely end the interview.
The rest of the interview is talking about coding, projects they've worked on, challenging and interesting problems, wish lists, and for more senior people architecture/planning, and a mock code review: we give them some bad code and ask them to give feedback. The entire process takes about 3 hours.
I get the frustration of senior devs at going through this stuff, but the alternative is a weird form of credentialism based on seniority.
Why can't I prove that I passed this screen once, then take a piece of paper to each of my FANG interviews and skip the technical part. Then maybe retake it every 5 years if I'm interviewing.
It is not a good indicator of competence.
Most people pay a third party (after having paid for law school) to cram the information into their head in a short period of time.
RHCE for example isn't great, but having passed both I think it's actually better than the bar exam, since they at least hand you a live broken server.
I've been rejected by companies who were using open source code I wrote.
I have seen too many very senior engineers in the company that is more of a testing engineer nowadays, they do well in analyzing the issue at certain level, document them etc, but they're unable to fix anything that is deep and really complicated in a new code base that is huge(e.g. linux kernel, android framework), each meeting I kept hearing "I know exactly where the problem is..." but after many weeks there is still no fix, or the fix broke more things that it fixed.
A few weeks later a junior guy(not fresh-out though) came in and dove in and dug in then fixed it in a few days.
Senior developer means a lot only if you keep learning, keep coding, resharpen all your skill daily, and stay current. Otherwise, the title is a big negative to many companies, as the performance to price ration is totally unjustified.
Alternatively you could look for a different path in life. Best to get out of the coding jobs early in your career. Don’t look back.
That said, there are some good reasons to do the coding path. At the high end, they pay very very well, and there's no bar organization forcing you to get a $200K 3 year degree. Salaries start higher, and working your way up in other job ladders can be a grind and take quite a while to get up to SWE salaries.
I’ll leave the paradox of industry claims of a shortage as an exercise for the reader.
Best example, I have ever had I was interviewing for job about 6 years ago with a start up. The guy that was interviewing me has a CS masters degree strong tech stack background, probably lacked personality. He asked me what polymorphous was and at the time I didn't know. I just told him that I didn't know. Then he went on to explain it to me. Which I really didn't care about learning about. It was clear I wasn't going to get the job and that was fine, it didn't hurt my feelings. However, I learned to code because I have a background in finance, stocks, and options, before I became a coder. I have built stock algorithms that are profitable, regardless if they don't use all the right classes or OOP. So when this gentleman told me that I wasn't good enough for the job, he followed up with, I really like what you are doing with stocks and your stock algorithm, maybe we could meet for coffee sometime and you could tell me how your algorithm works, etc.
So I'm not good enough for your job, but but you want to learn about my algorithm. (the company went out of business 1 year later.) Pound sand.
The problem that I face is I don't want to be a Senior Dev. I have enough side projects and work life balance that I'm not trying to hit the CTO career mark, unless maybe with a start up. Some one mentioned that that they where like a studio musician. They aren't going be the rock star, but they do well with the band, etc. That's probably me, I'm more interested in my side projects. But professional enough to work at a day job.
Whiteboards, interviews, take homes I'm not seeing this get much better anytime soon.
The issue is that there are a lot of programmers who have a lot of years and who consider themselves senior who have very little programming ability. If you have been with a “senior” developer who had no idea how to program but was always telling other people what to do, because he was senior, you know the danger of hiring one of these.
The other thing about this is preparation. It is no secret how these companies are screening and interviewing. A truly senior developer who really wants the job, with a few weeks of practice for an hour every night can considerably improve their chances.
Thing is, very good people always have a plethora of options. So a company that tries to make a talented developer jump through somewhat silly hoops, is often going to miss out on that person. Google for example will say, 'we're ok with a lot of false positives' but they are also missing out on outright brilliant people who can make an outsized impact.
The FAANG companies can get away with it to a degree, because their compensation is so high. But there are a bunch of companies out there copying these hiring processes when they can't pay anywhere near what those companies pay, nor offer anything else compelling enough to make up for that.
So on one hand, yes, if you want to get paid the big bucks to work at one of the FAANG companies, you play ball their way and jump through the hoops. But that strategy is not going to work very well for the vast majority of other companies.
But why would I want to spend that time? There's a lot of companies out there looking for experienced people. I have better things to do than to cram things I'll not actually need. I'm lacking time, not tasks and ideas.
I'd be damned tempted to walk out of an interview if they expected me to do trivial programming exercises.
I'm curious on how HN would filter developers like this. I've been a fan of take home exams, but I know that doesn't work for everyone.
1. It is a problem representative of the work the person will normally do in the job (we use an extract of our actual data for it)
2. We provide clear guidelines and criteria for success.
3. They are allowed to implement a solution in any language they choose, using any tools they choose (we ask everyone to bring a laptop with their preferred dev environment, but we do provide one with some common tools for them if they can't).
4. They are allowed to use Google and open-source libraries to help them with the solution (we want to see how they really solve a problem)
5. We are there to interact with them and answer domain specific questions, as well as to offer advice if they are stumbling on something to help them move forward.
I've really, really gotten a lot of good mileage out of this. The range of skills that I've encountered over the years has really surprised me. The problem is pretty straight-forward, and usually involves parsing some JSON, looking at the data, and matching disparate sets of the data together. The basic O(n^2) solution can be done in about 20 lines of code and there is some nuance to the datasets that require them to think through the problem and not what they have memorized in their head. I've had programmers with years of experience from places like LinkedIn take 20 minutes just trying to read a file in from the file system, and I've had people who are self-taught developers crank through a really good solution in the same time. I like being able to see how people are writing code, how quickly they are able to lookup information they might need, and listen to the types of questions they have when trying to solve the problem.
There needs to be a interview training/mentoring period where you have engineers sit in on interviews to learn how and what questions to ask but without actually having veto/accept power. this allows them to get experience without screwing up the whole interview process.
Most inexperience engineer interviewers think you get the best candidates by having the highest reject rate, and that's simply not true. Only interviewing experience and training can improve this.
The important skill to learn is figuring out how to do it. Coding is no different. For example, I've yet to use React to build an app, but I have taken the time to learn the basics of how it works. If I needed to use it I could, and would, and it wouldn't slow me down much, if at all.
I think what's important is discovering how adaptable one is. If one gets whiny about using a specific toolset they're going to be a problem no matter what you put them on that requires something different than their existing skill set.
TripleByte has a very clear process which leads to a two-hour frontend interview, an hour of which will be dedicated to building something with React.
Give it a try: https://triplebyte.com/iv/NKCtNG2/it
You’ll surely learn something.
I work in DevOps. If I'm interviewing someone, I'm going to ask "Explain the difference between continuous integration, continuous delivery, and continuous deployment". A junior person who can answer that well gets a big thumbs-up from me. A senior who can't answer it will probably be rejected out of hand.
In neither case is implementing Towers of Hanoi on a whiteboard useful for the job.
The fact is that business is trying to turn us into commodities and it sounds like right now they are winning...all that we can do it either adapt or change careers sadly.
1) create a very small web API
2) CLI the frontend spa of your choice
Just toy examples with some in memory data and filtering
Time boxed to an hour.
No crazy puzzles. Just demonstrate you can do the basics. See how far you can get, discuss as you go...
High failure rate. Even when I'd basically prep the candidates in the phone screen.
I'd basically tell them what they had to do. Still didn't prepare.
I've been burned on the take home projects and super crazy timed algo puzzle tests with the terrible instructions. I try to take the stress out of it as much as I can.
Now I actually get to read it :)
Why the fuck is someone asking a lead-level expert with over two decades of experience a first-year CS question? Because that's the process? It's a total failure. Asking senior people to do basic things like that is insulting. Don't you have anything better to ask?
While I'm reasonably good at these style of questions, I'd be very unsurprised if there were a few that'd just catch me cold, even today. And I'm probably working in a field that's a lot more day-to-day data structure heavy than most (RDBMS internals).
It's not that it's difficult. It's that it's stupid.
edit: Let me put it this way... if you're hiring a senior/lead level code security analyst, the odds that they will be implementing (or even reading for comprehension) a binary tree are effectively nil. The odds of having to show how to mark false positives in a Fortify scan are very, very high. Can they explain buffer overflows, html encoding, etc? Can they write a description of unsafe practices in plain English, for both developers and managers? Do they have experience in conducting training classes for developers to reduce security problems? Do they have a working knowledge of HIPAA, SOX, or other relevant industry regulations? Can they do good Powerpoint presentations on this stuff?
Being a security analyst isn't about writing homework assignments from freshman year of college. It's about regulations, about training others, about using high end tools that aren't taught in college, and a bunch of other stuff. Ask questions about the actual job.
Imagine if someone asked you to conjugate verbs or graph sentences to demonstrate your English skills. Would you do well at it, even if you're a native speaker? After all, you learned that stuff in elementary school.
What gave you the idea that it was anything but a blog post/personal opinion piece?
Yep. If you're asking for hundreds of thousands of dollars a year in compensation, then you'd better be prepared to jump through some hoops.
But something else was brought in to replace them all.
And it's called culture-fitism and ageism.
I typically won't do programming challenges. I don't believe it's fair for the applicant, because if it becomes the industry norm then applying for 10 jobs means 10 separate programming challenges just for the opportunity to get an onsite. But, recently, during a phone interview with a shipping logistics company with a common first name in their name, I vibed with the lead I spoke to and decided I would give their hackerrank a go.
The solution I came up with was using a temp table, that hackerrank permissions did not allow. The array question, my (working) solution timed out because one of the tests used an array with several million units in it. There was no indication of a certain time this should run under. It took about five minutes after submitting to realize a way that probably wouldn't have timed out, but at the time I was happy with my solution given the whole test was timed and I had written six lines of code to solve this problem.
I had really thought my answers would grant me an onsite, but it didn't. So yeah, back to not doing stupid timed tests.
This was a month ago. The position is still open and I expect it to be for the near future.
If anyone read this far, I have given some thought about my various interviews after some interesting ones recently (another recent time at a .net shop I was asked to demonstrate sorting a list so i did a toarray() then sort and they were like no, do it manually).
I'm probably going to put together a blog about my interviews over the years since I've had all sorts. I feel like as deep as retrospective as I can remember over my decade of interviewing might give me some insight as how I should be better.
"You can't invert a binary tree". Well doh! Maybe you should go through the effort of at least looking at some of the basic algorithmic concepts again, you know just to show that you even remotely care to be hired by the company. They have a much harder job than you do. They get hundred thousands of applicants per month and need to filter them out. You are one person applying at maybe 2-3 companies a month or week.
To me, this sounds like someone who thinks too highly of himself and "he doesn't need to prove himself to a FANNG company". Well think again, writing Homebrew doesn't mean anything. Pretty much anyone at a FANNG company could do that, but not everyone wants to do it. If you want to work at FANNG instead Homebrew, you need to prove yourself to them, not vice versa...
Is it really too much to ask to spend a few days solving some programming puzzles on a whiteboard?
If few days are not enough, then maybe you really aren't as smart as you think?
I think people these days really tend to always put the blame on others. What about starting to look at yourself more critically, think about if you are really a "senior" engineer? I work in tech for years now at FANNG companies and "senior engineers" are in a different league. I think I will get there in one or two years but it has been a long ride. These people are paradigms of programming that can always give you useful insights and advise. They excel at a wide range of soft skills and management too.
If you see what most companies (outside of FANNG) consider "senior" you will know why (1) senior engineer means absolutely nothing and (2) why FANNG is not interested whatsoever if you were a senior engineer somewhere else...
Who cares if you can invert a binary tree? Who cares if you can write a binary tree? I know what I've needed to know really well, because when it hit me in the face, I learned it. If I need a self-balancing whatever, chances are I'm gonna grab one off the shelf and call SomeBTree.new(args).
The problem with "maybe you should have just learned those simple concepts" is that there are an infinite number of clever questions interviewers try to ask, and close to none of those questions matter. The management that wants to have confidence that applicants can verse a binary tree is also the management that would not let you budget the time to create a binary tree if you actually needed one from scratch... "you shouldn't have to worry about that, just ship it and move on".
Most of my job as a dev seems to be cleaning up the messes of someone that cleverly coded everyone else into a slow, unmaintainable mess. How interviewing for that?!
It's not a matter of capability - in over 20 professional years I've yet to run into a problem I couldn't solve when I was motivated to do so - either because my job required it, or just because it was interesting.
It's a matter of valuing my time. I do. Companies that want to put me through 12+ hours of interviews and exercises do not. And if they can't value it for interviewing purposes, chances seem very low that they'll value it when I'm an employee.
Guess I was too expensive, heh. The tone of the declination was actually super kind.
My feeling now is that the fact that it is arbitrary and doesn't have that much to do with real-life work may be a feature. You can dissect job performance in a number of ways but I think most people would agree that these four factors are important: general cognitive ability, conscientiousness, domain knowledge and motivation. And of those, domain knowledge is already relatively easy to discern from the resume and otherwise easy to screen for and if your company is doing anything unique, not as important in the long run. Almost any process would do a sufficiently good enough job of taking into account relevant domain knowledge. Thus what makes one process better than others has more to do with extracting other signals.
Whiteboard coding interviews, by being timed, somewhat arbitrary, yet something that is widely practiced and easy to study for, implicitly selects for cognitive ability, motivation and conscientiousness. It's hard enough that you can't be dumb, it requires enough preparation that you have to be somewhat motivated. And the process of preparing for interviews is sufficiently repulsive and it's easy enough to fool yourself that you're prepared enough when you really aren't, that studying to the point where you're prepared is a test of conscientiousness. This creates a paradoxical situation where the test itself isn't necessarily that relevant for the job, yet those who get through the test are almost always very good.
In short, given that what you need to do to pass these interviews is fairly widely publicized, the ability and willingness to do what it takes to pass positively signal that you'd make a good employee.
Even if you're great at software development, if you're neither sufficiently motivated nor conscientious enough to prepare yourself to pass these interviews, it's unclear to me why you'd also go out of your way to excel at any given job - every job requires you to do things you don't want to do, learn what you don't care to learn and deal with a variety of suboptimal situations constructively. So while I'm sympathetic to the point of view that this shouldn't be how things are done, I think the willingness to say, "you know, this is how things are, so let's deal with reality as it is instead of wishing it away and ignoring some of the best job opportunities because I don't want to study" is a positive characteristic. Every job has challenges like that - something that in an ideal world is kind of stupid, is not at all fun to do and takes a lot of effort, but doing it is strictly better than not doing it. You want to hire people who are willing to do these things, not just complain about how stupid it is.