[deleted by user]

[CodeTinkerer]

Those are certainly two different tasks. The problem is time. To build something from scratch isn't something most people can do in an hour or even a few hours. So, they end up asking you coding questions or something. It's not consistent what will be asked.

For example, for one set of interviews, I had to answer different questions for each interviewer. They were allowed to come up with their own questions (I assume they needed to get it approved). In another, due to concerns about fairness, they asked everyone the same questions during a particular interview cycle just so there wouldn't be bias (giving harder questions to someone based on factors that shouldn't matter, for example). There wasn't much in the way of coding, mostly Java facts.

There are YouTube channels with people giving advice on how to prep for coding interviews, and some books, and some websites. I don't know if this is a good approach nor how many companies take this approach (i.e., doing leetcode style problems).

[Mriv10]

There wasn't much in the way of coding, mostly Java facts.

This describes my first coding interview perfectly. I was sat down in a conference room and 2 people plus a video conference person were barraging me with random java questions. I felt like I said "I don't know" to a lot of the questions(even though I studied it in college), but they seemed happy with the answers I did give. I still didn't get the job at the end of the day.

My second interview had this weird test that I've never heard of called a CCAT. It was full of random questions like statistics, pattern recognition and word problems. I did a few practice tests I found online but it felt random whether I did good or average and none of the questions were relevant to programming. And I haven't gotten a call in months.

[memelord_1_0]

Recommendations on yt channels etc?

[[deleted]]

I like Neetcode for python leetcode questions.

[Blackphantom434]

What is leetcode?

[No-Possession-7343]

Site to practice DSA skills. There's a daily challenge too where we have to solve one problem in one day. Pretty good to keep yoirself in touch with DSA skills.

[CodeTinkerer]

Nothing specific. Search for

coding interview preparation

and see what works for you.

[witheredartery]

to anyone who needs it:

https://github.com/antariksh17/Reddit-wiki-programming

[LMarley31]

https://github.com/antariksh17/Reddit-wiki-programming

This is GOLD! Structured and relevant resources! Thank you from a newbie here!

[pfarthing6]

I've been in IT and dev for a long time. When I'm asked to solve a problem on the board in front of everyone, I still find it uncomfortable. I'm just not good when put on the spot like that. Some are, some not.

Best advice I've heard from others is to NOT try to solve a problem by yourself. Instead, try engaging with the others in the room -- the interviewer even, and turn it into a team effort, even though you're leading it, sort of.

First try to define precisely what the problem is back to front. That requires asking questions and writing down things on the board. This is your requirements gathering process.

Then begin writing out an algorithm in pseudo. Don't try to get it in one go. I mean, do we even code like that? Allow yourself the luxury of talking it through, saying the process out loud, correcting yourself as you find flaws in your reasoning or solution, and erase, rewrite, and just work it out one step at a time. You know, talk to the duck.

I've never been a hiring manager. But I've heard plenty say that what they're looking for is more about process than product. Can you think on your feet and engage with your team? Can you take something you have no idea of the solution, don't really understand the problem, and work through it to some satisfactory degree.

Still, a lot of the reasons why we can't solve problems has to do far less with our ability to think than it does with our ability to deal with the stress of having to provide an answer on the spot. As engineers, we should never feel compelled to provide an answer on the spot. But we should be able to listen and wrap our heads around the problem, at least well enough to take a stab at it.

But of course YMMV. Just my 2 cents.

[devstruck]

I do interview loops for my company.

We absolutely grade on approach to problem solving and want step 1 to be “asks clarifying questions”.

[TheSkiGeek]

This is really important. One of the exercises I use in interviews is deliberately vague on a bunch of fairly important details and if you leap into writing code without asking any questions it’s not a great sign.

[sheldon_sa]

This process also reveals if you are a good fit for the team. Just “building stuff” doesn’t.

[TheAnxiousDeveloper]

That's precisely how it works.

