Notes from an Interviewer

https://devwithahammer.wordpress.com/2024/02/23/notes-from-an-interviewer/

by thunderbong • 2 years ago

127 190 2 years ago

devwithahammer.wordpress.com

mooreds2• 2 years ago

I'd add:

* Do some research on the company and ask a question showing you did so

* prep your coding skills with koans or similar, depending on the job and your recency of coding experience

* Have a good reason why you are looking at this company, instead of any other

uraniumjelly2• 2 years ago

* Have a good reason why you are looking at this company, instead of any other

I don't like this sentiment. Are people not allowed to be looking at other companies at the same time? Your company is probably not so unique that people will have legitimate reasons to have a significant preference for your company over other ones (sans the salary). I feel that it's out of the interviewer's line to expect interviewees to have an answer for that, when it's not like the interviewer is looking at a specific interviewee instead of any other.

igetspam• 2 years ago

I didn't read it that way. You could absolutely be interested in other companies but you should be interested in this one as well. Don't show up not knowing what the company does or the basics of the product. We hire people we want to work with, that want to work with us. Knowing who we are shows you want to work with us.

mooreds2• 2 years ago

Are people not allowed to be looking at other companies at the same time?

Of course. But I think if you can think of some reason that you are interested in this company (beyond "I need a job") that is going to help you stand out.

You don't need to pretend that working for this company is your life's dream, but a reason will show you have done some work and are excited to be a team member.

Examples include:

* I like the variety of consulting (for a consulting company)

* I really want to work more with Ruby on rails, because I have done so in the past and enjoyed it.

* What you are doing in the industry is exciting because I think webhooks are foundational and undifferentiated, but hard to get right (for a webhooks company)

Etc etc.

Don't gush, just show a modicum of interest and research.

runamuck• 2 years ago

Follow instructions. I like to say "please respond with short, focused answers. Two or three sentences per question max." The interviewer will inevitably ramble on with unfocused stream of conscious word vomit until I have to cut him/ her off.

jacamera3• 2 years ago

Thank you for sharing this and for providing explicit instructions during your interviews.

It's confusing and awkward when the interviewers set it up as a casual conversation. There are no natural conversational cues when you're talking to muted participants who are looking down writing notes and continue to do so for a few seconds even after you stop talking. It feels rude and uncomfortable to just deliver a short statement and stop but I suppose that's probably always going to be the best strategy. I'm new to interviewing and suspect I just failed a final round due to word vomit. I would have much preferred to be working through a coding problem instead of having a "conversation".

angarg122• 2 years ago

One big point I'm missing from this post is "work on your communication skills".

