Programming thread

  • 🐕 I am attempting to get the site runnning as fast as possible. If you are experiencing slow page load times, please report it.
I have a scenario, let's say you own a tech company or creating a project, and you're looking to hire a programmer to work with, what is your general ruleset or requirements to prove if the new hire is a good candidate that you can tolerate with? How do you know if the person is not creating pajeet/spaghetti code or know how to make memory-efficient scripts etc etc?
 
I have a scenario, let's say you own a tech company or creating a project, and you're looking to hire a programmer to work with, what is your general ruleset or requirements to prove if the new hire is a good candidate that you can tolerate with? How do you know if the person is not creating pajeet/spaghetti code or know how to make memory-efficient scripts etc etc?
Anyone who has evolved past being a skiddie will be able to switch coding styles and adhere to API conventions, as far as capability. The main concern for me would be their personality, like, how working with them would pan out.
 
I have a scenario, let's say you own a tech company or creating a project, and you're looking to hire a programmer to work with, what is your general ruleset or requirements to prove if the new hire is a good candidate that you can tolerate with? How do you know if the person is not creating pajeet/spaghetti code or know how to make memory-efficient scripts etc etc?
Interviewing is an art rather than a science. You can always give them a take-home project but the trick is make it something they can't stack overflow or ChatGPT.

I rarely ask language specific questions, because I usually don't care. I prefer to ask theory or concept questions. If they always keep coming back to things like "Well, I'd use library X in my_favorite_language" then they're probably not the skillset I'm looking for.

Also, give them pseudo-code and ask them to look at optimizations. Make them big obvious ones not subtle brain teasers. Like make an O(n^3) routine that could easily be O(n) or O(n^2) etc.

Obviously this is vague.
 
Interviewing is an art rather than a science. You can always give them a take-home project but the trick is make it something they can't stack overflow or ChatGPT.

I rarely ask language specific questions, because I usually don't care. I prefer to ask theory or concept questions. If they always keep coming back to things like "Well, I'd use library X in my_favorite_language" then they're probably not the skillset I'm looking for.

Also, give them pseudo-code and ask them to look at optimizations. Make them big obvious ones not subtle brain teasers. Like make an O(n^3) routine that could easily be O(n) or O(n^2) etc.

Obviously this is vague.
When I've interviewed, I try to be up front about my limitations but work around them. If they ask me a question I don't know off of the top of my head, I own up to it, but I try to demonstrate my ability to adapt to and consume new information. From what I've seen it has been effective, but I'm curious if I'm on the right track
 
When I've interviewed, I try to be up front about my limitations but work around them. If they ask me a question I don't know off of the top of my head, I own up to it, but I try to demonstrate my ability to adapt to and consume new information. From what I've seen it has been effective, but I'm curious if I'm on the right track
Yes. This goes both ways. If you don't know an answer don't just say "uhhh, I dunno", tell me how you'd figure it out, and not just "Google" or "ChatGPT"

"Library X is doing Y, how do you fix this?" "Well, I've never used Library X, so I'd go to their documentation for that function and read it again, then I'd go to the issues page on their github and see if this is an open or closed bug, then maybe I'd look at the code and see if I can understand what it's doing."

But it's also on the interviewer to not ask retarded closed ended questions. "Have you ever used python" bad. "Tell me about a time when you had to learn a new language or API and how you dealt with it?" good. I often interview for systems admins, one of my favorite questions is "Tell me how a system boots", I get answers ranging from "Well, I turn it on and get a login screen" to people who talk about power up, BIOS, UEFI, finding the bootable device, grub, kernel, initrd, systemd, etc. You can guess which one gets hired, but even if they don't know the detail, they can walk through what they do know.
 
I have a scenario, let's say you own a tech company or creating a project, and you're looking to hire a programmer to work with, what is your general ruleset or requirements to prove if the new hire is a good candidate that you can tolerate with? How do you know if the person is not creating pajeet/spaghetti code or know how to make memory-efficient scripts etc etc?
Check out their portfolio, see if there's anything there that makes you want to scream.
 
Interviewing is an art rather than a science. You can always give them a take-home project but the trick is make it something they can't stack overflow or ChatGPT.

I rarely ask language specific questions, because I usually don't care. I prefer to ask theory or concept questions. If they always keep coming back to things like "Well, I'd use library X in my_favorite_language" then they're probably not the skillset I'm looking for.

Also, give them pseudo-code and ask them to look at optimizations. Make them big obvious ones not subtle brain teasers. Like make an O(n^3) routine that could easily be O(n) or O(n^2) etc.

Obviously this is vague.
In my workplace they just tell the people they advise using ChatGPT and increase the workload. It's pointless to try to go around it.
 
I've found copilot immensely useful for helping me to write boilerplate code that is fairly tedious to do. I don't let it do anything that is complicated enough for me to have to sit and read it though. ChatGPT is nice because it's basically stackexchange but faster and with less snark.
 
  • Like