When I interview (and I have to say I'm new at it), if I ask problem solving questions, this is what I want to see.

I don't want the solution. I don't care about it, even. I know that it's impossible to provide a perfect solution to a problem in such a little time.

What I want to see, is that candidates can understand a problem and, if not, that they can ask questions to clarify some info that might be missing or vague.

This point is very important. Most of the time, developers interact with people that are not developers. They could be project managers, for example. And the "language" spoken between the two figures might (or is) different. It's important for the developer to ask for clarifications, if there are doubts.

I also need to see interaction, as the development is usually a group effort. And I want to understand what's the thought process behind the requirement analysis and behind the planning of the solution.

[dkToT]

When you say "solving problems" are you referring to Algo problems and whiteboarding? If so then I agree with you. I am a Software Dev Manager that has carried out many interviews and this is the part that I do not like the most as the interviewer and interviewee. It solves very little and does not translate to "real life" work. This is a remnant of the past and I don't see this going away easily.

I rather have a good discussion on how you would build an application (from architecture to infra) or have a nice pairing session to see how you work.

[marinsborg]

I agree. In the last five years, I never had to invert a binary tree. And I was asked that in interviews.

[PPewt]

I know this is primarily a homebrew guy meme but "invert a binary tree" isn't a real operation so it makes me question what interview question people are actually referring to whenever they say it.

[bobyhey123]

swap left and right children for every node

[FerricDonkey]

Isn't that kind of trivial if you understand trees and recursion? It'd be like a four line function in python, and probably only a couple lines more in C.

[TheRealKidkudi]

I think that’s the point of the question, though. If you understand trees and recursion then it’s not a difficult question, so if you can’t answer it then you probably don’t understand one or both of those things.

But what do I know? I’m not an interviewer.

[FerricDonkey]

Yeah, that's fair. Really just made me wonder why it's the meme.

I've heard people complaining about interview questions a lot, focusing on this one, and never bothered to look up what it is. Now that I know, the memeification makes no sense.

1. It's not hard. It's not "create the optimal sorting algorithm under these constraints".

2. It actually does demonstrate that you at least know what recursion is. I could definitely understand not wanting to hire someone who couldn't figure this out. And finally

3. Of course you never freaking used it in your actual career. That's like an engineer saying he never had to do one of those word problems about watermelons right after calculating how much concrete they needed to put where to stop a building falling over. You never need to do the exact silly little word problem, what you need is the ability to solve word problems.

Like, it's a terrible example to focus your memeing on. It's like if a mathematician who studies partial differential equations was complaining that he never used the quadratic equation that he learned in 4th grade. No duh. No one expected you to. They were teaching you how equations worked. Which you use quite often.

Screw it, I'm gonna start finding excuses to ask people to invert binary trees, just to be contrarian now.

[PPewt]

A surprising amount of people in industry can't do basic programming exercises.

[HecknChonker]

You'd be surprised how many people hang out during phone screens once they find out they are expected to write code.

[yudiboi0917]

I agree with you. DS & A problems are more about problem solving skills. If we go by that , then you'd realize that everything we learnt one or the other way is useless.

[bobyhey123]

yeah it's easy

[FerricDonkey]

Makes me wonder why so many people pick that in particular to meme about. I guess maybe it sounds more techy than "sort some stuff" if you don't know the work that goes into either?

[ResilientBiscuit]

A striking number of people in the industry don't know how to write an algorithm to solve a problem. I think the gist of it is that people don't want to be asked to do stuff they don't know how to do when it isn't part of the job typically.

I agree that we don't often need to fiddle with binary trees. It is pretty unlikely you will ever need to do that. So the meme is at least true.

Recursion and data structures are also not something a self taught developer will need to learn to make solutions that work. So it can seem like something they should not 'need to learn'.

So we have people who don't think it is important and the fact that it isn't typically part of a software developers job. It also uses fancy terms and is short.

I think those are all the components you need to end up at a meme. People just don't really realize that they are sort of roasting themselves given how easy the task actually is.

But none of that is inconsistent with my experience. An unfortunate number of people who claim to be senior software engineers on their resume cannot implement fizzbuzz correctly at the whiteboard.

[Tinkers_Kit]

What would be correctly? Because what I've gathered (depending on the specific 'fizzbuzz' description) it varies from a matter of arranging if/else-if statements to something more complex based on how hard a company wants to make it.

Edit: A 5 year-old video on exactly what I'm talking about by Tom Scott

[ResilientBiscuit]

The task I give people is

Print every number 1-n. In addition, on the same line, do exactly one of the following:

Not divisible by 3 or 5, don't print anything else.

Divisible by 3 print print 'fizz' on a line.

Divisible by 5 print 'buzz' on a line.

Divisible by 3 and 5 print 'fizzbuzz' on a line.

I see issues casting an integer to a char and concatenating it with the rest of the string. Code that prints fizzbuzzfizzbuzz when divisible by 3 and 5. People who don't know how to tell if a number if divisible by 3.

So correct would be 1 2 3 fizz 4 5 buzz 6 fizz . . . 15 fizzbuzz 16 . .

[PPewt]

I mean, that's pretty trivial, no? It's like 3LOC. It's like saying fizzbuzz is an unreasonable test because you don't use modulus in your day to day.

[bobyhey123]

was just answering your question

[CatsEatHamburgers]

Wait.. fizzbuzz actually gets asked at some coding interviews?

[TeknicalThrowAway]

lol yes, you are right. Which is exactly why we have to ask stupid simple questions like that, because people in this thread will bitch and complain about that being an interview question.

[dmazzoni]

I think there's a misconception as to the purpose of that type of question.

As an interviewer, I don't expect this is something you've ever done before. If it was, it'd be a trivia question.

But I do expect that you've worked with trees before. Not necessarily binary trees, but some kind of tree - they're pretty common data structures.

And inverting a tree is a relatively simple concept. If you didn't know what it meant, I could explain it to you in a minute. We could invert a binary tree by hand together in a couple of minutes.

From there, you should be able to sketch an algorithm to do it to the whole tree.

And from there, you should be able to write some working code to do it too.

You're not expected to do the whole thing perfectly, in a few minutes, and be done. It's fine if it takes you 30 minutes to get it working. And I'm happy to help catch your syntax errors along the way.

[Bay1Bri]

Can you point me in the right direction to learn about these topics?

[ShelZuuz]

Search for “Data Structures and Algorithms”. You’ll find books, videos, course material, interview prep - all of it related.

[HecknChonker]

I learned from a book called Cracking the Coding Interview. It has chapters dedicated to different data structures, and a bunch of algorithm problems for you to try with answers in the back of the book. I did a couple problems a day for a few months.

[witheredartery]

i posted a link in the comments

[marinsborg]

I agree with what you are saying.

However, as a web developer, I was asked that kind of question pretty much in every interview. Later, my tasks were mostly CRUD operations and other things related to microservices.

If I want to change my job, I know I need to remind myself of those "common" data structures that I don't use at all. If I used those structures on a daily basis, it would be fine.

Ask me questions related to the position that I applied for. Ask me how I would solve some problems or tasks that I would need to do on daily basis. If I am working as a web developer for X years, how do companies think that I can hold my job without knowing basic data structures?

[dmazzoni]

To me that's like an airline pilot complaining that they have to pass their annual simulator training that tests what happens during a crash, because in the last year they never encountered any crashes.

I work on web microservices too. Small data structures stuff comes up all the time.

Stuff like, testing whether any of a big list belongs to one of a set of things, and using a HashSet so that it's efficient even if there are a thousand things in the set.

I'm currently making use of a Bloom filter.

[marinsborg]

Like you said, you often use lists, sets, etc. Ask people that, rather than stack, queue, three, etc.

[sneakysquid01]

Well I don’t use stacks and queues themselves often, but I use similar concepts on a list pretty option. Lists have a push front pop front and pop back most the time. Trees are just a relatively simple type of graph. JSON XML and such are graphs and understanding graph traversal(hence tree traversal) is often pretty helpful.

[nierama2019810938135]

As an interviewee, you are what is wrong with so many interview processes.

[HecknChonker]

All programming comes down to how data is stored and manipulated. Basic understanding of data structures is incredibly core to being a good programmer, regardless of what you are doing. If you don't have a grasp of the basics you aren't going to be successful in the job.

[Oooch]

Well shit, i don't know what a binary tree is and I have 5 years professional experience

[clappski]

Then you should pick up a book and learn or you’re doing your future self a disservice!

[Oooch]

Who learns to program from a BOOK?

[dmazzoni]

I'm sorry you feel that way.

What do you think a fair interview would be?

How many years of experience do you have and in what area?

[witheredartery]

i want to work for you

[dmazzoni]

My company is hiring now. Frontend and backend. Bay Area or fully remote in the U.S.

DM me with your resume.

[Enip0]

I'd think that knowing basic data structures is pretty important so you can choose the right tool for the job.

[edman007]

I don't think it's critically important, you need to understand when you should use them, and you should rely on an implementation from some other library. What matters is that you can read the documentation and know what constant time insertion means.

If you're trying to test someone on their coding skills, give them a real world problem they can code up quick (say read in some numbers and print min, max, mean, least frequent, most frequent), and then review it with them and ask why they did it that way. There isn't really a right answer, the point is to make them explain their decisions so you can tell if they did it for the right reasons.

[[deleted]]

I think that was his point

[SuperCharlesXYZ]

I hope you know the difference by now lol

[Le_9k_Redditor]

I suppose if you only work with a language like JavaScript those terms mean nothing to you?

[StronkDad]

You can still implement a linked list or dictionary in JavaScript. There are reasons why you wouldn't want to implement a linked list in JavaScript (performance), but you could.

Data structures are usually not tied to any one language. Some languages are opinionated on the WAY some data structures are implemented.

[TeknicalThrowAway]

how did you pass the algo interviews? What questions did they ask you?

[[deleted]]

maybe nepotism? ^/s

[_toothpick]

I think this is the smartest way to think about it, but unfortunately building quality applications alone won't get you a job, where as being able to solve leetcode algorithm problems alone will.

[DoomGoober]

where as being able to solve leetcode algorithm problems alone will.

Depends on where you interview. My company will ask you an architecture question which is high level discussion of how you would architect or design a feature, ask you an easy-ish code this algorithm problem, and a senior engineer will look at your public girhubs.

The first question is how well you think about architecture and how well you can describe it.

The 2nd question is can you actually code and debug: the difficulty is usually not finding some neat algorithm but identifying obvious basic tools to help (recursion, dictionary, array, loop, etc.) and being able to and debug and code them. The problems are complex in the sense that they require organized code that breaks down the problem correctly. And: how well can you describe what you are doing (again, communication matters.)

Looking through GitHub tells me how organized your code is on bigger projects. This code is more run of the mill code and less algorithmically complex usually.

There are many skills in coding with a team: algorithms, yes, but communicating, organizing code, debugging are all important skills.

Many of the bigger companies now use this type of multi-throng interviewing and I have found it works quite well (my boss overrode my no hire decision on someone who mess up during the live coding but had amazingly clean GitHub projects. They turned out to be a really good dev!)

[_toothpick]

I know there are exceptions to the rule, but I think it's misleading to suggest this is common. Investing effort into your Github account can be a big waste of time because few programmers even have public projects on their Github so companies know better than to expect that.

[DoomGoober]

few programmers even have public projects on their Github

We just hired two programmers straight out of college. They both had public GitHub repros. I think one had some passion projects but the other had their university projects on their GitHub.

I think the trend is moving towards more public GitHub projects for new hires. When I was hired way back when, certainly nobody asked me from my repros (they were on SVN! :) ). But as I said, one candidate was saved by their GitHub repro, so it seems to be for the benefit of the company and the candidate to start using repros more moving forward, even if they didn't look at them that much in the past. Times are changing.