People shit on STAR method or variants, but the fact is that unless you are a great communicator (and most engineers I interview aren't), you will do better by adding some structure to your answers.

And then there is people who just ignore your questions and ramble on and on. Listen to your interviewer and directly answer their questions.

andrewstuart• 2 years ago

I’ve written a lot of software without knowing SOLID. Maybe I did it all wrong.

ninkendo• 2 years ago

IME, SOLID is only an important idea because there are so many ways to do OOP poorly and you need a set of guidelines to help you not turn your OOP codebase into a mess.

You get most of SOLID automatically if you just don’t do implementation inheritance. Many great languages don’t even support it in the first place, and that’s a good thing as it’s a massive footgun. That obviates 3 of the 5 SOLID principles right there: just don’t do implementation inheritance. (Interfaces are ok, just not base classes, ie. Use “implements” but not “extends” in Java, etc.) The other two principles are mostly just common sense anyway.

Or heck, maybe just don’t do OOP, as it’s not clear to me that it’s the right approach in the vast majority of circumstances. Make your data first class and design algorithms that work on it, keeping your logic and data firmly separated, and you sidestep the whole issue.

nomemory6• 2 years ago

Don't worry!

sys_64738• 2 years ago

I've found that interviewers who often give expert advice are the problem, not the interviewed.

koliber4• 2 years ago

Can you elaborate?

Joeboy• 2 years ago

My #1 interview tip would be, have a decent mic / internet setup so I have a shot at understanding what you're saying.

epalm• 2 years ago

Yes, this! In this day and age, if you’re applying for a remote position but you’re still fumbling around, unable to smoothly join a zoom meeting with a working microphone, it doesn’t bode well.

hajile4• 2 years ago

I’ve never understood this issue. We get paid well. A $400-450 Shure sm7b or Electrovoice re20 will last you decades and is an incredible return on investment — way better than your electronics and monitor investments and probably better than your chair and desk investments for most people.

Even a $30-50 USB mic will last a few years and blow away your laptop or built-in camera mic (though the dynamic Shure/EV mics don’t pick up everything like capacitive mics).

nomemory6• 2 years ago

I am also doing lots of interviews, and I try to stay away from theoretical questions about SOLID, OOP , the difference between a GET and a POST, what is an inner join, or similar.

Most of the seniors I interviewed were acing questions like this (they probably answered them tens of times before), and there's no way to differentiate them, once you get perfect answers. As the author of blog post mentioned, some of them don't even listen the question till the end before reciting manual phrases about Single Responsibility.

Some people would disagree but for us there are a few factors that predict if the candidate would be a good fit:

* The ability to solve easy and medium leetcode-like challenges and explain his choices. Nothing fancy, no dynamic programming or graph theory. This tells us if the candidate knows how to write code, which in most cases is at least 50% of the job.

* His academical record. It's a good predictor, because people who actually did good in school and finished their homeworks have a good work ethic. Of course, we are not recruiting PHDs to do backend work, but people who did decently well in school are usually nice to work with. There are brilliant dropouts, of course, but they are not the norm.

* We test how opiniated the candidate is when it comes to technology by asking outrageous questions (relative to the Status Quo): Why dependency injection is bad. We like people with opinions, but we find difficult to work with "evangelists".

The rest is commentary (at least in our case).

uraniumjelly2• 2 years ago

* The ability to solve easy and medium leetcode-like challenges

What about Fermi estimation problems? The internet seems to have turned on them in recent years, but they are a good test of intuition and general problem solving skills.

TrustThrows• 2 years ago

In four of the last five jobs I have held over the last 30 years, I have been the "last resort", the one who can find a creative, elegant, cost-effective solution when everyone else is hitting dead ends or just sitting there spinning their wheels in the mud. And I go utterly blank when confronted with a Fermi problem.

People who are good at Fermi problems may be good problem solvers. But people who are good problem solvers may not be good at Fermi problems.

DinaCoder992• 2 years ago

It's a good predictor, because people who actually did good in school and finished their homeworks have a good work ethic.

Wow, you actually ask for their transcript? I don't think I've run across this after my first job (an internship), thank god. The main issue with this, of course, is that people are generally much more motivated by pay than by grades and foisted requirements, so you're going to get a very noisy signal from this.

michaelrpeskin3• 2 years ago

I’d rather have people who are internally motivated to do good work. I don’t look for people who get good grades for the sake of getting good grades. But people who have good grades as a byproduct of just wanting to do well. I think it’s a pretty good signal for me.

nomemory6• 2 years ago

We live in a small country with few decent highschools and universities.

pavlov2• 2 years ago

“His academical record”

Here at the General 1950s Engineering Corporation, we hire clean-shaven men who did well in college, are dedicated breadwinners for their family, and killed at least five enemies in the war.

nomemory6• 2 years ago

I get the joke, but it's not like that. We have a few metalheads in the office. They did kill their fair share of dragons in video games.

sokoloff2• 2 years ago

theoretical questions about SOLID, OOP , the difference between a GET and a POST, what is an inner join, or similar.

The last two of those don’t strike me as particularly theoretical.

bckr• 2 years ago

“Theoretical” only applies to the first item in the list. The list is generally about questions related to recalling the meaning of terms.

matwood• 2 years ago

We test how opiniated the candidate is when it comes to technology by asking outrageous questions (relative to the Status Quo): Why dependency injection is bad. We like people with opinions, but we find difficult to work with "evangelists".

This is a great point. The more senior someone is, the more often their answer should end up, 'it depends'. Evangelists often end up not following the standards set in an existing project causing all sorts of maintenance issues later. They also often to seem to always be arguing for rewrites because it doesn't fit their opinionated view of the world.

russfink• 2 years ago

Academic record? I’ve worked with a 4.0 from Cornell that couldn’t follow simple instructions and a 3.5 high school student who maybe quit college later ask a critical question that shaped the end game of a research project.

koliber4• 2 years ago

It does not mean that people who did well in school or college are guaranteed to do well in a particular job. There is a correlation though, as well as many exceptions.

I’ve hired in multiple organizations. Where we could hire quickly and fire quickly, we were willing to take more risks. Where it was hard to let someone go or the work had little risk tolerance, we’re were a lot more cautious and depended on a lot of signals when making a hire decision, including the academic record.

mynameisvlad• 2 years ago

* His academical record. It's a good predictor, because people who actually did good in school and finished their homeworks have a good work ethic.

Way to inadvertently eliminate basically anybody who is neurodiverse. Most of the great engineers I know, myself included, had absolutely shit university records because brains don’t always do what they want to and university is rarely a motivating factor for people As the other commenter mentioned, rarely are the motivators the same between university and a job.

Of course, we are not recruiting PHDs to do backend work, but people who did decently well in school are usually nice to work with.

What does someone’s grades have to do with how nice it is to work with them? I know people that aced their classes and are complete sociopaths, and I know people that dropped out of high school and are lovely to work with.

There are brilliant dropouts, of course, but they are not the norm.

You say they exist, but you’d never consider them according to the rest of your comment.

koliber4• 2 years ago

As much as I hate looking at colleges and grades, and try not to let them influence my hiring decisions, I see a correlation between both quality of school and academic record and job performance. Correlation does not mean causation, and it’s a heuristic and not a rule. Many individuals are exceptions to this heuristic. However, when hiring and faced with a lot of applicants, we need to make decisions based on whatever signals are available.

One example is sloppy resumes with grammar and spelling mistakes. What does spelling have to do with coding? Both require care and attention, and your resume reflects how much care and attention dedicate to things.

jghn• 2 years ago

His academical record. It's a good predictor

Two things:

1) I graduated from college nearly 30 years ago. How is what I did in the 90s a predictor of what I'll do for you today

