So... smart and gets things done. Honestly that's all I look for on a resume. You also have to talk about it in an interview.
I couldn't care less if you can invert a binary tree. One of the greatest developers I've ever worked with, I hired straight out of college. He graduated with an electrical engineering degree but his senior year he took a course in Java and liked it and decided to be a programmer. Couldn't tell me the first thing about programming but I could tell he had the chops to figure things out and that he had a passion for things getting done.
The trouble is, this "je ne sais quoi" that you speak of, that you "could tell he had the chops to figure things out", is unquantifiable and almost totally subjective. To be a bit blunt and cynical, this way of evaluating candidates basically boils down to, "do I like this candidate?" Your criteria for liking someone happens to be that you look for these nebulous "chops for figuring things out". What about the other interviewers at your company? What kind of stuff would they like? Would they evaluate "chops" the same way you do?
Or, just imagine that you're interviewing a hypothetically equivalent candidate who also had the same drive and "chops to figure things out", but who happened to be less fluent in conversational English. Are you so sure that you'd be able to pick up on the same underlying "signal" about their chops, if it was obscured by some language fluency noise?
Hiring is a Hard Problem, and there's a big gap between well-intentioned intuition and translating that into robust processes.
Exactly, it's so sad hearing someone not realize that their hiring process is basically discriminatory in nature. Can you tell someone had the chops to figure things out if they came from a different cultural background than one you're familiar with? If they had a different social upbringing from yours? If they presented themselves in a way that you personally misunderstood but someone else would have been completely comfortable with?
Of course not, OP basically hired someone he got along with, and that's fine on a small scale, but it's not something to pride oneself over.
A better approach in my opinion is if you find someone who you get along with, you think they have that kind of fire and passion you're looking for, but they don't know the basics and fundamentals of computer science nor are they familiar with data structures and algorithms, you advise them that if they want to make the most of their potential then they should take some minimal amount of time to really devote themselves to understanding those aspects and then they can reapply for the position at a later date. You can keep in touch with them, even potentially mentor them if you really think they are worth it, but you don't just give someone a pass.
Letting someone get by without that knowledge because you like them doesn't really do anyone any favors.
> Exactly, it's so sad hearing someone not realize that their hiring process is basically discriminatory in nature.
I've come to the sad conclusion that this is a fundamental tension.
Ignoring the pre-interview filtering, our industry has, on one end of the spectrum, a relatively nondiscriminatory process that assumes basically nothing and tests you on as much of the field as they can before hiring. It's nondiscriminatory in that it doesn't matter where you come from as long as you can solve the same structured problems as everyone else. This is the whiteboard interview everyone hates, and it's not all that inclusive.
On the other end of the spectrum, we have the fuzzy 'does this person seem like they could become capable quickly and work well with me' process. It's inclusive in that it doesn't require you to be able to solve those stupid problems yet, just be bright enough and hard working enough to learn. But it's not at all unbiased.
So do you go for unbiased and give people the same standardized questions, or go for inclusive and have a real conversation? I've found the best people come from the latter process, but I would say that, right? I'm biased.
I agree there is tension and it's imperfect and I don't think one needs to go to one extreme or another... but GP literally said that they hired someone who didn't know "the first thing about programming" who took a single course on Java programming and just hired that person because they had the "chops and passion".
That is what I am criticizing as not being helpful. If someone has the chops and passion for a job, they have the chops and passion to learn a few data structures and algorithms before interviewing for said job. Let them know it, keep in touch with them, and have them come back after they can tackle a proper technical interview.
>I've found the best people come from the latter process, but I would say that, right? I'm biased.
Right and that's a valid observation and there's nothing wrong with that bias per say. On the other hand I've found the opposite, the best software developers I currently have the pleasure of working with know their fundamental data structures and algorithms and have no trouble explaining deeply technical topics with rigor and precision, so that's what I hire for.
It was a fresh college graduate, I don't expect them to know shit about software development honestly. What I do expect is for them to work hard and show passion for what they're doing and the learning process. I expect to see prior experience of self-motivation and hard work which is easily teased out in the interview process.
This person became one of those legendary developers that could do the work of 3 without breaking a sweat. I interviewed tons of people from the same university with actual CS degrees and knowledge of data structures and algorithms. I actually hired lots of them and only a few were as competent as this person was. Your degrees and knowledge of a few data structures and algorithms mean nothing if you're lazy and don't show passion for what you're doing.
That’s just confirmation bias on your part, my dude. You’re kinda glossing over the fact you took a chance and it worked out. How many times did you take chances like this on people? Probably not a lot.
You likely hired the other folks not because they were passionate or had some quality you looked for in the other candidate but because they were clearly apt and able to do the job.
I’d also say that there are many people out there that are incredibly intelligent, hardworking, knowledgeable, and just don’t give a single fuck about any business they work for. Most of my peers put me in that group. Don’t be bitter with us - we don’t find the shit challenging or appealing. A lot of us spent years in college grinding at rigorous academics and came out jaded. There’s relatively little left to learn compared to a starry eyed kid who took a single course, barely knows shit as you said, and is being given a once in a lifetime opportunity.
Kid will leave and likely be jaded like the rest. It happens. Mentally, software is a horrible career.
> Exactly, it's so sad hearing someone not realize that their hiring process is basically discriminatory in nature.
Leetcode and take-home assignments, to some degree, filter for younger people. I don't think too many people are going to solve two Leetcode hard questions in 45 minutes without some practice. I suspect this is a feature, not a bug, but I will take off my tinfoil hat now.
Whether or not you like it, people want to work with people they think they will get along with. Someone can crush objective screens but maybe they come off as arrogant or potentially difficult to work with.
"Exactly, it's so sad hearing someone not realize that their hiring process is basically discriminatory in nature."
Yep. I've seen this so much in my company for performance review. It's completely subjective and managers dont even realize when they are discriminating or violating company policies (or laws!).
> Hiring is a Hard Problem, and there's a big gap between well-intentioned intuition and translating that into robust processes.
Ultimately, hiring is INTRINSICALLY a subjective process. If it were quantifiable and one could reliably screen based on "objective" criteria, it would have been a solved problem by now and employers could hire "robustly". But it is not and it never will be that way.
That said, hiring and assessing talent takes practice and there are some techniques that work better than others. In particular, behavioral techniques are extremely valuable and sadly often take a back seat to persnickety homework quiz questions. It takes some skill and practice to get good at behavioral interviews (for both parties). But when it's used properly, the candidate has a chance to actually demonstrate "chops" even though they may lack some of the job requirements.
Your argument presupposes that an objective criteria is optimal. It's trivial to refute that, for example a company could hire people based on whether they are greater than 6 ft tall, that's an objective criteria but it would still be terrible.
Objective doesn't mean "good/optimal/solved" and subjective doesn't mean "bad/suboptimal/unsolved". All subjective/objective refer to is how sensitive a property is to a specific context. An objective measure is not particularly context sensitive whereas a subjective measure is.
My company has both objective and subjective criteria. Competency is mostly measured objectively and represents the bulk of our hiring criteria, the subjective assessment involves things like communication, collaboration and professionalism.
Both aspects are difficult and imperfect to assess regardless of whether they are objective or subjective, but I don't think it's particularly appropriate to assess someone's competency based on a subjective measure.
If someone is a good basketball player, or a good plumber etc... they are likely good regardless of the intricacies of the individual making the assessment that day and hence it's something that is probably best measured objectively. However, whether someone will get along with the rest of the basketball team, or whether a plumber can properly communicate to a customer what the issue is and how to fix it, that may very well depend on what team that player is playing for, or the relationship between that specific plumber and the specific customer. That would be more of a subjective criteria.
There certainly are subjective aspects to competency as well as objective aspects to communication, but it's minor (perhaps a basketball player is good only on a specific team, perhaps a plumber is illiterate).
Thanks, but I don't need the explanation about the difference and nature of objectivity and subjectivity and don't need to be told that it's not a value or worthiness dichotomy. Admittedly, the HN crowd clearly heavily favor what they think is objectivity, so it's easy to assume everyone thinks like that on here!
I do think we sort-of agree that BOTH subjective and objective measures need assessment and they're both difficult to measure.
The purpose of the explanation is to point out the flaw in your argument that if hiring was purely quantitative and objective then it would be a solved problem. To quote you:
"If it were quantifiable and one could reliably screen based on "objective" criteria, it would have been a solved problem by now"
Given that was the premise of your entire argument, once that flaw is exposed the rest of your argument falls apart.
There is something to be said about the value of human intuition, though. While it may be fallible, part of what makes hiring a hard problem is that many of the things that distinguish good candidates just aren’t objectively measurable.
> There is something to be said about the value of human intuition,
IMO, the something to be said about it is that people have a good intuition about people who remind them of their family, friends, and celebrities they admire; and a bad intuition about people who don't, and remind them of people seen as criminals or bad guys.
This mysterious robust process that can deterministically fit humans into the "hire" and "no hire" box doesn't exist. Everything you can describe that's negative about human intuition, I can use to describe whatever robust process you can think of.
I want candidates to succeed -- I always start out rooting for them. The interview is not a place to beat people down but it give them opportunities to show their strengths.
What does your intuition say is a good way to approach hiring? Does it maybe tell you to figure out relevant skills and ask the candidate about those? Yet if you ignore that voice, you end up timing how long it takes them to invert binary trees from memory instead
Everybody on earth who is good at what they do relies utterly on their carefully trained intuition
I hired a lot of very good developers, so I was able to rely on my intuition pretty well.
Then one time I hired an excellent candidate, technically very strong. Then it turned out he couldn't figure things out on his own. I had a co-interviewer who also thought he was very strong. In the end we had to fire him after a month since he couldn't pick up the pace (his colleague who started at the same time is actually very good)
I was "very good at hiring", until I hired the wrong person. Even now it's hard for me to tell what actually went wrong there. It was mostly theory and understanding underlying concepts, but now I definitely mix in a lot of practical issues and examples. Sometimes I think we interviewed his twin brother who could actually program ;).
Hiring developers is indeed very difficult. You can only tell when working with them for a few weeks.
I've been responsible for hiring for most of the last 20 years. I've literally never had a false positive where I recommended someone and they performed poorly. I have had one case where I said no, was overruled, and then the person turned out to be awful. To be fair, I have no idea how many false negatives I've had where I said no but they would've been great.
I'm always puzzled by people/companies who find this difficult. I don't believe for a second that my intuition is magical. I have a very simple interview process and it works really well. I just ask you what you did, and then I keep asking you increasingly more complex or detailed questions about what you said you did until one of us hits our boundary of knowledge. Then I ask a couple of social questions, usually in the form of "Have you ever dealt with x kind of situation?"
Funny anecdote, I asked one guy if he'd ever had a coworker he had personal issues with. He told me some guy made a racist comment and his response was to ask the guy to step outside to fight. We did not hire that guy.
I always thought a huge blind spot in hiring is that nobody counts or worries about false negatives: Those people who you said "no" to but would have turned out to be great. False positives are often, but not always, easy to spot, and you can know and feel regret about how many hires turned out to be low performers. But it's hard to know or feel regret about the people you turn away. I mean, how would you even track this or correct it? Keep track of everyone you interview, then look at their career 10yrs in the future? Flag people as "no, but maybe we're wrong" in the HR system and then wait for them to re-apply?
As an interviewer, I sometimes wonder if I made the right "No Hire" call on that person who might just have been nervous. As a candidate, I always know that when they say "NO" they're wrong :)
I never worry about this. I usually have some idea of what I am looking for: junior, senior, architect. I just want to find someone suitable in an efficient manner. There's tons of solid candidates out there, it's not my responsibility to make sure the ones who get too nervous to communicate during an interview are taken care of.
oh no doubt, getting around implicit bias and all that is hard and is training I've been through and try not to let get in the way. I've interviewed hundreds of people over the course of my career and I've had the greatest success in evaluating the soft skills of an engineer rather than their stated resume skills. For experienced engineers, I still ask technical questions to make sure they're not BSing their way in and have some knowledge of development. But college grads I really want someone with those soft skills.
Yes, it is slightly subjective, but not unquantifiable. You have to have shown me times you've done those things, not just say them.
I just came of a call with a a potential hire. I recommended her to a second round because of three things:
* She would culturally fit while still bringing something new to the tam
* She doesn't know Web Analytics, but has done market research, built html prototypes and has basic knowledge in JS, python, html, SPSS and some other things
* She is self motivated and shows this because she actually learned all these skills in her last job because she wanted to and it made her job more easy.
I strongly believe she would learn the technical ins and outs of Google Analytics or Adobe Analytics quite fast. The rest is not important.
I don't care that she has not worked with AA oder GA. If it were my decision I would have hired her on the spot.
The self-motivation aspect you mentioned is also critical. It's these soft questions that reveal so much about a person's character that speak to me as much as or sometimes greater than certifications or degrees do.
It's also why resume screening done by HR drones or worse, AI, are so problematic. Unless I need someone to do an exact thing extremely fast, I'd much prefer a generalist with a sharp mind, proven "gets shit done" attitude and experience, and is motivated to do the right thing.
But "cultural fit" is still necessary but must be defined carefully. If a company doesn't care about culture fit when hiring people, it will become a very bad place to work.
Questions to address when determining cultural fit:
- How does this person resolve conflict with peers? With managers?
- How does this person advocate for change in the workplace?
- Does this person share credit, and praise others?
- How does this person take responsibility when something bad happens?
- How does this person respond to something they heard but don't quite understand? Do they pretend to understand and go on, or stop and clarify at the risk of sounding unknowledgeable?
Questions that sometimes get confused for cultural fit:
- Does this person watch the same television shows as me?
- Will this person understand the same cultural in-jokes as me?
- Did this person go to the same college as me?
- Did this person have a similar life journey as me (religion, or where they grew up, etc)?
What you described is what used to be (still is?) called “soft skills”. This is not, from my experience, what people understand by “cultural fit”. At least in NYC it really meant exactly all that you mentioned on your second list.
> How does this person respond to something they heard but don't quite understand? Do they pretend to understand and go on, or stop and clarify at the risk of sounding unknowledgeable?
This. I would additionally also say, how does this person react when shown they misunderstood/misinterpreted something. How do they deal with being wrong about something.
With cultural fit I meant that she needs to fit into our diverse team. She should probably not have biases against people coming from different and diverse backgrounds.
She needs to be able to work in a collaborative team setup within our core team as well as be able to integrate into project teams with even more diverse people.
Someone who shows that they would not play well in this team sport while also being self sufficient when necessary would not be a cultural fit in our org.
I dann don't care about the color, gender, age or educational background. On the contrary I enjoy the multibackground people around me. It is inspiring.
Frankly I’m not surprised at all that a plumber that is an effective troubleshooter could port that skill to the digital realm in a short period. Being an adept troubleshooter is pretty much the top requirement for the trade (that and a strong resistance to malodorous work environments).
I’d have been much more impressed and surprised to read an article profiling a programmer that became an effective plumber in the same amount of time.
Yep, I’m saying it—y’all just ain’t as smart as the plumbers out there…and most of you are kind of…”soft” in the physical department and probably would run screaming from the physical demands of the gig.
(I am including myself in the negative assessment above)
So by your reckoning, old people with families and a life outside of work are... stupid and don't do anything? Are you serious? Being smart and showing you have great motivation to get things done in NO WAY relates to how old you are, if you have a family, or a life outside of work.
Most places I've seen want people to work extra hours consistently. Or at a bare minimum reward people working extra to the detriment of those working the normal hours.
For example, Bob works 8 hours per day and completes 80 units of work but Steve works 10 hours per day and completes 90 units of work. If you get enough 'Steves' in the organization then the remaining 'Bobs' look like slackers. If you can't work 10 hours per day because you have a family, then it puts you at a disadvantage. I've seen it happen. I was told that if I wanted a 7% raise/promotion that I needed to increase my working hours by 13%. Why would I take a rate cut for a position with more expectations and longer hours? My conclusion is that many managers do not think, or that they like to play dumb.
Sorry you've had that experience. Most places I've worked at, actually -every place- I've worked at, has rewarded me for doing the job and doing it well. Do I occasionally work a few hours extra here and there? Sure, but that's the exception not the rule. I'm mid-40s and have kids and a life outside of work. I don't do extra unless I'm self-motivated to do it or it's a rare requirement from the boss to get something done.
if you had read the article the guy worked 11 hour days and then came home and learned to program.
>As a commercial and residential plumber in metro Atlanta, he pulled 11-hour days working some of the dirtiest, stinkiest problems in the country.
from third paragraph.
later on
>Over the weeks that followed, Daniel forced himself to sit down at his computer after those 11-hour days. He grappled with Python and Javascript in the back of his work truck. One minute he was wrangling sewer pipelines - the next minute, CI/CD pipelines.
as it is past the edit window I suppose I will just note that the above was in reference to the quote from the article
>Over the weeks that followed, Daniel forced himself to sit down at his computer after those 11-hour days. He grappled with Python and Javascript in the back of his work truck. One minute he was wrangling sewer pipelines - the next minute, CI/CD pipelines.
so the guy was able to work 11 hour days and learn to program, two programming languages, to take part in this contest, and his code was evidently solid as well so - I have to assume he did at least 4 hours a day after the 11 hour work days, and then of course the weekends.
Evidently people thought I meant that only young people can be smart and get things done, which I can only think that misunderstanding arose from not having read the article. Because even if I agreed that smart and gets things done was the answer if someone pointed out young and has no family I would immediately think oh yeah, he was definitely pulling some 15 hour days there without distractions.
It’s come full circle. I’ve often heard people (working developers) say over the years that software engineers are basically just digital plumbers. And the job often feels that way. Now we have proof that the skills do in fact overlap quite a bit with plumbing.
My old boss (web development) said in 2003ish that "we're just plumbers" and at the time (I was young) it offended me as I thought as "technologists" we were "special". When I went out on my own, I realized he was right.
If I had to pick one essential profession it would be farmers. Even with peak efficiency it's work that must be done to sustain modern population sizes.
I had this realization over last one year, after 17 years of professional life.
Most of my work these days involves plumbing together right libraries and data pipelines to automate business processes. Sometimes I need to fix an existing plumbing to plug a leak here and there.
IIRC the meaning of that was specifically someone that was willing to bodge things in order to ship - someone that prioritised getting it done over getting it "done right" (whatever that means). I think it's a little different from the "plumber" label.
FWIW I like both terms. I just wouldn't use them interchangeably. :)
It’s a small sample size, but highly motivated self taught folks who come from tough blue collar careers that I’ve seen have been pretty reliable and committed.
I presume it’s a lot easier to appreciate the working conditions and compensation package, as well as tolerate the political dramas, when you have some perspective on how life is for most other people.
For sure. My summer jobs were in restaurants and factories. It deeply shaped my notion of what work is. It's been a long time, and I'm still excited I get to work from my house basically solving puzzles.
It has downsides, though. One thing you learn in blue-collar businesses is that the direct work is primary, with other stuff secondary. In a restaurant, nobody shuts down during the lunch rush to talk with everybody. In a factory, everybody understands that the machines keep going; any administration is done very much on the margins.
So it's maddening to me that in most office contexts, my schedule fills up with meetings and I'm expected to get my work done around them. And that nobody sees that as a problem, because that's just office culture.
Oh wow. Thanks for the distinction. This cleared up something for me that was knocking in the back of my mind.
I had the same feeling having had a lot of blue collar jobs while studying. Discussions/management was scheduled around getting work done.
I was working as a cook once and the real chef (I was studying literature and history at that time) and I were doing reviews of the evening after the kitchen was closed, cleaned and we were sitting at the bar drinking our one final drink of the evening. It was a little bit like a sprint review with the sprint being just an evening long. Sprint planning so to speak happened before guests arrived and the restaurant opened.
We prepared the kitchen, chopped stuff for salads, prepared sauces and stuff and were discussing who would do what when the rush started. So even without knowing the actual ordering of dishes and the amount of every specific dish we roughly knew what to expect (how many orders aka tickets we would have in the sprint/evening).
So we had a sprint planning, a sprint and a (internal) review. And our service people would give us feedback on what went well and what went wrong also, because they had the direct guest feedback.
Yes, absolutely. When the work is visible and straightforward, it's so much easier to understand and optimize what's going on.
That's part of why I'm a big fan of kanban boards for work. If you make our pretty abstract work visible, you enlist people's natural intuitions. Especially when there's the habit of regular reflection.
Of course, that takes a culture that supports it. It sounds like you had a really good place to work!
> So it's maddening to me that in most office contexts, my schedule fills up with meetings and I'm expected to get my work done around them. And that nobody sees that as a problem, because that's just office culture.
Block out portions of your calendar with recurring work time, and let them schedule their meetings around that.
Recently I went through a phone screen by a gentleman I imagine to be in his 50s or 60s and it was an immensely pleasant experience. No gotcha questions and any time I mentioned how his problem reminded me of so-and-so tech he would gush in excitement that he also worked in that tech
Compare to a recent interview with the world's best employer (tm): the interviewer was young, was upset that my solution wasn't written in Java (???), and when I described my experience I talked about dashboards and he didn't know what that was. I described it as charts and he didn't know what that was. I described it as graphs and he also didn't know what that was. The interviewer had a bit of an accent so maybe it was a language issue but I had never run into someone who hasn't heard of a chart!
> I described it as charts and he didn't know what that was. I described it as graphs and he also didn't know what that was. The interviewer had a bit of an accent so maybe it was a language issue but I had never run into someone who hasn't heard of a chart!
It’s at this point that I would end the interview and let them know it doesn’t feel like it would be a good fit.
I think the issue is that the interviewee doesn't always know what is on the "test". It is also a waste of everyone's time. If a company's only data store is SQL of some kind, which do you want: Someone who can barely do joins but has memorized red/black tree function implementations in several languages or some one who knows SQL at a production level and if they had to do something with red/black trees would just have to spend a day or two re-reading how they work? I think the thing this underscores is that we really need an association like the "bar". So you can go study all the things on the test and prove you have the knowledge and ability and then skip that as part of hiring and just focus on experience. The only thing we have today is tech company specific certification which is okay for certain things but not for more general software needs.
Inverting a binary tree is not hard. That people keep using this as a joke is more a testament to the stubbornness of people believing they shouldn't have to do no learnin' no more than it is bad interviewing practices.
Expecting engineers to develop skills they don't learn/use in their actual professions to prove they're capable of working a job makes no sense. If these leetcode puzzles were actually relevant, why do so many engineers have to spend time outside of work "grinding" in order to get better at them?
> Expecting engineers to develop skills they don’t learn/use in their actual professions to prove they’re capable of working a job makes no sense.
I used to feel this way, but I think I’ve changed my mind. Interviews aren’t really primarily testing for skills you’ll use day to day, they’re testing for breadth of skills and knowledge and more importantly breadth of understanding. When I’m interviewing, knowing if the candidate has the specific skills for the job is the bare minimum needed to get in the door. I’m really more interested in potential, how much they can grow, and indicators of growth potential include how interested they are in the art of programming in it’s many different forms, whether it’s algorithms or math or software architecture, or coordinating people who write software. Puzzles are only the tiniest fraction of all that, but they’re still a signal that you like thinking about algorithms, and have exposure to different ways to write code and lots of algorithmic concepts.
A university CS degree isn’t particularly good at teaching job skills per se either, there isn’t much I use in my job day to day that I practiced in school, at a superficial level. But the school degree is pretty good at covering the broad concepts of computer science, and that has lasting value over the course of a software career.
How do these questions give you any indication that the candidate can do the essential job functions of shipping working code that is actually useful to your business and being a good teammate?
That question is impossible to answer. However, the negation is answerable. "Is the candidate incapable of the essential job function?" Questions like fizz-buzz, et. al. answer that readily.
Put up a job posting on a job board and you'll get hundreds of applications. 90% of those you're going to throw out because the resume doesn't match the job description at all. What does that tell you about the candidate pool? It's an all out assault of candidate spam. You have to employ these sorts of basic filters to even get the number of interviews you do down to a managable number.
What it tells you about the candidate pool may be less than what it tells you about the qualifications for the position. Job requirements in the computer industry routinely include nonsensical requirements (5 years experience in something that's been around 3 years, 2 years experience in each of 8 items for an entry level position, etc.)
This is endemic to the point where applying only for jobs where you fit the job description is a losing strategy.
And even if your own job posting isn't one of those, how is the applicant supposed to know you're one of the few employers who actually means what's in the job description?
This is a good question. However, there is nothing that will tell you this reliably aside from employing the person.
Most people who are smart and get things done will be capable of shipping code, if they can stay motivated. And that’s where having some signal about their interest can help. I want to know if people can inspire their teammates, not just get along, I want to know if they can lead by example, whether they’ll rise quickly, and whether they’ll love it for many years. The essential job functions are just plumbing, the important parts are more than that and aren’t demonstrated by evaluating for narrow, specific job skills.
Look, I don’t in a million years think grinding on Leetcode is some singular answer, or even particularly good. But I don’t see anything wrong with people who are interested doing it, and I also don’t see anything wrong with asking interview questions. I never put a huge weight on such algorithm questions, and there are a dozen other major interview categories. So there’s nothing wrong with asking a few algorithm theory questions, to see the bounds of what people know. I like getting into questions that people don’t know the answer to, whether it opens a conversation about what it means, or whether the candidate has no idea or doesn’t care, that is a small amount of useful signal to me.
If playing scales were actually relevant for a professional musician, then why do they have to spend time outside of concerts practicing them in order to get better?
Inverting a binary tree is nothing but basic pointer-chasing and recursion. Both skills that software engineers need.
It's like a chef complaining about being asked to make a fried egg. They might not be making that exact food in their job, but it's trivial for anyone proficient with the basic techniques that they need in their job.
I'll say it again -- if these skills were something software engineers needed, there wouldn't be a need for services like Leetcode because SWEs would just learn these skills at their jobs.
Reversing a tree is not a skill. It's a test of rudimentary experience working with fundamental data strutures. You are not expected to know the solution, but you are expected to produce one if asked.
Again, if this "experience" so "rudimentary", why do top engineers spend time on leetcode trying to get better for interviews? Wouldn't this "rudimentary" experience be learned through their, you know, actual work experience?
Because these "top engineers" are self-taught with massive gaps in their base CS education? Reversing a tree tests for the knowledge of binary trees and recursion, which is... what?... a second year of a CS program, conservatively?
Neither is counting on your fingers in binary, but would you time someone on that with a stopwatch if they would never use such a party trick during the course of a job in your company? Or perhaps we should just test their Spanish pronunciation since that would be about as relevant as inverting binary trees for any position I’ve held in 2 decades of software jobs (I’ve almost done consulting in Latin America which means my Spanish skills would be even more relevant for solving technology problems than inverting binary trees—at least for me).
If I'm hiring you to develop GUIs and work with relational databases, I'm hiring you to work on tree structures. I think you should have to prove you aren't completely clueless about tree structures.
If I were hiring you to work on raw data streams, I'd expect you to be able to figure out how to count in binary on your fingers in 10 seconds, if you hadn't already figured it out while sitting around bored somewhere.
So, I just read more about what you do, and you do some cool stuff. I know a ton of developers and most of them do nothing like what you do. The point is lots of people are annoyed at being asked interview questions about things unrelated to the job.
I wasn't always a VR developer leading my own dream project, and I didn't get to be where I am by crying about "why should I know this? I don't need it for my job every single minute of every single day."
You know what my first job was out of college after graduating with the highest GPA in my major? QA tester. That's all I could get. I had to beg to get commit access to fix bugs I found that I knew exactly how to fix.
Wait, inverting a tree is a real thing? What does that even mean? All the terminal leaf nodes become roots? That can't be right. I thought part of the joke was that it was impossible.
I would have called it "reversing", but I guess that sounds less technical. Now I'm confused, just in a different way. There's no obscure algorithm for this, just maybe 4 straight-forward lines, depending on language. I guess it tests whether you've ever heard of recursion.
I thought the meme depended on it being some obscure, difficult, and irrelevant thing.
I see this attitude all the time. It's usually from people who don't know anything about basic data structures like trees. How would you know that they don't apply?
It does apply. GUIs are fundamentally tree structures. Relational databases are fundamentally tree structures. JSON documents are fundamentally tree structures. Almost everything you're touching in a CRUD app is some kind of tree and you think knowing how to work with trees has "very, very little to do" with writing them? Again, how would you know?
I'm so serious that not knowing how to invert a binary tree is ludicrously bad. It's just a swap operation. You walk the tree and you swap the left and right branches of every branch you find. That's it. It's not black magic.
That's why it's used as an interview question. It's not meant to be a test of skill. It's a shiboleth. It's one of the easiest ways to quickly answer, "is this the sort of 'programmer' who is likely to import a whole package for padding strings with spaces?"
>It's one of the easiest ways to quickly answer, "is this the sort of 'programmer' who is likely to import a whole package for padding strings with spaces?"
But that's the sort of programmer who gets hired, because SOP for Javascript development (and oftentimes elsewhere) is to import the existing library, and any developer who insists on writing that code themselves would be considered a code cowboy wasting company time and resources, and likely writing less safe code in the process.
Because implementing low level algorithms like that is almost never an issue for application programming in modern languages, for which robust libraries for such operations exist and are data agnostic.
Unless you are using Go, pretty much the only modern popular language that both features static typing and lacks generics, so that kind of algorithm re-implementation task might make some sense for screening application programmers using Go.
> Because implementing low level algorithms like that is almost never an issue for application programming in modern languages
Except it is. You spend a lot of time traversing nested tree-structured data, validating it, sorting it, filtering it. If you can't do the simple inversion operation you have no hope with the more complicated stuff.
You usually have a structure that is already tree-like and need to write custom code to walk over it. If you're taking a tree-like thing and first extracting it to another tree structure just to do basic tree operations, then you're already performing tree-traversal and just wasting a lot of time, disk, CPU, and memory just to bundle every person-under-the-sun's tree structure needs into one place.
Most of the time the work is trivial for all developers involved. But in some special cases, some developers might reach their limit while other don't. That is my experience.
And most of the time, you can rely on the Master degrees to pull through. Although I once worked with someone without a degree, but he could do magic like no other programmer I met.
"Until I met Daniel, I actually didn't know that "smoke testing" was a term with a literal smoke-related meaning. I'd always heard it used in the context of software tests. Daniel used a tracing technique to follow a problem to its source, instead of just making random guesses."
I've always known "smoke testing" to refer to the mythical magic smoke that makes all electronics work. Smoke testing is turning something on for the first time to see if you're going to let the magic smoke out.
This- I knew the electrical sense that early software engineers working on hobby computers probably got it from, where it refers to wiring something up, plugging it in for the first time and seeing if it lights on fire / creates smoke.
That reminds me of a story[0] my digital electronics instructor once told me. He was on a team working on satellite[1] electronics and had the whole thing laid out on breadboard. It wasn't working, and they suspected it was a short, but with so many connections everywhere it would take forever to find. So they decided to crank up the input current until the short started burning and locate it that way. It apparently didn't cause anything to smoke, but eventually someone did notice the orange-hot wire that was causing the problem.
[0] I have a terrible memory so details may be incorrect.
[1] IIRC this guy had worked on geostar satellites and the hubble, but I'm not sure if this story was about either.
Yeah, this is not uncommon as a testing technique. Fuse keeps blowing? Replace it with a bigger fuse (or a heavy gauge wire) and eventually something else will pop (hopefully the bad component).
I used to live in a place where we had gas resources and gas stoves. Gas pipes would be painted yellow to stand out and people always had some sort of respect and caution around them - you don't mess with gas pipes - I learned that as a kid. At the slightest whif of gas people would light up a match or a lighter and run it along the pipe to check for leaks - I always thought this is what "smoke testing" meant (altho there would't be any smoke). I still don't know if this is safe or would even work or it's just something people did and keep doing... and I have no gas pipes around me anymore.
I remember watching my grandfather spit on pipes to find the source of a leak. It was viscous enough that it would bubble up. Taking flame to a gas pipe sounds absolutely terrifying.
I recently learned that there is such a thing as "gas leak detector". Bah, looks like fancy soapy water to me. Looked up such things, and it turns out that soapy water can cause corrosion and other bad things. "Gas leak detector" also works at sub-zero Fahrenheit temperatures if one needs to check refrigerant lines. On top of that, I bought some because I need to somewhat regularly crack a propane line on the RV/camper, and it was all of $5 for what is probably a year's supply.
If companies truly care about diversity of thought as they say they do, there is a massive untapped group who really bring fresh perspectives: older career-changers.
I might be biased as I belong to that group, but I have met some fantastic people from that group.
I think I'll do that as well next time I apply for a job. See where it lands me. If they actually check if I've won a Nobel Prize and find out I haven't, I'll just call it a career hack, that should resonate enough in today's world.
The meanings "Hero" and "Soviet Union" are both up for discussion, so I think I could bluf my way into being believed about that part at least.
Inspiring story if you don't already work "in cloud" but as someone with a decade of experience, it somehow has an opposite effect on me. This story highlights how un-glamorous our job can be: tracking down (memory) leaks, fixing (bit) rotten hardware and obsessing over (code) smells, etc. It makes me want to quit.
I don't know, I find those exercises to be satisfying in their own right. I have enough technical knowledge to problem-solve in a domain that most average people would be completely lost in, in the same way that I'd be lost trying to fix my own car or do my own plumbing. It doesn't need to be glamorous to be enjoyable.
Between "Amazon Web Services" and "Plumbing" he lists "Backflow Prevention and Cross Connection Control Inspector/Tester" and... I'm not quite sure if that's a cloud architecture skill or a plumbing skill!
This is great. Occasionally I wonder what I'd be doing if I weren't a software developer. I suspect I'd be a mediocre car mechanic. I'd be great at the weird and interesting problems, but bored to tears by the standard, unchallenging work. And crabby about it, of course.
That was exactly me as a car mechanic, finding the problem that no one couldn't find? Awesome, but even doing the work to fix it after diagnosed it was boring for me, not to mention the thousands of tire changes, oil changes... So boring.
Sold everything and travelled for 4 years where I worked on projects of my own (programming) and being self taught I planned to be a programmer when I came back (now) but thinking about it... I don't think I would like the day to day work, typing code like a monkey on the que of a superior, it honestly feels like programmers are the new factory workers of the industrial revolution.
Also doesn't help that I am in the Netherlands, where it isn't paid as exceptional as in the US, it maybe would make it bearable.
Plenty of dev jobs are as you describe, but not all of them!
For example, right now I'm working for a non-profit. Meaningful work, smart colleagues, and a fair bit of agency. It doesn't pay as well as a fancy tech company, but I get by.
You should also check out groups that are more niche. For example, a friend of mine is part of the Copenhagen user group for Extreme Programming. That's a method that's focused on a good developer experience. And in my experience, niche methods and languages tend to be used more at non-awful companies.
So stay away from the big, boring companies, or at least the boring parts of them. Look for small, independent groups with clear purposes and close connections to the users.
I recommend joining a smaller company or start-up, that way you have plenty of interesting things to work on, and won't be bogged down to being a "code monkey", as you can influence architectural decisions, and so on. It's the bigger companies with a very routine "process" that usually makes you feel like a line worker.
But certainly finding problems in old systems is a valuable skill, and it requires a willingness to do dirty work that many folks turn their nose up at, so to speak.
Agreed. It's 133 pages. Content is good for those like myself trying to answer "Where to start" with cloud stuff. Still cheaper than LinuxAcademy/ACloudGuru. If it leads to a six-figure career, a $24 investment is worth it I guess.
Like with any info product, a lot of the value here comes from what you put into it (the book contains dozens if not hundreds of hours worth of project ideas) - but I'll just add for posterity that part of the value of that sticker price is an included biweekly newsletter that provides inside referrals to hand-curated cloud jobs. We've seen great response to this newsletter so far, including multiple folks getting job offers: https://cloudresumechallenge.dev/newsletter
Yes, I should've brought up the newsletter as an additional resource.
The $24 is still the 50% off price. I didn't have any issues dropping that amount on it despite being unemployed because I already knew you from your newsletter and as a guest on Last Week in AWS / Screaming in the Cloud. For someone outside of tech, whose not used to those prices for an ebook, it might be prohibitive. Especially when they'll want to spend $40 on a course by Adrian Cantrill (I would warn them away from ACG) then the $150 for exams.
Brand new Kindle books go for $14.99 typically then settle to around $9.99 and can go lower depending on what publishers want to do.
It seems things are going well at your price point though and that's something for anyone doing self-publishing to consider. It's ok to still throw out an opinion that at face value it 'seems' expensive. :)
I'm glad so many people are getting traction out of it. I look forward to diving in further myself over the course of the next year. The thing about the tech world I appreciate are all the efforts of people to give back, including yours.
This might be a confusion around a cultural translation. "The Greatest Resume I've Ever Seen" is referring to an American "Resume" which is what we call our CV (Curriculum Vitae). In the US we use the word "Resume" to describe this 1-2 page document that outlines our skills, job history, and qualifications in order to apply for a job.
So for example in the post, this is the Resume/CV that they are referring to: https://dsresume.com/
So it isn't referencing the verb "to resume", but is instead referencing the noun "Resume", which is an American colloquialism for a CV, which is to be a piece of literature to describe qualifications for a job.
While I am American, i lived in France and England for a while and over there, the term "Resume" was completely foreign, but CV was something everyone understood. So that is why I thought I would shine light on this.
(Unless maybe you were meaning to make a joke, sorry I took the question literally)
I couldn't care less if you can invert a binary tree. One of the greatest developers I've ever worked with, I hired straight out of college. He graduated with an electrical engineering degree but his senior year he took a course in Java and liked it and decided to be a programmer. Couldn't tell me the first thing about programming but I could tell he had the chops to figure things out and that he had a passion for things getting done.