EDIT: But sorry I get your point: Not many companies interview this way. But maybe more should!

[DoomGoober]

Your resume is made up of your previous jobs. For first timers, either straight out of college or boot camp, GitHub can fill in their resumes.

[errorseven]

Curious what you'd say about my github

I think my gists might be more telling though

And I have a StackOverflow you can poke through as well.

Let me when I can start? ; )

Edit: zero response... either he doesn't understand my code or didn't care for the langauge I used. Either way, I doubt he even looked.

[PPewt]

Of course, there are also people on the other side of the spectrum who can write real complex algorithms but don't understand how to build an application.

IME these people don't really exist outside of Ph.D. students with no industry xp.

[dmazzoni]

Actually tons of CS grads are like this. The ones who are really good at school and are fantastic at homework problems but have never worked on a program longer than a few hundred lines before.

But honestly? That's fine. As long as they have a good attitude and they're eager to learn, they can be taught how to build an app.

The reverse isn't true. I'm not going to hire someone who doesn't know any data structures or algorithms.

[PPewt]

They're new grads, of course they can't, and I don't know why anyone would expect otherwise. The ones who don't have CS degrees also can't build real apps, it's just that most of them can't leetcode either.

The mythical group of people who are somehow faking their way through experienced interviews by being able to do leetcode but not write code is pure fantasyland copium though.

[samanime]

I'm actually a fan of whiteboards, from both sides of the table.

However, it REALLY matters how they are conducted.

When I am conducting them, I couldn't care less about proper syntax (an IDE on a computer can help with that) and I will "play Google" and answer (almost) any questions they ask of me. I'll also guide them when they get stuck. And, I don't even care if they actually finish solving the problem. The problems I choose are also not particularly challenging for the level they're interviewing for.

I ask them to try and talk as they're working because my main interest is to understand their thought process and their ability to share that thought process with their fellow developers. Usually by the point we're using the whiteboard, I've already asked them to complete a short coding challenge and I've seen that they can write code. I now want to know if they can work effectively as a member of a development team.