2) It could be "Her" academic record. Just saying.

nomemory6• 2 years ago

1) it's not black and white.

2) English is not my main language, hard to explain, but we use the masculine form when we refer to "the candidate" (which is a masculine noun). Sometimes I do a bad job at translating my thoughts into English and I get to sound like that.

latency-guy2• 2 years ago

1) I graduated from college nearly 30 years ago. How is what I did in the 90s a predictor of what I'll do for you today

Thats what the remainder of the next 30 years of history are for.

2) It could be "Her" academic record. Just saying.

It can be "His". Just saying.

dehrmann2• 2 years ago

medium leetcode-like challenges

People here like to hate on it, but if you can't solve a problem where a good enough solution uses standard data structures in a halfway obvious way, you're gonna have a hard time in the job.

Scubabear686• 2 years ago

“His academical record”.

I dropped out of college young, for complicated reasons. It has never, to my knowledge, been an issue with any potential employer.

And I also disagree with wanti g someone with a “good work ethic”, as you say. People with a good work ethic will grind out mediocre code year after year. I want a creative lazy coder who will find a smart solution or piece of automation to save himself work down the road.

_dark_matter_• 2 years ago

I've worked with lazy coders and it sucks. It really does. They are not diligent about listening to users, about following standards, about testing, or being thorough. It works in the short term but only for them, not for the team.

I despise this trope of lazy coders. The best engineers I've ever worked with were thoughtful, efficient, and hard working. They got things done I didn't know were possible, and then did it again the next day. They write books, develop open source libraries, and speak at conferences. Lazy people don't do that.

decafninja• 2 years ago

My experience with tech interviews is that the number one most important thing by far is to be an leetcode master while being friendly and personable. Everything else is secondary or tertiary to the ability to regurgitate perfect hyperoptimal solutions to leetcode mediums and hards in twenty minutes.

This won’t cover every single company as there are edge cases, but it’s the most scalable approach covering a huge swathe of companies, including many of the most competitive ones.

t8sr4• 2 years ago

I had to look up what SOLID is, and it kinda goes against most of what we’ve learned about software development since the 90s. When people say they don’t want algorithmic “leetcode” interviews, I wonder if this is the alternative they want? 1999 style OOP Java trivia?

Is the idea that you’re supposed to provide good discussion of the pros and cons, and so show some experience? That sounds like you’ll just hire people who had similar experience to you.

mytailorisrich8• 2 years ago

Hmm, SOLID is very well-known and the principles are ubiquitous good practices for object-oriented programming and also useful for software dev in general.

Certainly, asking about them and , especially, asking the candidate to critique them is a very good question.

diarrhea2• 2 years ago

Only ones I ever found worthwhile are D and maybe I.

t8sr4• 2 years ago

It’s well known in a specific setting, possibly? I’ve managed to never hear of it in 18 years.

If asking “well known to some people” stuff is kosher, should I be able to quiz candidates on FFP design principles in Haskell, or maybe how to implement collision detection in a video game? Both of those are well known in swaths of the industry.

I guess if you’re hiring for a specific role, writing OOP business applications, you will have no shortage of candidates who know about SOLID, but you’re probably passing on everyone who is changing domains.

hajile4• 2 years ago

It’s generally not what it claims. Single purpose is a good idea, but the rest…

The idea that one class changing won’t change others is a pipe dream.

Substitution only matters if you’re using inheritance, but if you’re inheriting, you likely have bigger problems as few real world problems are naturally represented by inheritance.

The interface rule is redundant with the single principle idea. Maybe it should have been SOLD instead.

Dependency injection is a guideline at best. If you actually do what it says, you get enterprise fizzbuzz. It should only be used occasionally and sparingly at specific boundaries otherwise the cure becomes worse than the disease.

More controversially, when you avoid inheritance in favor of composition in a language like Java, you lose polymorphism while keep a leaky abstraction and really bad encapsulation while the language still retains all the mental and syntactic complexity of the inheritance bits.

https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

AgentOrange1234• 2 years ago

Perhaps there’s a difference between knowing and having internalized these concepts, versus having heard of them via a particular acronym, and being expected to remember that acronym and these specific names.

“Liskov substitution principle” for instance is something I had to look up. I can read it and say, “oh, duh, yes that’s a key part of what interfaces are even for.” I’ve built with it for decades now.

The term SOLID was apparently introduced in 2004. It would be a shame to reject good programmers who can opine intelligently on these principles, but who have not internalized this particular jargon.

coldtea3• 2 years ago

Certainly, asking about them and , especially, asking the candidate to critique them is a very good question

...if you're looking to hire a code quality consultant that has not written any code since the 90s

ryukoposting5• 2 years ago

