Code Interviews
alaiacano.github.ioI won't bother with coding interviews. I consider them to be "hazing rituals"; not actual qualification assessment. I am very, very fortunate, in that I don't have to deal with them. I am not looking for work, and plan to never look for work, ever again.
I have a giant portfolio[0]. It has links to 40 or so repos, with tens of thousands of lines of code, spanning decades. Just about every project can be cloned, built, and submitted to the App Store, or SPMed into your own work, in about thirty seconds.
I've written stuff that is now a worldwide standard infrastructure, and the links to that work is in my portfolio, as is a blog entry, where I discuss the strategic thinking that informed its genesis.
I've written dozens of articles, tutorials, and blog entries, that detail the way I think, work, document my code, evaluate and implement architectures, and work with others. Links to all that is...you guessed it...in my portfolio.
There are years of checkins, so things like development velocity can be measured. My GH ID is solid green.
If you aren't willing to even look at it, then we probably won't get along, and we're both better off, avoiding each other.
You are proving exactly why we need a standardized way to judge whether a candidate is hirable. All the candidates I see have almost zero history of contributing to OSS or maintaining side projects. Their work history usually consists of some run of the mill experience.
I have to rely on that and absolutely do not expect them to have a green GitHub. I would hate for that to become the norm.
That is why we need to ascertain coding signal. And that is why we need some contrived problem to provide to ascertain within a reasonable amount of time whether a candidate is a yes/no.
You are a unique data point and hundreds and thousands of other developers just don't have that kind of clout (I didn't look through your resume thing).
Also, from a hiring perspective, it's not scalable going through a candidates repos and verifying their worthiness. However, it is fun to talk about them during interviews.
Oh, yeah...one last thing, before I go...
I'm a unique talent. I'm not God's gift to Programming, but I have a very different kind of backstory from most that you find. I had a hard road, and the uneven terrain that I traveled, has a lot to do with how I became as good as I am. When no one gives you breaks, you are forced to make your own, prove yourself, at every step, and accomplishment becomes habitual. You learn not to overpromise, figure out how to learn new stuff, and check your own homework.
Many of the team I led, had similar eclectic backgrounds. They were all senior-level C++ algorithm developers, with decades of experience. Most were smarter and better than I am.
We all would have been immediately rejected, in barbarous fashion, from today's hiring process.
As it turns out, they have all gone on to do very well, and that makes me happy. I am glad to have been a part of their career. Working with them was a signal honor. They are making their new employers quite happy, indeed, but it took each of them over two years (in a couple of cases, well over two years), to really land, which is quite telling.
In my first three jobs, I never worked with one single engineer that had actually had real software training. I worked with astrophysicists, mathematicians, MBAs, chemists, designers, economists, teachers, electrical engineers, and even other high school dropouts, like me. Even my last, long-term job, was mostly with EEs and physicists, but all the Japanese folks had serious sheepskins. It was a fairly marquée corporation.
Sorry, need to call BS for all the impressionable young readers.
The job of ‘programmer’ takes on many shapes and sizes. Businesses evolve and are different from one another.
You may be very successful in some clusters of business, but how representative is this, let alone your unique experience, to the rest of the industry?
If you’ve never worked with anyone with “real” software training, why would I hire you into a senior position when there are plenty of candidates who have?
I’ve worked at companies back in the day where experienced non traditional programmers have both kick started and ruined businesses within the same job. You may be successful enough to grow a business, but that’s different from scaling or pivoting one.
If you can’t grok a homework program from the first week of a data structures course, why should I trust you to self learn more advanced topics? Why would I spend a ton of time evaluating massive GitHub contributions vs. just watching you code a problem your team would work on for 1 hour?
I have to pay smug kids 100s of g’s because the labor market is so fucked, and there’s no way I’d either trust them to evaluate candidates via code review, nor would I spend their time on that vs. building and learning.
I’d love to not pay children small fortunes, but most very experienced journeymen I’ve interviewed over the years can’t string together dynamic api calls or tell me how things scale, and I get to hire for experience first every time.
If you were able to self teach, then the kid that just spent 4 years snorting adderall and interning and google sure as hell has a chance to, too, and he’s willing to solve my dumb riddles.
The other thing you won’t read: firing people for most managers is awful. A manager only takes so many risks before they learn how to mitigate having to experience this horrible experience. I’d rather reject you than fire you.
Edit: I was one of the impressionable young readers once upon a time, and I set myself back quite a bit taking advice from strangers on the internet. Genius programmers on GitHub don’t sign your paychecks.
You…um…do realize that I wasn’t giving advice to “impressionable young readers,” right?
I was merely recounting my own personal experience, and, a bit more cautiously, opinions. I say “cautiously,” because I know that opinion is a different thing from fact, and I need to be careful to avoid presenting my opinions in a manner that frames them as “facts.” In another thread, I needed to do a mea culpa, where I did just that, and was [rightly] called out for it[0].
No BS at all. It actually happened. Are you calling me a liar? Because that is what it appears to be, and I was under the impression that we don’t do that kind of thing, here. One of my personal postures, is that I stand behind my own words. Please note that I have links to my entire portfolio, and many, many ways to back up (or refute) what I say. I deleted my last anonymous posting account, years ago.
One of the issues that I have, with today’s Internets Tubes, is that people like to anonymously spew out opinion as fact, and take every opportunity they can, to insult and demean others. I make every effort to avoid that, in my own interactions. Feel free to go through my posting history, and show me otherwise. If I am wrong, I live a lifestyle, where I am required to promptly admit it, and make amends. I believe that I do this.
I have merely written my own experiences and personal story.
It makes me very, very glad to know that I never have to put myself into a position again, where certain types of folks have power over me. I am quite aware that my own story is different from the run of the mill, but being called a liar for telling it, is beyond the pale.
This new world seems dark and depressing, to me. A Lovecraftian “food chain” world, where everyone is constantly battling everyone else; including their own teammates. I used to look forward to a career of excitement, adventure, learning, and being a member of teams, where I was the dumbest member, and it was an honor to be included. I have never been interested in competing with others. I have always wanted to collaborate with others. I am rather saddened to learn how unique this approach is.
In a lot of ways, I got that, and I’m grateful, but I now see that I probably dodged a bullet.
If there were anything I would say to “impressionable young readers,” it would be:
Damn. Did it again. Forgot to give advice, and only gave experience. I feel very, very fortunate to have had mine. Reading the experiences of others, reinforces this gratitude. I do believe that living a life of Gratitude has helped me, in many ways. I also believe that it has helped others, in my orbit, as well. I’m told that I was a pretty good manager, and I have done a significant amount of unpaid Service work (see: Portfolio).At one time, some of us looked forward to careers that were not gladiatorial arenas. We woke up, every day, anticipating learning new stuff, and felt honored to be part of a team, composed of people that humbled us, but never humiliated us. We made enough to have a comfortable living, never worried about putting food on the table, and didn’t have envy for our coworkers. We didn’t measure our own self-worth, by demeaning others, and we felt as if we were riding the crest of thrilling new discoveries and technologies. We stayed at companies for many years, because we believed in the aggregate mission, and liked the idea that we were making a positive difference in the world. We became lousy interviewees, because it was an unnecessary skill. We never “hazed” one another, and embraced our differences, as they brought new perspectives into our worlds, challenging us to constantly review our own opinions and worldviews. There was, once, a happier time, before The Great Old Ones burst through the portal, and made the world as it is, today. I lived in that time, and am reporting from *experience*.If merely recounting my own experience and personal worldview is considered a threat, I have no words, other than I truly feel badly for others.
Now, I truly am done with this thread. Have a great day! I sincerely wish you and your family, health, success, happiness, and fulfillment, in all your affairs.
You are taking a very active role in discourse in a public medium. This isn’t your personal blog, so you’re intentionally broadcasting your experiences to anyone and everyone.
> .. I see have almost zero history of contributing to OSS or maintaining side projects.
Not sure about US, but in EU, the contract from employers doesn't allow you to contribute code without permission (e.g. contributing to OSS, working on side projects, etc), it's very very rare to find an exception.
You can check this discussion few weeks ago: https://news.ycombinator.com/item?id=27843198
> I have to rely on that ..
By doing this, you are not considering employees who are doing nothing wrong, but follow the rules and respect the contract terms.
Very good point. Depends on the company.
I was fortunate, in that I didn't have a "shower clause" in my employment contract, so I was able to do a lot of extracurricular work.
In fact, it was a principal reason that I stayed at that company. They paid me...OK...for doing the work I hated (managing -but I was also a good manager), and let me have enough bandwidth to do my extracurricular work; which was my true passion.
Basically, the work I didn't get paid for, was what I really wanted to do. They were extremely happy with the work I did for them, which did not reflect my true, personal passion. I feel like I was "just going through the motions," as a manager.
But I also firmly believe that if I am given responsibility for a task, then I do it to the very best of my ability; whether or not I am passionate about it, and I'm actually a really decent manager (for the type of team I led).
After leaving that company, and learning (the hard way) that no one wants to work with a 55-year-old engineer, willing to work at half the wages of far less-qualified people (because I already had my retirement set), I was forced into early retirement, and actually achieved my dream, which is writing code to help out NPOs, for free.
I never heard of that. I'm originally from the EU and in the country I'm from, employers cannot control what you do in your spare time, and do not automatically own what you do outside your day job. In the US that's much more complicated.
Ask your employer, most people don't know about it.
i’m self employed
> I never heard of that ...employers cannot control what you do in your spare time.
If you are self employed, you might not get the same contract. In our contracts, what has been discussed in the thread was clearly stated by our employer (I asked my colleagues about their older contracts as well).
> Also, from a hiring perspective, it's not scalable going through a candidates repos and verifying their worthiness. However, it is fun to talk about them during interviews.
I was a hiring manager for 25 years. I would have killed for this kind of information.
The people I hired were no slouches. It was a big deal, and not to be taken lightly. I loved multi-page résumés.
For a long time when looking for work I got absolutely no callbacks. A friend looked at my Resume and said "You have this huge block of skills you say you have but you have no explanation for how you have them." I explained it was because I got most of my experience from working on OSS software or software for myself and if I listed everything my resume would be ~2 pages & ~4 sides. He said to go for it despite everyone else telling me at my age (18 at the time) my resume shouldn't be that long.
As soon as I listed everything I started getting calls back.
so this basically means people assume you are lying and a fraud, which is another problem that is not talked about enough - it should not be assumed that you are like that, until proven otherwise.
Why? People lie a lot about their skills. The fizzbuzz test was invented a first to filter candidates that said they knew how to code but didn't, and it was very effective at it.
Being able to write software does not automatically imply you are able to write software while on a video call, and while explaining what you are doing constantly.
True, this approach will cause false negatives. But from what I understand, most people in interviewing prefer false negatives to false positives.
Sure, they can go right ahead and keep preferring to pass on exceptional people and hire mediocre people instead who will entertain their circus. Sooner or later they'll find out that won't work so well to stay competitive.
> keep preferring to pass on exceptional people and hire mediocre people instead who will entertain their circus
That's what big companies are all about, there's really nothing new to see here. It seem to be working well for most of them though.
this is exactly the issue - if you cannot take a moment to look at a candidate’s work but can waste 10 hours in leetcode zoom bullshit calls your system is broken, sorry
People making non-trivial contributions to open source projects or coding in their free time are an exception. Most candidates (>99%) have no work you could actually look at.
> Most candidates (>99%) have no work you could actually look at.
Most inexperienced candidates...
One of my favorite pastimes, is following up on GitHub, with people from this joint, or others, that pique my interest.
There's a lot of really awesome stuff out there! You guys rock!
Of course, many of these folks, are...chronologically challenged, let's say. If you've already decided that you will only be hiring folks right out of school, then I can see the problem.
And...to answer the inevitable "You're likely an insufferable bastard" canard, that the conversation ends up at, after we've worked through the other things, I have a LinkedIn profile, packed with testimonials, from managers, former employees, and project partners.
Turns out, I'm actually a really decent human being, and play well with others.
I also worked for decades, for a Japanese company. You won't last long at a Japanese company, if you don't "team" well.
why is this voted down?
He’s obviously wrong.
Most people have various interests and obligations. The number of people who after a day of work in software engineering go on to continue to do that in their free time instead of pursuing other interests is vanishingly small.
Additionally you have people who also just can’t do this, even if they wanted to, due to other obligations.
Obviously there are people who have a very narrow set of interests and leave their office to go to a hacker space but that is such an absurdly small group that it’s ridiculous to even consider them in hiring.
In fact you probably want to avoid having an entire team of people like this in favor of a more diverse group of people.
You are correct. I made a statement that expressed opinion as fact.
It is, however, an advantage that some folks have, and my suggestion is that we should not be required to deliberately hobble ourselves, just because everyone does not have the same advantage.
Of course, a hiring corporation has every right to ignore things like this, and they likely won’t go out of business, as a result. They, may, however, miss talent that could take their business to “the next level,” and risk hiring folks that have become expert at “gaming the system,” and presenting style, over substance.
After my day in software engineering I cannot grind leetcode. Why is it OK to demand people grind leetcode and pass ridiculous circus interviews, but it's not OK to demand they show a personal project they worked on? Both our equally time consuming to pull off.
that’s too bad then. anyone can work on a simple project. how about a simple CRUD app for kitchen recipes?
It is like a cover letter, if you will do half-arsed one it will work against you.
It has to be a good CRUD kitchen recipe app if you want to show it off.
A cover letter won't tell you whether the candidate can get anything done. A small coding project will.
I am not writing anything about small coding project vs cover letter. Tool that I used in my comment is comparison to show common traits of both ... like "white as snow".
Bad - small coding project will show that candidate is a bad coder, even if the code works.
Bad - cover letter will show that candidate has bad grammar, even if person put in the effort.
Good - small coding project will show that candidate can get anything done.
Good - cover letter will show that candidate is willing to put extra effort to get the job.
also, i would rather share code i wrote and go through it than deal with any standardized coding interview. you can derive a lot more from someone’s work than from coding interviews and it is a much fairer process.
On the flip side, an interview where you're doing relevant work with another engineer is a way to evaluate whether you're a decent person to work with. I've hard-passed on candidates with immaculate resumes and huge open source portfolios because they were rude and insufferable. When you're hiring, you're building a team, you're not hiring individuals who work in isolation.
In a previous life, I was forced to work under a very senior engineer who was/is a well-known thought leader with a handful of books published. His leadership was nothing short of abysmal: he had no people skills, answering questions with links to e-books he'd written for O'Reilly in lieu of responses. The best engineers got tired of being micromanaged and nit-picked and left. It doesn't matter how smart you are if the other people at the company hate working with you.
There are many coding interview objectives (and I won't defend interviews which try really hard to ensure you know how to code) but pair programming and systems design questions are absolutely necessary to understand whether the person you're hiring isn't just qualified, but rather the kind of person who will make the team better overall.
But, how are you qualified to make that determination (as in whether a person is decent enough to work with)? Isn't it likely that you either get a skewed impression of this from an interview or that you are biased yourself? The person you reject for lacking decency could be your interviewer in another situation, and reject you for the same reason.
* not trying to imply that there is no objective way to define/measure decency
There's no objective measure of decency. I'm qualified to offer my subjective input while evaluating the candidate because I'll be on the team that has to work with them.
And frankly, I'll happily take the L if the candidate rejects me as the interviewer at another position. I have no right to assert that I'm the best possible candidate for their role because the job at hand isn't strictly about quantitatively measured qualifications. Though, if I rejected a candidate for being unpleasant, chances are I'll withdraw my application upon seeing they're and interviewer. Why would I change my mind about working with that person?
GREAT work!
I can understand why big companies use LC type of questions to assess coding skills of those who graduated recently or didn't enough experience to show their work, but I struggle to understand why many Startups adopted such way of evaluating engineers. I see many startups nowadays asking to candidates to reverse a tree, a task that doesn't reflect the daily work in a startup (where people change gears frequently). I understand that people interview to join the big company, pass a certain bar and then get matched to a team, the startup is too small to not have clarity on what skillset they are looking for.
reversing a tree does not mean you are capable of getting anything done, it just means you bought that shitty book called "cracking the coding interview" and grinded enough of the sort of questions the book covers. besides, you have grinded enough of that stuff in college, if you went to any reasonable quality college anywhere in the world with a CS program.
As an experienced engineer Apple I'm sure that you've noticed a few trends such as.
1) There are those who are unfamiliar with core comp sci concepts, and are still very productive in many kinds of engineering work.
2) It can be difficult for a team that codes frequently and sometimes does need to deal with algorithms and other items to onboard a new team member who's not very good at the act of coding or very familiar with when to use what or how to make something that does one thing do another.
3) Very experienced and skilled people sometimes forget how to do the basics but with a little practice do fine.
4) Those who are experts at the fundamentals tend to learn any new product area relatively quickly, which is a much better approach to hiring than looking for Go + AWS engineers with 20 years of experience ;)
As an interviewer/hiring company hiring many engineers you then have to decide whether you should have a different process for hiring experienced engineers compared to junior engineers or otherwise deal with the awkward circumstance that an experienced candidate maybe isn't just rusty but doesn't have the knowledge or execution ability to code. When hiring an internal transfer it's fairly easy to vet the latter criteria, but when hiring externally it's substantially harder.
1) that is extremely unlikely for any engineer who has produced open source projects or commercial products succesfully
2) again, see 1)
3) they don’t need to remember everything about all algorithms and data structures, just like lawyers don’t remember all details about the law either. that is what books and the internet are for. you just need to know what exists and where to find it, and should have implemented some of it in your career and while in college.
4) i think that that is a typical mistake made by managers and HR. it takes years of work to enter a particular niche and gain experience in it, and it’s unrealistic to think you can just quickly train someone on the job. apple is the example here - most people there are highly specialized in exactly one thing and have long careers related to that.
passing on experienced people because they don’t care about your stupid binary tree trick question or are just tired of going through another leetcode circus act is a costly mistake - there are only a very limited number of highly specialized people available in the market, and it is these people who will make the difference between a “meh” product and something truly incredible.
hiring is broken and will remain so until the coding interview bullshit is replaced with something better.
I also think it's broken in the way you describe, but also find it amazing that it can remain broken for so long given the costs associated with it.
> find it amazing that it can remain broken for so long given the costs associated with it.
For the same reason that hazing has lasted as long as it has.
"I got hazed, so you will, too!"
> 1) There are those who are unfamiliar with core comp sci concepts, and are still very productive in many kinds of engineering work.
That's me! But...wanna see something cool?[0] That's a link to the maintenance manual for my very first engineering project, started in 1986-7 (PDF doc). I wrote it, as well as the project it describes. It contains full source code for the firmware OS, strategic discussions, user guidance, chassis, and electrical diagrams.
My very first project. At the time, I was a high school dropout, with a GED, and some tech training school. I'd never attended one single "core comp sci" class. In fact, I had no idea that "core comp sci" even existed. The engineering team I worked with were all EEs. The firmware team was separate (and a bit arrogant -hard to work with), and my team liked having their own firmware geek, who was quite grateful, for being given the chance.
Not too shabby.
> 2) It can be difficult for a team that codes frequently and sometimes does need to deal with algorithms and other items to onboard a new team member who's not very good at the act of coding or very familiar with when to use what or how to make something that does one thing do another.
I code every single day. How's that work out for you? In my experience, others have a hard time, keeping up with me.
> 3) Very experienced and skilled people sometimes forget how to do the basics but with a little practice do fine.
Define "the basics."
If you mean LeetCode school curriculum algorithms, then, guilty as charged. Also, guilty of not being particularly interested in "a little practice." These represent things that I have seldom encountered, In Real Life. I won't bother wasting time practicing them, if the only place they have utility, is in a conference room that I'll never enter.
If you mean "the basic structure of iOS applications," "device I/O concepts," "Shipping to the App Store," or "idiomatic Swift," then, you're in luck! Since these inform the work that I do every single day, I happen to be pretty up on them. No practice necessary.
Although, TBPH, I frequently google even the most basic stuff. This will continue for the rest of my life. If you can't deal with that, then we're better off not interacting with each other. I forget stuff, all the time. I google it.
This Internets Tubes thing is the pants!
> 4) Those who are experts at the fundamentals tend to learn any new product area relatively quickly
People who solve difficult problems -every single day- can also be pretty fast on the uptake.
Just sayin'...
[0] https://littlegreenviper.com/TF30194/TF30194-Manual-1987.pdf
I'm in the same boat. Fortunate to have worked at startups that exited succefully and now in cushy corporate job. If I went out and did interviews I would just make enemies.
> All job interview processes are flawed. They're just flawed in different ways, and some of those flaws work to your advantage and some don't.
Ways in which the flaws of interview process have helped me:
* I'm very good at "conversational" interviews. I have battle scars from years in industry. Higher-ups at companies want to hear about that, and they make me strong offers. But technically, I could completely suck at my job and the discussion could sound exactly the same.
* Most of my money is stock growth from my initial packages. No way I would have this $$$ from bonuses.
* My title-bump came during hiring, not promotion.
It's also frustrating for job mobility, as you need to move jobs (or at least have offers) to get employers to pay your market rate. But in order to get offers you need to basically start a part time job studying and interviewing. If you just interview with a company you want to work for with no competing offers you will get lowballed - you might also just get rejected because companies prefer high-false positive rates and most interviewers do not get any sort of continual training, feedback, calibration or standardization. It's also unfortunately standard that your compensation doesn't keep up with your market value as companies would rather hire-in than promote internally.
why spend 3 months full time studying when you can spend one month full time writing code for a product you can talk about in the interview?
Many companies will reject you unless you an also pass the coding interview and that will generally require studying.
good luck to them
Max Howell's tweet gets pasted on every article talking about code interviews as some kind of exemplification of the problem of whiteboard/algorithmic interviews.
What some people might not know is that he reflected on that tweet two years later (3 years ago), in this Quora question: https://www.quora.com/Whats-the-logic-behind-Google-rejectin...
He even explains how he actually did well in the software engineering interviews in the process.
The tweet comes up every so often, but it has two problems:
(1) Most of Google's engineers didn't even know Homebrew - it just wasn't something Google used on its notebooks.
(2) There's no such thing as "inverting a binary tree." At least I haven't heard about it anywhere else.
Maybe Google's interview process is broken, but the tweet isn't really explaining much. It's just a nice soundbite.
Reversing a binary tree is a real question that gets asked in interviews: https://leetcode.com/problems/invert-binary-tree/
It’s actually pretty easy if you’re comfortable with recursion and traversing trees. The tree questions Google asks in its interviews are usually much harder- it implies they were giving softball questions to him.
Knowing Homebrew could have given them reasons not to hire him. He made bad engineering decisions and brushed off feedback. And even he said he's a dick.
sounds like what google does with their analytics and google drive products
“He actually did well” - how would he know that? He also wasn’t hired.
It's possible they told him but given that he admits he didn't know what a binary tree is it seems unlikely he did well at a Google coding interview, where I assume 90% of people know.
> But ultimately, should Google have hired me? Yes, absolutely yes. I am often a dick, I am often difficult, I often don’t know computer science, but. BUT. I make really good things, maybe they aren't perfect, but people really like them. Surely, surely Google could have used that.
Hmm so he fully admits that he made a bad package manager and is often a difficult dick. He sounds pretty arrogant too. I wouldn't have hired him.
And yes it is bad (try installing an old version of something). Just because it is popular doesn't mean it is good. It only ever had one competitor (ports) and that wasn't really Mac focused.
It's of no interest to Google that something bad you made happened to become popular. It's not like you can repeat that on demand.
Would you hire the person that wrote Bash? Or YAML?
MacPorts is Mac focused. People liked Homebrew because it didn't take lots of time compiling its own copies of libraries the OS had already. But MacPorts got binary packages. And Homebrew gave up using OS libraries.
I would hire Brian Fox, if I could afford him.
We can't know, but
> I am often a dick, I am often difficult
If that came out during interview, it could easily have sunk their packet
Perhaps he felt he knew it to the extent that the problems posed weren't completely foreign to him and he felt his solutions were reasonable which was possibly corroborated through either subtle bodily cues of the interviewers or direct verbal confirmation.
>My task is far more life-like,
That's debatable. I've never had to implement a from YAML task execution system for work. I've used them a lot but that's a very different task than writing one. In fact given how many exist writing one seems very much a bad case of NIH syndrome.
I suspect this article is satire
Agree that 99% of the leetcode interviews are divorced from everyday coding work.
However, this article goes in the wrong direction in trying to keep the LinkedList premise - how often do programmers see a raw linkedlist anyways?
Directly ask coding questions from your everyday work, and skip the linkedlist stuff as 3rd level detail questions; the signal that the candidate can do the job is much higher then. Ex: here’s an API and it’s json response: write some code to parse it. Add extensions like paging, network failures, etc. Let the candidate google everything, and if your question is good, it can’t be copypasta from StackOverflow.
that sounds like a takehome and should be paid for.
It’s possible to structure the question to fit 30-45min. It’ll be pretty clear what level and experience a person has in doing api’s. If the json response is already laid out, parsing json can be an independent task from the network call. The point of the interview is to see if the person can reasonably code it, it doesn’t have to be production grade.
DOING api’s, what does that mean?
leetcode interviews do not test if a person can reasonably code. they expect people to give a specific optimal solution to a specific question which you can only provide if you have solved the question before, in the way it is expected, within max 2-3 minutes. the process is broken.
the moment you ask a candidate to build something you could use in your codebase you should pay them.
> It is increasingly common to use this kind of “pipeline-as-YAML”
> configuration to piece together a workflow of pre-built
> components 1. Some real examples of this are TFX components,
> scikit-learn Pipelines, or Airflow DAGs.
There's add-ons that let you define them in yaml. Which I find hilarious since one of the original selling points of Airflow was that the Dags aren't in XML.
I took Adam’s point here to be that an Airflow DAG author primarily concerns themselves with the configuration of those objects, since the underlying components (Celery worker, Python execution process or K8s pod; data warehouse; RPC) have been abstracted in the form of Operators.
> There are a few questions that people like to use as punching bags. Invert a binary tree. Reverse a linked list. Perform breadth-first and/or depth-first tree traversals. Anything to do with heaps.
None of these are hard. Should be pretty much covered by any good algorithm class.
The problem is that however distasteful or lacking the current situation is, it’s been adopted by most large companies and is seen as standard now so nobody has any incentive to improve it and it self perpetuates akin to hazing rituals at fraternities . Google got us into the current mess with their claim to have found the only difference between good performance and bad performance at Google was the ability to do algorithmic problems. If only they published that research! Before Google was Microsoft. The only thing that would incentivize employers to change now would be engineers refusing these interviews en masse or a small company becoming an influentially big one that has a different hiring scheme altogether.
it's just a matter of time before the workforce will be replaced by shitty engineers who all grinded leetcode and are good at that but are not capable of actually creating anything good on the job. eventually, FAANG will realize they have a problem on their hands and fire everyone and hire experienced people who have no interest in leetcode, and the cycle starts over.
they don't need research, they had that person who became part of the hiring committee overnight and who sold them all on the magic leetcode formula and they bought it.
As a data scientist, I regularly get asked at least a subset of questions that are more suited for real software engineers. Very few interviewers get around to asking relevant things (for me/my job).
My day-to-day is messing around with pandas and matplotlib, mostly, but I never get interviewed on that. It's usually brainteasers, time complexity of some algorithm, and an invariably-rigged machine learning thing I can never get right.
That may be because I'm young, but the idea of studying for a few months and get a salary that's triple of what I currently make, or double of what starts to be the high barrier in my country (France) is extremely appealing to me. I understand that I may not feel the same way in 10, 20, 30 years but until then it's a golden opportunity.
> a decent evaluation of junior engineers without industry experience, but it’s a common complaint among senior engineers that they have to study material that they haven’t used in years to get a job where they won’t use it.
Counterpoint: some engineers with industry experience may have been working on very specific tech that doesn't readily translate to a new position. Actually, I'm sure some companies wouldn't even consider them for that reason.
Big companies need some standardized way of interviewing people if they want to maintain some level of fairness. At least, algorithms and data-structures provide a common denominator.
No. Senior engineers are expected to have different level of skills - project management, leadership, and ability to identify problems that matter, rather than blinding solving problems that are given to them. You're also not going to be able to test their ability to learn by giving tests.
I'm sure most of us would fail high-school trigonometry (or spelling and grammar for that matter) if given one.
> I'm sure most of us would fail high-school trigonometry (or spelling and grammar for that matter) if given one.
Not if we had a few weeks of prep time.
Doesn't it seem like an absurd scenario to you though, that you need to prep for an interview by relearning skills that aren't relevant to the job you're interviewing for?
I've been in coding interviews that matched the work that the company is doing, and I've found those useful - I get something from taking the interview (an idea of what their codebase is like, working with a partner, maybe some interesting code design questions), but I'm never going to do another "code this CS algorithim that 100% of people use a library for nowadays" type questions.
It is absurd, but is so easy to counteract by just prepping. I’d be a lot more negative about it if it wasn’t so easy to game.
I think this is the point - that it's so easy to game (albeit a waste of time) and that this doesn't reflect on the quality of the hire coming through this process. Assuming this is the test for senior engineer, the greatest candidacy pool would be second-year CS students.
True, but I guess they are also judging our pliability in jumping through hoops, because even us senior engineers have to jump through many. To be honest, I'm probably not jumping through enough of them, cramming for a coding interview is one thing, but jumping in on every welcome!/goodbye! email is something that I really wasn't ready for.
Then it’s no longer a skills test but an aptitude test. That’s fine if we’re all happy to call it that.
But I'm not going to take a few weeks of prep time to prepare for a high-school trig test, either. I have no reason to waste my time in that way.
And I have no reason to waste my time spending a few weeks prepping for a code interview, either. I am who I am. Either you want that, or you don't. I'm not going to try to spend weeks studying so I can pretend to be different than I am.
(Disclaimer: I'm not looking, and I haven't been for a very long time. I've never been desperate while looking. I haven't even been unemployed while looking in over 30 years. If I were unemployed and watching the bills pile up, I might feel a whole lot less smug...)
If the trig test was in the way of a $200k/year job I didn’t have yet, I would totally hit the books.
> I have no reason to waste my time in that way.
Preparing for interviews isn't wasted time provided you have some chance of success. The signing bonus alone can be worth the time.
you mean 3 months and then going through 30 cycles of 10 hours each?
I think it's worthwhile looking at what you're going to accomplish out of an interview. For systems design type stuff, I think it's reasonable to always ask, since it's useful to know how someone approaches problems, and it's not necessarily a given that someone would have needed to deal with architectural / design questions regardless of seniority level.
If you're hiring for a senior position though, and the purpose of your question is "can this person code?", you should be able to get enough evidence from their resume / github / references. If you genuinely can't, then I'd question why you're interviewing them for a senior position in the first place. Strict adherence to standardization leads to absurd scenarios like giving basic "can you code" interviews to the authour of Homebrew like the article states.
> you should be able to get enough evidence from their resume / github / references
The problem is when you get 1000s of such resumes, but only a few positions to fill. Also, not everybody has time to spent on github projects. It can be even more time consuming to work on personal projects than brushing up your algorithmic skills. Not saying these interviews are perfect, but I do believe that they are a good solution for a very big company.
Talking about system design interviews, I had the feeling that they were less useful than algorithm interviews, especially for a senior SWE. You can nail them with only theoretical knowledge, even though you've never worked on the systems they ask you to design.
if I spend 3 months full time building a product, I have something of value, guaranteed. If I spend 3 months on interview prep, then I still have to start going through the cycles, and it will take another 3 months before I might have a job. No guarantees. Anyone can build something in a month, so the idea you have no time to build a side project is just BS. Especially if you can spend months grinding leetcode.
It's a gamble. Most companies don't bother to look at Github page, at least in my experience. On the other hand, the skills you build grinding leetcode can get you a good job (and the next ones).
grinding leetcode guarantees nothing. I does not guarantee you will get a job now, and it won't in the future when you go looking for your next job. Looking back at my recent experience I don't see how it made any sense for me to spend my time on that.
I went through several cycles and did excellent on the SD interviews because of my experience. But none of that stuff mattered, it was all about answering some trick coding questions that were irrelevant for the job. So it seems that all the important stuff like experience is much less important than leetcode.
> Counterpoint: some engineers with industry experience may have been working on very specific tech that doesn't readily translate to a new position.
Some