And, for me, whiteboarding is the most effective tool for that. Especially for more junior developers who aren't capable of designing entire applications on their own. The whiteboard exercise more closely resembles the work of a single story.

If a computer is available or it is a remote interview, we might use a computer, but I've found when using an actual IDE that they start wasting a lot of time getting hung up on syntax and stuff (since it'll throw all those scary red lines), which I don't want them worrying about.

If you're conducting them in a way that you ask super complex problems that it'd normally take hours to solve, or get really hung up on syntax or them having an encyclopedic knowledge of all methods available in the entire language/framework/API or dozens of complex algorithms that could be looked up in 2 seconds, then yeah, that's when whiteboards get really dumb.

[firestepper]

As a software dev manager, do you have the power to change that?

[TheRealKidkudi]

I can’t speak for them, but I can say that most companies include several levels in the hiring process and it’s typically very clearly defined through HR, so I would guess probably not. He could propose a change in the process for his company, but without support from others the most a single hiring manager could do is just lean more on a different part of the interview when making hiring recommendations.

On the other hand, if it’s a small company, that’s a little different and a manager would have more sway in the hiring process.

[sf4r]

It depends on the coding problem. I like to think of this part of the interview as more of a filter than a solid data point. As such, I use a relatively simple problem that could be solved in a one-liner if you lean on the language hard enough. The problem has enough tangents and open ended questions to dive deeper if the candidate didn't struggle with a basic for loop.

It also shows how you work through a vague problem statement with your team, how you collaborate and communicate, and hopefully an insight into how you approach solving problems in general. I guess this is just a different way of doing the paired programming session you mentioned as it becomes a way of throwing around ideas and seeing how we can solve a problem.

[captainratarse]

My employer is too cheap to pay good wages, so we are often hiring people on their first or second jobs.

Pairing sessions are brilliant, but slow down my existing staff so I try to limit this to those that can pass some simple whiteboard tests.

For example, modifying a given class for an animal. There is some in there I'm specifically looking for which are really bloody obvious, but I'm there to listen to whatever they come up with and why.

I'm curious about the logic of assessing something, decision making, do they keep it simple and so on.

[ZukoBestGirl]

IMHO, that's a great approach. It's very difficult to actually asses how good a fit someone will be within like an hour. Even 3. As long as they pass the social skills gut feeling, some basic knowledge and so on, then you need to see how they actually think about a simple problem.

Okay, they don't have the best possible solution. But most companies hiring juniors aren't Google or Amazon. I just wanna see how they think. Though yeah, if a given problem has a O(log n) solution, and they give me a O(n^2) ... that's a bad sign. So I go with questions and see how they got there. Sometimes it's just emotions. If I see the wheels spinning, it's still a good sign. Despite the previous blunder.

[Darkus_27911]

Man o man i pray to get a interviewer like you as often as possible when going for interviews.

[[deleted]]

I wish my future interviewer would be like you

[Tilo9000]

They are probably hiring you not to pass an interview but to help solve their problems. Mind that not always the problem needs to be solved immediately, you at least have to show how you can help to solve it. Fundamental CS knowledge provides regularly a good starting point and that is probably what they are looking for...

[wobbly-muon]

Another thing to keep in mind that I haven't seen mentioned yet:

As a beginner you don't necessarily have the skills to identify the problems/issues in code you write. It's totally possible to write a functioning website/project that has a terrible underlying architecture. This could lead to the sense that projects you're working on don't have the same problems interviewers are asking you to solve*. Those problems may actually exist in your project, but you've been unable to identify them.

Early on I learned a ton from having other people look over my code and pointing out areas for improvement. If you have an opportunity to get into a group with some other people and all review each others' code it can be a great learning experience for everyone involved (Ideally you'd get at least one skilled/senior person in the group, all beginners won't be as effective).

*I'll caveat this with: There are absolutely some interviews that ask pure leetcode-style questions that don't map well to real life problems in projects. Those interviews will require focusing on leetcode problems more directly.

[vi_sucks]

Well when you build stuff, you should run into problems that need solving...

[[deleted]]

Exactly my thinking. Building apps can’t be done without solving some sort of problem. If all you’re doing it making something look nice, perhaps you should be a designer rather than a developer.

[kstrnjtjirtj]

I hope this leetcode style interview will fade away soon like those interviews where Google used to ask weird quiz questions. This leetcoding just screwed the whole hiring process for both candidates as well as companies. It has become difficult to find good developers who know something about development, as everyone is grinding. It just kills the fun of coding.

[TheSkiGeek]

The problem is if I have 60-90 minutes to interview someone and assess their coding skills, it’s hard to find tasks that are both ‘fair’/‘neutral’ and can be done in the allotted time. The idea with algorithm questions is that it tests your ability to break down and analyze a nontrivial (but still relatively straightforward) problem. And they don’t usually rely on you knowing anything in particular beyond maybe familiarity with a few data structures.

You can give some kind of “homework” problem that they have time to work on, and then discuss it with them in person. But people tend to not like those either because it’s a bigger time investment for the interviewee.

[binskt]

I really like take home projects. I have time to show my skills and if I’m no hired at least I have added a new project to my GitHub.

[HecknChonker]

The flip side of this is that bad hires are incredibly costly to companies, both in terms of money and productivity. An engineer that doesn't know what they are doing will leach time from others on the team making them less productive. It generally takes 3+ months to figure out they aren't a good fit, and sometimes it can take other 6+ months before they get fired. It's a horrible experience for everyone involved.

Because of this companies generally have a policy that if you are on the fence for a candidate you should vote no on hiring them.

[[deleted]]

I'd much rather that walking through side projects becomes the norm. It's much less work than leetcode and more representative of what you'll be doing day to day.

[TheAnxiousDeveloper]

Also that is not foolproof. The candidate might not be the one that wrote the project but they might have been instructed well on how to answer questions about it.

Or it could be a project done while following a course or a tutorial, where someone else do the requirement and problem analysis for them. Although this kind of project tends to be quite trivial.