SOLID is a meaningless term in my corner of the industry (firmware, where we follow the SPAGHETTI method), so I read SOLID as a placeholder for whatever the acronym-of-the-week is. With that in mind, I came to a totally different conclusion. I want to ask questions that most interviewees get wrong, because that's how you narrow down a large pool of candidates to a small pool of finalists. Augmented by a reasonable quantity of questions, pointed questions like these can serve to isolate a signal from noise.

hitchstory2• 2 years ago

It's not completely meaningless but it does tend to be something people recite and then never think about - even when they're inadvertently following it. It's performative - a bit like reciting the bible.

Take I as an example - "don't depend upon interfaces which you do not use". I've seen good developers cut out dependencies hundreds of times for this reason - not because they've trained themselves on SOLID but because it just feels right after years of experience. If I said "this is part of SOLID" many of them would go "... is it?" "hmmm. I guess it is..."

As with reciting the bible, just because somebody recites it doesn't mean that they took it to heart and people who take it to heart can't necessarily recite it.

Being able to recite it is just a ritual used as a social signaling mechanism. It's a bit like leetcode, an ability to recite big O notation or knowledge of git's internals - symbols of "developerness" that don't necessarily align with skill.

david-gpu3• 2 years ago

firmware, where we follow the SPAGHETTI method

I used to write GPU device drivers. Electronic Engineers had a great understanding of the hardware, but tended to write sloppy spaghetti code. CS graduates, on the other hand, had a loose grasp of the hardware but we're better at writing solid maintainable code. Most teams ended up with a healthy mixture of the two, which worked great.

I once ran into a hiring manager that only wanted to hire people like himself, with the same skills and philosophy. I tried explaining why we needed people with a more diverse set of skills and strengths, but he wouldn't bulge. Unsurprisingly his team didn't deliver much value to the company.

dasil003• 2 years ago

Is the idea that you’re supposed to provide good discussion of the pros and cons, and so show some experience? That sounds like you’ll just hire people who had similar experience to you.

This depends far more on the interviewers listening skills, open mindedness and maturity. Obvious everyone has their biases, but good interviewers (especially for senior positions) need to be able to evaluate how someone with different skills and perspectives will be additive to the team.

nyrikki10• 2 years ago

DDD, Microservices, Clean, Hex, Onion, TDD, XP, EDA.....

All of those follow the basic SOLID principals.

The problem is the cargo culting and blog posts vs actually reading what the stuff means.

S or the Single responsibility principal as an example is always explained poorly by the same people who complain about it.

SRP means that "A module should be responsible to one, and only one, actor."

An 'actor' being a group that requires a change in the module.

making sure you decouple persistence code from domain code is an example. Almost universally the people who complain about SOLID thinks it means that you have to have trivial functions with lots of sprawl.

Really it is about allowing you to make changes without stepping on another's toes or trying to coordinate with them.

t8sr4• 2 years ago

Mantras like these are always a response to something. Someone in charge of technical culture at $PLACE diagnosed specific anti-patterns in their Java code, came up with a set of rules for the noobs and a catchy acronym. Things got better. Great!

But then those rules got transposed into other situations, possibly by somebody else and things went downhill. Also see "Agile".

Our industry, because of its huge growth, is filled with inexperienced people who learned from inexperienced people. We all know software is kind of trash, and we're coming up with ways to improve it, but the fact of the matter is we don't know what works. We know some things that don't work, and many of those were previously on a list of things that might work and had catchy acronyms of their own. A few people have enough experience to give good advice, but what they have to sell isn't a magical silver bullet with a neat acronym, and they don't use twitter, so nobody listens to them.

The only thing I personally believe makes you write better code is long and varied experience with different domains, fueled by a desire to always be learning. Throw away mantras when they're no longer useful. Work like this for 10-20 years, and you'll start writing sort of OK code. Everything else ends badly.

jupp0r3• 2 years ago

Your comment is involuntarily funny in the sense that 1999 style OOP Java is a serial offender of SOLID, not a prime example of it. It's mainly the Liskov Substitution and dependency inversion principles. If you have deep class inheritance hierarchies, you are not doing SOLID, sorry.

t8sr4• 2 years ago

I’m not sure I agree encouraging inversion of control, more indirection and behavior inheritance is an improvement. In the recommended style of most languages, these are probably big anti-patterns.

On the other hand, I never spent that much time working on old Java stuff, so maybe it is a step in the right direction.

mattchew• 2 years ago

I'm not crazy about SOLID principles either. They don't feel like useful, practical ideas to me. They were born to be memorized for a classroom test or a job interview. SOLID does come up in interviews, though.

Most companies don't really invest in trying to do good interviews. Rarely is there anyone motivated (or permitted) to think about the process and make it a lot better or different. Doing what they've always done, or what everyone else seems to be doing, is good enough.

ryukoposting5• 2 years ago

I used to ask ‘tell me one of the SOLID principle you strongly agree or disagree with’ but I had to stop because it ended up with the interviewee listing/describing the SOLID principles rather than critiquing them.