Reactions: Jarry Seinfelt
Bois I was working on a project with a buddy who was supposed to be handling the UI, but he hasn't done a single thing in months. It's in Python and I've been using just jinja, HTML and vanilla javascript because looking at any single framework user makes me want to hang myself by the balls from the tallest building I can find and yodel my way down once the sack finally rips.

So what do I do? Do I continue in the 3 above and make my own shit? Ultimately the look of the page is just css, so does it really matter, do I really need the premade stuff React has? What would be some things that I could benefit from not doing myself? Couldn't I just use standalone libraries for those things to not have extra bloat? Let's say you want to make your own Portainer interface, what could you use from React that would be better than diy/standalone libs?

I'm not trying to hate on it, just want to learn. Could use an explainer. I'm a seasoned dev so I don't need any reddit "eli5" shit, it's just that I never see these React influencers actually programming and I don't care to read random codebases so I am genuinely clueless. I don't even know what React is. How do I React? Do I watch a youtube video, pause every 5 seconds, say "haha that's true" and I magically get a user interface?

I figured React might be best to go for as I can just hook it up to whatever REST api and I could use it on my resume to impress all the single companies in my area. Other suggestions are highly appreciated of course.
 
  • Feels
Reactions: y a t s
If you do any of the following:
-Program in C/C++ or ASM "so that you can understand how a computer actually works"
-Say the words "data structure"
-Write your own shit instead of using a modern free framework
-"Ironically" use a 1970s text editor
-Never released a project but have the exact same NPC 50 walls of text about software license drama
-Use BSD, Plan9, Haiku, or some neo-hipster faggot poseur OS
-Read SICP/The C Programming Language
-Write your own algorithms that run 5% as good as ones from 20 years ago

Then YOU are on your way to becoming Kiwifarm's next biggest lolcow!

Get off the fucking welfare and get a job. Better yet kill yourself
 
Bois I was working on a project with a buddy who was supposed to be handling the UI, but he hasn't done a single thing in months. It's in Python and I've been using just jinja, HTML and vanilla javascript because looking at any single framework user makes me want to hang myself by the balls from the tallest building I can find and yodel my way down once the sack finally rips.

So what do I do? Do I continue in the 3 above and make my own shit? Ultimately the look of the page is just css, so does it really matter, do I really need the premade stuff React has? What would be some things that I could benefit from not doing myself? Couldn't I just use standalone libraries for those things to not have extra bloat? Let's say you want to make your own Portainer interface, what could you use from React that would be better than diy/standalone libs?

I'm not trying to hate on it, just want to learn. Could use an explainer. I'm a seasoned dev so I don't need any reddit "eli5" shit, it's just that I never see these React influencers actually programming and I don't care to read random codebases so I am genuinely clueless. I don't even know what React is. How do I React? Do I watch a youtube video, pause every 5 seconds, say "haha that's true" and I magically get a user interface?

I figured React might be best to go for as I can just hook it up to whatever REST api and I could use it on my resume to impress all the single companies in my area. Other suggestions are highly appreciated of course.
Python faggot thinks he can write better frameworks himself, ends up not doing so and just sitting there and wasting time. You don't say
 
Creative Username said:
TL;DR: You're going through a stupid phase that a lot of programmers do. Just write things and if they're slow make high-level logic changes that improve performance by 800%. Learn data structures and algorithms. A program with good algorithms written in Python will run faster than a bad one in hand-optimized assembly because the bad algorithm has to do exponentially more operations the larger its input is.
You're not a programmer fag you're just jerking off in C and pretending you are smarter than everyone else for repeating the same NPC tier C shit that all C niggers do.

The one going through the "phase" is you. Actual programmers use modern langs and actually make money. You're just gatekeeping and trying to get less people programming, as all C niggers do.

Data structures and algorithms are for faggots since all of this has already existed for free since 2000 and you can't make better ones.

Nobody gives a shit about code speed when you have unlimited memory and caches because it's not 2005 anymore and we have the cloud and it's worth more business value to put development time into new features since all you can do is just bump up the server resources and they pay another $10 a month.

C and doing it the 1970s way is for fags looking for a timesink to fill the giant void in their lives that should have been occupied by the job they should have gotten. It's not 1990 anymore and you are not gonna change the world with your shitty C programs.
 
Embedded pays way fucking more, get better bait
Embedded is a C autist tard fantasy. Another stupid line that all C NPCs say.

They aren't going to hire you over a 60 year old with 40 years of experience.

Also it's a timesink and you will have to dedicate 8 actual hours of work per day, meanwhile any OOP job is remote and you do 30 mins of work per week for $100K. Since you are remote then you get another OOP job and make another $100K for another 30 mins of work per week.
 
Back