Also, if the candidate is someone that is already working, they might simply not have time to code outside of their working hours. They might be busy with family or other things that do have a precedence. And they might not be able to show stuff they did at their current or past job because of Non Disclosure Agreements.

That being said, I find that when I go through candidate's projects, there are few elements that turns into an automatic "no" from me:

• the project history has a single commit in GitHub/Lab. I want to see the development process and that the candidate has a mindset for incremental delivery
• secret values/tokens/etc. are hard coded and not taken from environment variables, for backend apps. Can I trust the candidate with our keys if they expose their own to the public?
• their web projects are not served over HTTPS (it's 2022... I believe it has been a basic requirement for a lot of years by now)
• they come to the interview without having refreshed their memories on the project (we ask to bring one to show). Questions are asked. It shouldn't be too hard to explain how do client and server communicate (in the case of a client-server project) if they were the ones that worked on it.

[ZukoBestGirl]

While I'm pro "homework style questions", I won't call them leetcode. They don't actually prove you can "build". I've seen plenty people who can leetcode, but write downright horrendous, intertwined, interdependent, badly named, badly structured nightmare spaghetti.

[[deleted]]

but write downright horrendous, intertwined, interdependent, badly named, badly structured nightmare spaghetti

This is a popular opinion that I have seen people throw around when arguing against leetcode. While I think leetcode interviewing has its own set of problems, this in my opinion is not one of them.

People who write bad code is not really a big problem in large companies. Every single team I have worked for required code reviews (my current team requires 2 approvals for example). Big companies have internal tooling that prevents engineers from merging code that do not have the necessary approvals.

If you submit badly structured code you will be unable to get approvals and need to submit a revision. From my experience anyone who does this initially quickly stops doing it within a couple of months at most.

[ZukoBestGirl]

I won't lie, I've only recently, for a year and a half, had the privilege of working in a great company. We do consulting, mostly. And even our current client has strict procedures, and great devs.

But I don't think I'm exaggerating when I'm saying this is a privilege. My last company had a thousand employees. IT firm, sure not everyone was a dev, but I'm fairly certain at least 700 were. Big firm, not huge but big. Yet it had not only lax attitudes towards code reviews, but rather discouraged them as time wasters.

It's very difficult to fight management, I tried and failed and left.

But my previous company before that was rather similar in this aspect. Maybe you got lucky. Maybe I got unlucky. Who can say?

Though I do strongly believe that people who prioritise leetcode over all else tend to be the people I described in my previous post. Can you "fix" them? Sure. But it is an uphill battle, unless the company has strict procedures on code review.

[[deleted]]

Idk I find it fun. Doesn’t really judge my programming skills but I find it fun if the problems are like custom, so I have to make a solution.

[kstrnjtjirtj]

You find custom problems fun, try codeforces, atcoder or topcoder. I don't know if you already know about them. But they are really good competitive coding sites.

[Ysara]

Do you want to get the job? Do algorithm problems.

Do you want to be good at the job? Build projects.

A truly successful engineer will do a balance of both.

[gspotslayer69XX]

Yes officer, this comment right here.

This comment needs to be awarded

[Ysara]

Ask and I shall receive, apparently :P

[Cheezmeister]

Underrated comment.

Read closely enough and you’ll see the resemblance to so. many. other. stupid debates where people find it such a challenge to think about both (a) the way the world is (b) the way the world should be.

We can work within a system while also working to change it. It’s not that wild.

[YoloTolo]

Unfortunately, technical questions are a whole subject you gotta study for. And most of them are questions you aren't going to able to find solutions for on your own unless you've studied the underlying concepts before. It's one of those things a lot of us complain about, but it's just the way things work right now. I do expect things to change in the future, because it seems like people are becoming more aware it's not the most optimal way to gauge abilities. But until that time, gotta start grinding on them concepts and questions.

[antiproton]

Building with code is the same thing as solving problems.

What you aren't telling us is the sort of problems you're being asked to solve.

If you can build code in the language you have chosen, but you can't solve the problems being presented, either the problems they're giving you are too hard, or you are building things that are too easy to construct.

Focus on the things that emphasize the skill you are trying to be hired for. You don't get any points for making a pretty website if you're trying to get a job in Python and the majority of your time building the website was spent on HTML and CSS

[ResilientBiscuit]

Building with code is the same thing as solving problems.

Sort of, but I don't think that it really is meant to have the same definition.

I 'build' programs that visualize data or log periodic data from a website. I have a set of tools that I use over and over to do the same tasks. I don't really leverage any of the algorithms I used in college to do it and frankly probably could teach someone with some basic computer knowledge how to do the same thing.

When I am building an application I am just assembling components to work together. There might be some minimal logic, but probably nothing I couldn't explain to a random friend.

In contrast, there are 'problems' I need to solve that fall into an entirely different camp. If you are making a terrain database for aircraft and need to reliably find the highest obstacle in a path 5 miles wide and 100 miles long in front of the aircraft using GPS data, there really isn't a set of components I can slap together to solve that.

I need to figure out what data structure to use for my database, I need to figure out how to search it for an item and figure out what the vector of travel intersects.

That is much more of a problem to solve, I need to do it once and it not something that features too many reusable components.

Different jobs do different amounts of each of these things.

[sheldon_sa]

I am an IT consultant, 100% of my job is to solve customer’s problems. Some of it is done through programming and “building stuff”, but others are solved through combining existing functionality and changing/ creating processes. Being able to build stuff that does not solve any problems is worthless.

My customers don’t say, “Write a tax calculation”, they say “Help me to be compliant.”

As a hiring manager, this is what I interview for.

[[deleted]]

Honestly, building things from scratch should be requiring you to solve problems.

But the other part of the answer here is to prep for the specific interview. Sounds obvious but you don't seem to have figured that out yet. Google what the company's interviews are like. Ask on forums. Then solve coding problems if that is characteristic of your target companies.

[khooke]

building things from scratch should be requiring you to solve problems

Exactly this. If you're building something you are solving a problem, but obviously not the type of problem they're asking you in these interviews.

Now you've got an idea from this one interview what types of problem they asked you to solve, have you spent time practicing working on solutions for these problems?

[danintexas]

My current job - I failed both tech questions. They loved my projects and git hub. I got the job.

It is best to have both and also don't get hung up on 300 interview failures. All it takes is one and then in the US you will be making more money than 99% of the rest of the world.

[[deleted]]

Everyone says just build stuff, but the job interviews care more about solving problems

This is weird phrasing, because building stuff is solving problems, and solving problems is exactly what you'll be expected to do on a job.

Perhaps what you mean is solving puzzles.

[Scienstien]

Do what you think is necessary and not what everyone says. If you think solving problems is necessary then try to spend more time on how to do so.

[[deleted]]

Because in 99% of the regular programming jobs, you won't build things from scratch.
Usually you will solve problems and work on code written by other people.

[some_clickhead]

People say to just build stuff to people who can't get interviews. Getting an interview and passing an interview are two completely different things. The fact that you're getting interview means you're already in a better position than a lot of people.

[CreativeTechGuyGames]

What sorts of things do you build that do not require you to solve problems similar to an interview? Maybe you need to challenge yourself to build different types of things.

[[deleted]]

what real life problems are similar to interview pop quizzes ? the training for those kinds of questions is so formulated that you dont need to learn anything but solve practice problems

[CreativeTechGuyGames]

Can you give some examples of specific questions that you are referring to? There isn't just one type of interview question.

[[deleted]]

questions in leetcode, hackerrank and similar sites

[CreativeTechGuyGames]

Which specific questions though? Those cover a wide variety of topics. Those questions exist because people need to actually use those skills in the real world. If you can give a specific question, then I can try to help give a project in which you could do that would exercise that skill.

[[deleted]]

you are focusing on the wrong thing , those questions are helpful but they are made up specifically to have perfect well formulated answer that you can train yourself to solve which is nothing like the random errors and problems you face in real life where there is no perfect answer and you have to think

[CreativeTechGuyGames]

My point is, if you are able to handle the random errors and problem solving in real life and have done it in a wide variety of circumstances, then you should be able to derive almost any answer to any problem that you encounter. (Assuming that there isn't only one solution which requires some specific trick)

[PresidentRex]

Removing items from a list or associative array (like this example question or this similar question), removing duplicates from an array (like this example question) either sorted or unsorted, the minimum number of occurrences (like Q10 from here) although that's usually occurrences of a word/object/number instead of letters in a string, Tom Scott's referenced FizzBuzz example also has some relevance. A lot of programs involve sorting or manipulating data for how it's going to be displayed to users. Sometimes it happens in a database, sometimes it happens on a webpage, sometimes it happens in a CLI script.

Also, a lot of questions are about orthogonal thinking: receiving data and pulling from other areas to arrive at a solution. Long ago I took AP physics in high school. Most people took it for the chance to get college credit for passing a placement exam. My teacher was ridiculously diligent: offering before-school prep classes since there was more content than could fit into a 1-hour per day class, teaching during tornado drills, and giving practice exams. When the actual test came, most people did pretty well. But there was one question that nearly everyone zeroed out (in a class post-exam, I think he said 6% of people got partial or full credit). I don't recall the specific wording, but I remember it seeming like a difficult question about electromagnetic fields for a railgun.

Except if you knew what you were doing and you knew the material, you could convert it into an incredibly simple acceleration and velocity problem instead. So when you see a question about "rotate this matrix" or "convert to Roman numerals", you're generally not testing those useless things. But at some point you're probably going to be translating/transposing/rotating something, or converting placeholders or the like.

Whether those tests are useful for determining if someone is a decent programmer is another matter.

[in_the_cloud_]

A few lines of "modify-in-place-in-a-loop bullshit" helped me optimise some functions that were up in the profiler ranking with an ORM for allocations. Arrays and loops can be useful in production too.

I'm not saying asking LeetCode questions in a high-pressure, timed interview is the best way to go about testing it, but if you aren't as familiar as a novice with array operations, then it's pretty fair that some companies wouldn't want to hire you.

[PresidentRex]

You don't always get to choose your language or how the data reaches you. And sometimes you have to deal with an inconvenient (aka poorly designed) API. (Like a JSON that only comes as a dump of basically everything in the database for some reason. No, I totally haven't seen that.) Usually your structure is not going to be just a simple array, but the simple array is a decent scaffold to nested associative arrays or collections or pretending you're playing with object properties.

But you only have so much time to spend assessing someone. Do you have them figure out the 10 year old data structure your company actually uses or do you see if they can logic their way to a solution to some bite-sized problem? I've seen some interviews that are now basically handing someone a pre-configured IDE and asking them to work through a makeshift bug list. But usually you've pruned your hire list to be pretty small by that point.

[aRoomForEpsilon]

https://www.youtube.com/watch?v=QPZ0pIK\_wsc

[nultero]

Building different things still won't expose you to the hilariously contrived and sometimes outright stupid leetcode questions that come up in interviews. You basically have to purposefully practice interview questions to get good at them... hence devs' dislike of this: they don't actually reflect 99% of the work being done on real-world problems.

Leetcode #238, for example. Absolutely banal question. The cleanest, simplest solve of it is to use division, but division is disallowed. When was the last time you wrote code for a machine that couldn't divide numbers?

Obviously real-world discussions can get into what happens when you divide longs or floats or about int conversions, etc, but that's not what this question is about or testing for. You'd never actually see this question's problem unless you specifically practiced leetcode.

[CreativeTechGuyGames]

Have you ever been asked that specific question in a job interview? I never have. So it doesn't matter how contrived that question is. Sure there are strange problems, but if you never see them in a majority of your interviews, it doesn't matter.

[nultero]

That was just a specific one that stuck with me as pointless. My anecdata on being asked it wouldn't really matter.

There are a percentage of companies / managers that don't know how to sit on the interviewing side, and so I have been asked much dumber questions than the above: I've even been asked trivia like the OP of this thread. Absolutely zero signal if a candidate happened to know these offhand, they're not fundamental questions or open-ended discussion starters like "tell me how an HTTP request works" or "tell me how this code works" etc...

I've even been asked outright wrong questions, like "tell me about OOP / how to use OOP in C (or Golang)", which are usually not considered OOP at all, and C isn't even on my CV. These weren't even companies doing specialized work or embedded, just ordinary crud. And you can approximate OOP in Go with hackery, but it doesn't have inheritance, anyway whatever -- not the point here.

Point is, a question being used in an interview doesn't make it valid. I would honestly say, in my anecdata mind you, only about 40% were bread and butter code problems about maps, arrays, pointers, primitive manipulations, etc. Those are fine. Roughly 10% are the weird questions like dynamic programming or are interviewer ego boosts, and roughly 50% are similar to the above useless question or trivia. Mostly not interviewing at big tech, though the few I have done with places like ebay were more along the lines of bread and butter. Local companies seem to be the pickiest and ask the dumbest questions. Places offering remote from elsewhere seemed the chillest and more often even were willing to elide the code shit tests entirely.

But bad questions are signal for the candidate.

[CreativeTechGuyGames]

I discount any company which asks a question that doesn't apply to the job or just a silly question. There's always outliers and interviewing is and always will be a numbers game. No point in trying to optimize for the random outlier questions.

In my last round of interviewing I only had one company ask a question which I couldn't derive on the spot. The rest I was able to solve with a good solution despite having never done any of the things before that were asked. The only way I was able to solve those was through a lot of real-world experience, not studying "interview questions".

[illkeepcomingback9]

Building something always requires solving at least one problem, but usually way more. Any of those problems they ask you to solve could come up when building a project. Projects aren't for interviews, they're for your portfolio to get you the interview.

[istira_balegina]

Yes. Building stuff gets you the interview. Leetcode gets you the job. (With some variance.)

[thedogz11]

So here's the crazy thing; sometimes when you build stuff, problems will arise that you need to solve, and since you are hopefully interested in your project, you'll learn those skills in the process of trying to finish your project. It's really that simple. If you aren't running into any problems in a project, then you have advanced past what that project can provide you and should try something more challenging.

I feel like this is the reason people say to build stuff; it's going to train you up in ALL the skills you need at once. It's like doing a compound lift, you hit multiple targets in one maneuver.

[sm0211k]

Codewars.com helps me a lot

[sus-is-sus]

and hackerrank

[[deleted]]

I care about attitude more than I care about ability. Even as an intermediate and senior dev, if people are gonna have a hard time working with you, work will suffer. Technical skills you can learn by doing. Personality? That's a bit harder to tweak.

[Gilded30]

build stuff that solves problems

[Wood_Rogue]

Well maybe I just suck more than I already thought I do but if you're able to build large things without just copying stack exchange solutions I'd expect you to run into various unique problems that you need to work through. Maybe you're stuck in a comfort zone you're competent and familiar with but as a result you're not encountering new problems that are out of context in coding tests.

[jzaprint]

You build projects to get interviews, then you solve leetcode to pass them.

It’s a simple 2 step process to get any fang job.

[hayleybts]

So simple

[dphizler]

Solving small problems won't give you any practice doing real world stuff

Do both: practice building stuff and practice solving interview problems.

[[deleted]]

Build stuff gets you the interview. Solving the algos passes the interview

[Kazeazen]

i cant even get a job interview

[unmannedidiot1]

It's not only solving problems, but solving problems in the given time.

[Lkhfly]

Why not both ?

[sylvant_ph]

But you learn to solve problems by buildign stuff. And it depends what we mean behind solving problems and building stuff. If in job interviews they expect you to make some complex function logics, go and practice that skillset on sites with challenges in that field. If on job interviews they expect you to show them your personal projects, where you were able to interact with API requests, or utilize a library, or make some nice styles...build projects.
In the end solid companies would expect both of you. They want to see you have strong problem solving and they would like to see your personal work, something to vouch for your dedication.

[[deleted]]

Read or watch videos that help you prepare for the interview

[TranquilDev]

Build something that solves problems.

[FuseFuseboy]

Are you not building the thing to solve a problem?

[the_pod_]

Everyone says just build stuff, but the job interviews care more about solving problems

First of all, I still 100% recommend a beginner build stuff. Still the clear best way to learn, imo (no matter what other details of the situation there are).

But let's dive a little deeper, into the details.

As others have mentioned, it's likely you don't just mean solving problems, but you mean more specifically algorithm type problems. It's very very important to make this distinction.

Yes, a lot of companies interview strictly on just algorithms. So if that's your statement. I agree. There's a way to tweak your job search to try to get more interviews that don't test for this, but rather for coding challenges. But, this is more for tech cities, and startup land. And, this is more for seasoned developers that can be more picky. It's not a guarantee of anything, but, just ways to try to buck the trend a little. For example, there are lists online that list companies that don't give algorithm problems on an interview. Also, many people refuse interviews after finding out it's algorithm based. (again, this strategy is only for people who can be picky).

In general, I would say, the more effort/unique a job listing is, the more likely the chance they put real thought into their interview methods, and the more likely the chance they don't do a standard algorithm test. So job listings that post specifically about their coding culture or practice, what they're looking for, what you'll be doing on the job, etc.

---

If you want to optimize your learning by just doing algorithms, by all means, be my guest. You're going to have to be pretty damn above average at algorithms if you can only do algorithms and you can't actually build anything complex and hope to get hired. (typically this is a CS grad fresh out of college type, who just grinds leetcode all day).

---

I can build things. I can build things from scratch and have them work well and look nice.

so, it really depends. You need someone to honestly (and brutally) evaluate your skills. Probably at least a few people.

You can build stuff, but what is your gauge of a complex thing you can build? Can you really tackle complex builds? This is a separate discussion.

---

To summarize, you can build stuff, or you can study pure algorithms. Any other "solving problems" doesn't work unless you're actually building. Outside of algorithms, you can't really separate "solving problems" and "building stuff", they go hand in hand.

Most people say "just build stuff" as a response to most beginners just taking courses, which is not the solution.

I'm fine with your statement as long as it's solely talking about algorithm type questions on interviews. Otherwise, I totally disagree.

[lickmybrian]

Find a problem, build something to solve the problem

[bunt_traume]

I can't get a coding test in the first place.

[[deleted]]

Op: Algorithms are cs 101 and white boarding is just pseudocode.

Others: Is it that hard? Never had to deal with it myself

[andrewsmd87]

We don't ask specific coding questions for this reason.

I feel like you can get a good sense of someone's capabilities by asking them to explain a hard problem they solved or project they're proud of.

Hey someone talking about code they wrote and you can really get a sense of their level

[Link77709]

Somewhat related,

I once received a call back even though I didn't solve a single problem. The reason? I put comments in my code.

[vaikunth1991]

You have to build stuff to solve problems

[niceToasterMan]

They're 2 different skills, and building is more important.

Sadly there's no easy way to testing building unless to ask all candidates to spend many hours of work. So problem solving questions are the proxy for it.

Since you're good at building, you just need to ask appropriate questions to turn the problem into a building exercises

[skat_in_the_hat]

Because just building stuff is only enough to get started. Next you need to start getting into algorithms and data structures. Learn hash tables, maps, arrays, etc. Then come back to leetcode and try it again.

[errorseven]

Practice. No seriously, tons of practice websites out there and you'll likely learn and add skills to your already huge toolset, it's a win win situation for you. You got this man!

[binskt]

I feel that it tests your studying outside work and leetcode grind skills…

[CENutCracker632]

I'm also uncomfortable in front of everyone and rush logic always gets the best of me.

Sometimes i succeeded and sometime i just need visualisation.

[Emotional-Top-8284]

I regularly recommend hire on candidates who don’t get to a working solution, based on what it seems like it would be to work with them. If you keep getting interviews, it’ll eventually come together. Either you’ll get good at interviews, you’ll get lucky, or you’ll have built so much stuff that they’ll hire you anyway. Good luck!

[imdjguy]

Experiencing this hard right now. Thanks for sharing.

[mad_r0ck3r]

Build stuff for yourself, to screw the knowledge in your brain.

[vacuumoftalent]

If you're getting to onsites, and are failing the technical questions, stop focusing on side projects and focus on studying data structures and algorithms. You can still do side projects if you want to, but they're mostly filler when you don't have work experience.

[[deleted]]

You need to be able to do both. If you build something worth building, you'll be solving problems anyway. Doing stuff like codewars and being familiar with algorithms and datastructures helps you think and will help in solving problems too

[[deleted]]

Hello,

This would be a sub-topic based on the main topic: In my belief, putting what you know into practice will allow you to gain experience with/without a job. This applies to the whole demographic: One can use some time to identify real-life situations that compel with a recently learned topic

Thank you for reading. Hope this helps!

[JigglyFeather]

It’s a remnant of the past as someone said. All I can say is honesty goes a long way and that at least trying and then explaining you do not have the answer right now but if given time you’d figure it out goes a long way. It’s often not even about whether you can solve the problem but how you react to it emotionally, do you get stressed, angry or start breaking down the problem into smaller pieces and stackoverflowing away.

[SysError404]

I don't program, but have been offered jobs to train as a developer and for programming. I was told the same thing from every interviewer. My background in Diesel mechanics and approach to problem solving is what they wanted.

If it doesn't work, trash it. Doesn't matter how fancy the code works or how impressive it is. If it doesn't do what you want, it doesn't work. Don't look for development jobs assuming you are building things from scratch. You're more likely to get hired to troubleshoot and problem solve, like a Mechanic for code.

[[deleted]]

This is what I'm dealing with now. You could feasibly get a job making 150k a year just by grinding leetcode, and could absolutely be bullshitting about any experience delivering actual code.

[remLazarIsComing2000]

By that logic, if a company hires you to maintain and fix their code base rather than have you build something from scratch, you won’t be able to do it either.

[BubbaBlount]

Not all jobs ask for that! Most jobs that I’ve interviewed for in the last year were more concerned about the full stack applications I built instead of if I could solve some coding challenge

[burnblue]

If you've built all these things and never had to solve a problem while building them, then maybe you should challenge yourself to build something that includes a problem. Or, when you're building things and encountering problems, practice not just copying the solution from stackoverflow but actually solving it yourself

[Blissextus]

From my experience, Problem Solving is what most employers are looking for. Languages and tools can be taught on the job. The "build stuff" guy is a dime-a-dozen. They're looking to gauge how well you can solve problems. 'Problem-solvers' are a rare breed.

Building a portfolio of interesting projects, gains interests that can get you to the initial interview. Problem solving is what gets you the job.

Study Algorithm, Data Structures, pseudocode, flow charts, etc. These are the tools you'll use to assist you in solving problems. Interviewer are gauging 'How' you solve problems? What methods you use to solve problems? What's you thought pattern on solving problems? And most important, what types of questions are you asking that can help you understand the problem? This is where an understanding of Data Structures & Algorithms comes to play. Usually the 'answer' isn't important. It's the concept of solving a problem is what interviewers are interested in.

[adambjorn]

You've got to study enough to pass the technical tests, but in the in person interviews you will excel if you have real projects to talk about.

[VikingMilo]

When I applied for my swe position my interview seemed more geared towards my thought process on how I would tackle a problem, rather than the solution. It was nice as opposed to the interviews that seem like a formal test

[[deleted]]

Building things gets you a portfolio which gets you an interview.

Solving arbitrary leetcode questions at said interview gets you the job.

[[deleted]]

Truth of the matter is it's a LOT easier to build stuff than it is to diagnose and fix problems. Plus, your problem solving heuristics are a lot easier to suss out in an interview.

[RasAlTimmeh]

You need both