It sounds to me like this is a good question that you should keep asking. You're typically hiring one person out of a large pool. If only one out of 15 interviewees does well on a question, that's a helpful signal.

Fuzzwah• 2 years ago

As a good test for how important a signal this is, the interviewer should ask it to a few of their top performers.

lubujackson2• 2 years ago

This is the gem comment in this thread. If all these interviewers are such well-rounded and knowledgeable engineers, how much testing and effort do they put into their questions? Or is this just "cowboy interviewing" based on pet questions that scratch their own itch?

mytailorisrich8• 2 years ago

Agreed.

Anyone can learn acronyms, principles, etc by heart and repeat in an interview. The real useful questions are about reasons for them, purposes, limitations, etc. I.e. to test the candidate's critical thinking and experience.

dan-robertson• 2 years ago

Just because a fraction of people can answer something to your satisfaction, it doesn’t mean it’s a good signal. Eg I don’t think baseball trivia would be a great way to narrow down candidates.

That said, if you need to narrow down the pool and you like the question then go for it. I think it’s important to keep your ultimate goal in mind, which is probably:

- find the desired number of acceptably competent candidates

- who are likely to accept your offers

- without needing to make very large offers

- or spending a lot on finding and interviewing unsuitable candidates

- while complying with any local laws

These can lead to a bunch of different things you see in hiring processes (eg you prefer referrals because of 2 and 4, and candidates may be rejected for being overqualified for reasons 2, 3, and 4)

As a candidate, this often feels very frustrating: you would rather companies follow processes that are maximally fair where so long as you demonstrate sufficient merit, you get an offer. Or even better, processes that do a good job of uncovering the value you bring. I guess one can try to look at the hiring process through this lens to not take rejections so personally, and one can hope that different companies will have different processes (to hopefully reduce how much they compete with each other for the same subset of candidates) though I don’t think they end up being very different in practice.

ryukoposting5• 2 years ago

You're absolutely right - my remark was made with consideration of the specific question at hand. Instead of asking them to regurgitate an acronym, the given question asks the interviewee to provide analysis of an engineering technique. The question gauges an interviewee's reading/verbal comprehension, while also giving the interviewee the opportunity to display analytical thinking skills and an intimate understanding of the topic.

thih9• 2 years ago

Overly rigorous interviews are a problem in the IT industry, articles like this are a proof.

If you google ‘top 10 X interview questions’ where X is your technology, and a question is on that list you should probably know the answer.

Even if the company is not using that aspect of the technology in their work? What if the candidate has referrals and experience that already presents them as proficient?

sharas-2• 2 years ago

On interviewers who are asking about "recommended practices", SOLID, etc...:

Had an interview while back with a hiring manager for "Agile Coach" position. - He couldn't answer basic questions about what goal he wants to achieve. That was a weird question for him. - He was grilling me on SAFE processes.

This is a "normal" case.

sokoloff2• 2 years ago

I suppose that not knowing what goal they want to achieve could reasonably lead to them wanting to really scale up agility.

sharas-2• 2 years ago

SOLID, TDD, etc is a noise from simpleton uncle. I tried hard to see if he has anything of value to say. He doesn't really. That doesn't stop him from selling simplistic slogans to get attention.

jacamera3• 2 years ago

There's some good advice here but I take issue with this statement:

I used to ask ‘tell me one of the SOLID principle you strongly agree or disagree with’ but I had to stop because it ended up with the interviewee listing/describing the SOLID principles rather than critiquing them.

How many people have internalized every part of SOLID such that they can immediately start critiquing one of the items?

I learned about SOLID in some book 10+ years ago and I'm going to need a minute to remind myself what the acronym stands for. It's a sign that I'm taking your question seriously rather than just giving pros and cons of the first random thing that pops into my head.

I think this is just a bad question and that it reflects poorly on the author that they automatically assumed the fault lies with the majority of interviewees.

hitchstory2• 2 years ago

It's become almost a cliche as an interview question. That's the main reason I've thought about it enough to be able to critique it.

I think it's not necessarily a bad question assuming that the candidate can recite it. If they can, they probably should have thought about what it means.

I've met plenty of devs who can't recite it but who do it all instinctively though. That's why I'd rather see people demonstrate these principles while coding without using the term at all.

But, coding interviews are expensive and you need some way of sorting the 100 applicants into the 90 who can be ignored and the 10 who are worth an interview. This is a hard problem I've never found a really good answer to. OP's question isn't worse than most of the attempts I've seen.

gopher_space• 2 years ago

you need some way of sorting the 100 applicants into the 90 who can be ignored and the 10 who are worth an interview. This is a hard problem I've never found a really good answer to.

It's a solved problem but you need to take your engineers offline during the hiring process. This looks expensive if you're trying to increase headcount rather than fill actual positions.

jupp0r3• 2 years ago

I've also seen plenty of devs who can recite them and then blatantly ignore them when writing code.

karmakaze• 2 years ago

This is a bad question in that most devs will have internalized several of the terms without attaching that unconscious knowledge with the SOLID terms. I'm always reminding myself which letter means which 'thing that I know'.

The stand-out one though is (S)ingle responsibility. (All the other letters (OLID) are mostly aspects of how to do interfaces/testing.) It means not only to pick an arbitrary thing and do that thing in a class/module. It covers the full gamut of naming things being hard. If you understand the problem, and how to decompose it effectively, then those are the things that get separated out as responsibilities. It's easier lower-down when you're working bottom-up.

Adherence to any buzzword has a potential for cargo-culting so always be aware of trade-offs and exceptions to the rule(s). An experienced dev should be able to convincingly describe the pragmatic benefits of any particular application of a rule.

A different thing that's rarely discussed which I find more valuable is distinguishing policy vs mechanism. This really gets to the heart of understanding and choosing your abstractions. If you do this part well, the things just name themselves.

I suppose then that I would respond to the question by picking one (if I have a strong opinion) and/or critiquing SOLID in general rather than letter by letter.

patrickthebold• 2 years ago

The author seems like a reasonable person. IMO the best response is something like: "I don't remember the acronym specifically, remind me of the principles and I'll tell you which I feel are the most and least important."

Interviewers aren't perfect. Most are happy to be asked clarifying questions.

lopkeny12ko3• 2 years ago

This is a gotcha question, but all things considered, a pretty good one. "I don't remember/know what SOLID is" is the wrong answer, and an easy way to screen out candidates.

No, this isn't about rote memorization to pass an interview. It's about meeting basic qualifications to be a software developer. I can't imagine any reasonable technical manager wanting to hire an experienced dev who doesn't know SOLID.

sumeruchat• 2 years ago

That’s exactly my answer every time.

mekoka• 2 years ago

My answer to this question would go along these lines.

SOLID is a flawed attempt at packaging "clean code" into a formula. The military sounding acronym itself is a stretch, as only the first principle is really of importance. Producing clean code in practice is going to be leaky. That's just a fact of life. It relies heavily on experience and tacit knowledge. I think it's the reason many senior programmers tend to repudiate (consciously or unconsciously) SOLID as their craft matures, and embrace instead a set of guidelines to produce code that (in more or less that order) works as expected, is bug free, is reasonably efficient, and is maintainable (i.e. is legible, understandable, testable, etc).

UncleOxidant• 2 years ago

For fun I just asked BingChat/Copilot this question and it really likes the Single Responsibility Principle - it wrote a couple of paragraphs on it and then offered a code example in PHP. I'm looking forward to the day when we can just sent our AI avatar to interviews, it'll save so much time and stress. ;-)

baby_souffle2• 2 years ago

I'm looking forward to the day when we can just sent our AI avatar to interviews, it'll save so much time and stress. ;-)

We already can! I recently went through the "can you code?" phase of the interview pipe and they had me use a shared code IDE thing that ... had chatGPT integration.

The prompt was simple and I put in a paraphrased version of it into the chatGPT pane and ... the proposed solution was _almost_ correct. The coding question had one small wrinkle that could be accommodated by making a small tweak to the proposed solution.

I don't know if this was "free" gpt or the version that has code execution; I didn't bother pushing GPT to run and evaluate the code / correct its proposed solution against the test cases that the interviewer provided... but it almost certainly would have quickly figured out the wrinkle and adapted.

FireBeyond• 2 years ago

How many people have internalized every part of SOLID such that they can immediately start critiquing one of the items?

There was a post here the other day (https://news.ycombinator.com/item?id=39460829) where someone was giving advice about interviewing at Amazon and knowing their "sixteen principles" because "they're not just words, here more than anywhere we live and breathe them". He even went on to talk about how they specifically used them all in interviewers, and "bar raiser" interviewers were chosen for their "deep and profound" understanding of them all (there was more than a slight narcissism and smug superiority in the article, if you ask me).

My thoughts were: "Quick, you work at Amazon. Name all sixteen principles that you live and breathe every day. That people are expected to have a deep and profound understanding of."

(My other favorite quote in that article: "I have certainly referenced Amazon's Principles when discussing parenting techniques".

layer84• 2 years ago

The author isn’t criticizing that an interviewee might not know the SOLID principles. They are criticizing interviewees who can recite the principles but apparently are unable to express an opinion on them.

The SOLID principles are actually a good example, because some of them are so ill-defined, and they are such an uneven combination of items, that it’s hard not to have second thoughts on them.

csydas• 2 years ago

it’s just a bit too much for the question i think and it asks for opinion on a subject in an already stressful situation where the candidate is very eager to please and also had their mind in the context of answer with well reasoned technical arguments. I can easily imagine and many times have seen interviewers try to propose an opinion question like this only to spend time explaining to the candidate why the candidates answer is wrong.

It probably seems like a trap to many candidates and often it is a trap whether the interviewer meant it to be or not.

This isn’t to say that there shouldn’t be opinion questions but I wouldn’t position it like the author did in. at least how it’s presented it seems like it’s a fairly “big” question in the interview which candidates will pick up on as being important and questions of opinion can be nerve wracking in such a situation.

I also think that what the author is trying to test can be handled better; i am pretty sure the question is a measure of does the candidate think through their positions and can they defend it professionally, but i think there are better approaches, for example picking a common task with many ways to accomplish the task and asking the candidate how they’d do it and why it’s useful for them to use that method. For me at least i understand their approach a bit more and i like to hear about how they handle such situations in the way that’s most comfortable for them. that the task is one with many possible ways to accomplish it helps take the burden off the candidate in many cases as likely they know there are many approaches and it usually gets candidates to open up and talk about their projects and workflows. I often learn new perspectives on such tasks and telling the candidate as such calms them down a lot also since i genuinely like to hear new approaches. if there are elements i don’t understand, it’s a great question “oh that’s a new approach for me. can you explain a bit more how this method is useful for you?” (not exact words) which usually is a great way to get candidates to talk more as they see i want to hear their thoughts, not a specific answer; they know their answer is one of many right ones so there less burden there too.

i think the authors question is good intentioned but poorly executed.

deathanatos• 2 years ago

How many people have internalized every part of SOLID such that they can immediately start critiquing one of the items?

You don't need to have internalized every part of SOLID to answer the interviewer's question. You need to have internalized a single part.

I can only remember two letters myself: the "S" (the Single Responsibility Principle) — which seems like the unforgettable letter in the thing — and the L. That would suffice to answer the interviewer's question.

(I'm not sure I agree with the interview question, as I'm not sure what I, as an interviewer, would hope to glean from it.)

xandrius• 2 years ago

Maybe I don't know enough but I believe having any person talk about a few random projects from their CV and me asking them questions relevant to their position would give me a pretty good understanding of how much someone is knowledgeable in their field, as well as their confidence and general curiosity (it's ok if they just know their bit but plus points if they can also talk about design, business and/or other parts outside of their role.)

Of course one could learn that by heart and fool me but I'm also pretty sure people are currently wasting/spending their time memorising acronyms and leetcode just to get someone to give them a chance, so I'd rather have both enjoy the process.

tekkk• 2 years ago

Sounds like the author really likes their OOP. Nothing wrong with that but I hope the trivia is reflective of the job. I find programming to be mostly manual labor where common sense trumps many clever paradigms.

jeffrallen• 2 years ago

I’m sometimes in a practical part of the interview where a certain part isn’t going well. ... At this point I’ll try to offer the interviewee some hints or maybe even just tell them what to move them along. However, on quite a number of occasions this advice has been flat out ignored and the candidates have kept ploughing on with whatever failing approach they were using. To put it bluntly, the initial inability may not have been a deal-breaker but ignoring advice is.

Yes! If I set it a problem for you, and you're not getting it, it turns into a new interview challenge: can you work with me to get back in track? I'm not a ghoul looking for any chance to hang you. I'm your potential future colleague, and I'm looking to see if we can work together. Not knowing something is fine. Not listening to me as I try to get you unstuck and work with you too get moving again is unforgivable.

ccvannorman• 2 years ago

"Study basic interview questions, listen actively, and have a good attitude."

Why is this on the frontpage.. ?

pyb• 2 years ago

Serious suggestion: If interviewers want thoughtful answers, they should try sending the questions in advance.

icapybara• 2 years ago

They don’t necessarily want thoughtful answers, they want answers that provide them information about the candidate. Sending the questions in advance would ruin that.

mathattack• 2 years ago

“Listen to the interviewer” should also be read as “don’t talk over the interviewer.”

I used to chalk that up to nervousness of the candidate. I’ve since learned it’s a very bad sign.

nyrikki10• 2 years ago

My big problem with 'Know why not (just) what' is that, as demonstrated in the responses here, the interviewers typically don't, and if you try it will sometimes result in them failing you.

At a Google interview I tried to explain that in big-O notation the sequence can only exceed the bound in a finite prefix of the sequence.

Formally:

O(g(n)) = { f(n): there exist positive constants c and n_0 such that 0 ≤ f(n) ≤ cg(n) for all n ≥ n_0 }

I was actually made the interviewer mad with that when he asked if there was any reason to use non-recursive search algorithms and I was providing justification.

I still got an offer but turned it down because I need an environment where I can learn where my blind spots are and return in kind with the team.

Hunpeter• 2 years ago

Are you SimonDev? ;) https://youtube.com/watch?v=gCzOhZ_LUps

nyrikki10• 2 years ago

No, never seen that channel before but if he interviewed at the Fremont campus in Seattle we probably had the same interviewer or same internal guidelines?

It looks like he took that job, I didn't.

layer84• 2 years ago

You describe how it successfully prevented you ending up in the wrong environment, so I don’t understand why you have a problem with it.

nyrikki10• 2 years ago

The problem is that I hold back now, and I also have to waste time interviewing people to make sure it is clear I would love to learn from the candidate when conducting interviews.

The trivia game without context of assumptions and constraints is problematic for everyone.

Scubabear686• 2 years ago

I have been interviewing technical candidates for decades. I have found the most effective approach is to deep dive into systems the interviewee has built. This puts them comfortably in areas they should know, and very quickly how shallow or deep their knowledge is.

Asking random questions about technology mostly tests their ability to memorize facts. I want people who know how to build things in the real world, not those who excel at adding certifications to their LinkedIn.

A parting word - if you are leaning towards Uncle Bob for wisdom, you are heading in the wrong direction.

mtriassi• 2 years ago

I'd love to know a little bit more about how you do that. I'd typically feel wrong asking a candidate to show code they've written at a previous employer.

Do you just ask them to walk you through the architecture by memory? If so what how do you come up with questions about their choices without the specificities of the actual way they wrote their code?

mixmastamyk• 2 years ago

Don’t believe GP was talking about previous code, rather previous design. Perhaps diagraming on a whiteboard.

jareklupinski• 2 years ago

Do you just ask them to walk you through the architecture by memory?

depends on the role, e.g. for infra work i can ask "if you had complete autonomy to stand up this project again, what would be your first step" and then we go from there

Scubabear686• 2 years ago

No, I don’t ask them to show me any code or artifacts, but to simply describe the architecture, how it’s put together. Any novel code or algorithms they are proud of. Areas of the code that were problematic, and how they would fix them if they had the chance. Talk about non functional requirements and if the architecture addressed them or not.

Basically see if they could communicate how the system worked, it’s good points and bad points, and how deep they could go. This quickly separates the good developers from the cargo culters and pretenders. It also is a good gauge of how much real experience they have had.

Generally, if someone can’t describe at least the rough outline of the architecture of an application they have worked on, that’s a strong signal they are going to struggle as a developer

arcbyte2• 2 years ago

Definitely agree with the first part. The most important thing you interview for is passion and any discussion that lets the candidate show that more is great.

Hard disagree on the bit about uncle Bob. Everything he says isn't gold but his take on clean architecture and use case driven development is pure magic.

galoisscobi• 2 years ago

What has he built other than peddling his books and courses that we use on a daily basis? I don’t know if he meets the bar of an exemplary engineer by that standard.

Coders at work was a far better resource in that regard, every person that was interviewed has made significant impact in the world of computing and is discussing hard earned lessons about building software.

agumonkey• 2 years ago

This is so rare. I thought that the github repo trend would lead to more of this type of interviews but so far I hit none. Either people say "cool" and never mention your repo ever again or they straight say "we don't care about repos". So strange

jl2718• 2 years ago

You should always understand that the reason they are interviewing you is because they are unable to solve their own problem.

neilv• 2 years ago

The most useful thing about skimming articles and HN comments about interviewing is: Some people think X about interviews, so I need to be prepared for X.

As you pour your energy into simply getting past the ridiculous nonsense gatekeeping.

Once that misdirected energy gets you that job, you're now safe to pour your energy into the real business... of resume-driven development.

In 12-18 months, repeat. It gets easier each time.

daniel_iversen• 2 years ago

Another one or two that I feel are very important; 1. Be invested and show you give a damn, 2. (Related to 1) ask good questions that show you care and are invested

tptacek2• 2 years ago

Interviewing is a terrible way to screen candidates, but if you're literally asking questions that appear on "top 10 interview questions" pages, you're not even trying.

This whole thing really comes across as an interview process that is about soothing the interviewer more than it is about collecting empirical data that can be used (and iterated on) to qualify candidates. Be upbeat! Show that you've read the same Uncle Bob posts I have! Question me when it's important that something I said be questioned, but listen carefully and do what I tell you to in other cases!

angarg122• 2 years ago

Interviewing is a terrible way to screen candidates

so.... how do you suggest companies hire candidates? purely through referrals, without any further screening?

kasey_junk• 2 years ago

Thomas is a long time and outspoken proponent of work sample hiring. Here is his current companies process https://fly.io/docs/hiring/hiring/

lubujackson2• 2 years ago

Honestly, why not?

Obviously there needs to be SOME degree of vetting, but the way senior+ engineers are handled in the market is just absurd. The entire software engineering process is so closely tied to college classes with maybe a few years of professional work. All with the idea that "hiring the wrong person is terrible" but not considering that there may be thousands of developers that can effectively do the work.

If software engineering was handled like most other jobs, your work experience and references would be like 70% of what are considered. Instead, resumes serve as little more than initial screens at best, with all the weight given to leetcode results, pet questions and system design questions about how you'd build Uber in 10 minutes.

We act like its the 90s and literally everyone is new to the game. It's time to recognize the job has become a mature profession and we should treat it as such.

opmelogy• 2 years ago

If I disagree with you, that’s not an issue. Just like the songs Lennon and McCartney wrote together were better than the ones they wrote after, contrasting opinions on a team bring new insights and better decisions.

This is great but please tell people this upfront. Not everyone has an over abundance of confidence - especially candidates that come from traditionally marginalized communities.

Notes from an Interviewer

Related Stories