|
Miss Broccoli posted:They said from a culture standpoint I very easily scored in the top 10, and the feedback he really hammered into me was "you have great technical skills, you were let down by how nervous you were at the start, but you have nothing to be nervous about". Which yeah I was making GBS threads myself at the start, and kept locking up out of anxiety, once I started getting the ball rolling and started getting feedback that I was doing well I smashed the the rest. Did you get the position despite this?
|
# ? Apr 29, 2022 22:40 |
|
|
# ? Jun 3, 2024 21:06 |
|
That sounds backwards to me. How do you find problems that fit your languages feature set? Python's great as a stepping stone up from cmd line grep/sed/awk lines into something slightly more formal. Are you ever looking at a text-munging problem and dreaming up the type signatures instead of just.. like.. bashing the letters around?
|
# ? Apr 29, 2022 22:42 |
|
leper khan posted:If you're looking for a language with a useful type system, why would you ever look at go? I choose go entirely because I didn’t know C yet and wanted to learn how to write a reverse shell that could actually work in the real world on windows. I wish I learned C way earlier while I still can’t make much useful in it without tons of time or help it forces you to understand how computers actually work so stuff like “why would a string of a large number take more memory than the integer” is just obvious to anyone like 30 minutes into a C tutorial while even a lot of experienced high level language guys may not know because they never need to know.
|
# ? Apr 30, 2022 00:54 |
|
JawnV6 posted:That sounds backwards to me. How do you find problems that fit your languages feature set? I didn't realize we were just talking about scripting. I mainly make real big web applications.
|
# ? Apr 30, 2022 01:44 |
|
Do we have a thread for potentially networking? I.e. finding people at certain companies who can make sure someone at least looks at your resume? I mentioned before that I got an offer but it's probably not going to last more than 6 months so I want to start making connections now.
|
# ? Apr 30, 2022 10:15 |
|
Ok back again, thanks for the suggestions, I set the port to something in the 50000 range. I think... the issue I was running up against was that the syntax for the MariaDB connection is different to MySQL. So far I've been succesfull in sending a GET and POST request (so just need to write the functions for PUT and DELETE). However have hit another wall with he PUT function. I had thought I could simply amend the code used for the POST function however it doesn't seem to be making changes in the DB). The PUT request should be sending this to the DB, however while the function runs no changes are made to entry 501. Pretty sure it's something very dumb that's tripping me up. code:
code:
|
# ? May 1, 2022 18:01 |
|
Are you stepping through your code in a debugger? [edit] I'm not asking to be an rear end in a top hat, I'm just asking because debugging your own code is a core skill. Look at the request body. Is it what you expect it to be? Look at the query that's getting generated. Is it what you expect it to be? If the answer to either of those questions is "no", can you figure out why? I've never written a line of nodejs or used MariaDB, but this looks suspect to me: code:
New Yorp New Yorp fucked around with this message at 18:23 on May 1, 2022 |
# ? May 1, 2022 18:10 |
|
Also, if you're doing this in a browser, you might be able to see if there is a message in the 501 response with Developer Tools (F12). You can probably do it in Postman too, but I forget how exactly.
|
# ? May 1, 2022 18:40 |
|
New Yorp New Yorp posted:Are you stepping through your code in a debugger? Yeah, but it wasn't throwing up any errors (maybe I'm using the debugger incorrectly though). quote:I've never written a line of nodejs or used MariaDB, but this looks suspect to me: You're correct, this fixes the problem. I've hacked my way around it by updating the array that holds the req.body to to code:
code:
|
# ? May 1, 2022 20:23 |
|
keep punching joe posted:Yeah, but it wasn't throwing up any errors (maybe I'm using the debugger incorrectly though). Don't know anything about that particular toolchain, can't offer advice. I would have expected that your original code would work if you just moved the id variable to the end of the array, like so: code:
The reason your query wasn't failing is probably because it was still generating a valid SQL UPDATE statement, just with the wrong values. I'm also noticing that your database schema is improperly normalized, which isn't a huge deal but would definitely concern me in a job interview scenario unless it was accompanied by a note explaining that you didn't normalize it for the sake of time and explaining how you would normalize it if it were a "real" application. New Yorp New Yorp fucked around with this message at 01:08 on May 2, 2022 |
# ? May 2, 2022 00:58 |
|
keep punching joe posted:Yeah, but it wasn't throwing up any errors (maybe I'm using the debugger incorrectly though). There's going to be a lot of cases where your code doesn't throw errors, but it also doesn't do what you want it to. Those are times where you want to use the debugger to figure out what's going on. Like New Yorp said, it would be a good idea to inspect the query that's being generated, or inspect the values that are coming in from req.body to see if they're what you expect. A huge part of coding is solving problems just like this and all you really have to do is break things down into pieces to see where something is going wrong. The thing you're trying to accomplish (send a PUT request to update the db) is made up of a bunch of tiny steps, so you just kinda have to verify that each step is working until you find the one that isn't. 1. Is the browser actually sending the request? 2. Is my app receiving the request where I expect it and firing the function? 3. Are the values I'm pulling from the request what I expect them to be? 4. Is the query that's being sent to the db correct? In this case I'm not even sure if it's possible to inspect the query from within your node app so you might've needed to open up the MariaDB query log to see that your code was trying to update a record where the id was equal to the value you sent for subgenre.
|
# ? May 2, 2022 04:28 |
|
New Yorp New Yorp posted:I'm also noticing that your database schema is improperly normalized, which isn't a huge deal but would definitely concern me in a job interview scenario unless it was accompanied by a note explaining that you didn't normalize it for the sake of time and explaining how you would normalize it if it were a "real" application. Would you mind expanding on this further by what you mean by improperly normalised? I'm completely unfamiliar with DBs so wasn't aware that mine is set up incorrectly. The team I'm moving into are already aware that my coding knowledge is minimal, the task is purely to demonstrate that I have a basic understanding of linking a DB to a front-end (I honestly doubt they are expecting much here), and now that I have to GET/POST/PUT/DELETE routes set up I'm on more familiar territory because I know enough HTML/CSS to set up user forms and make the page have pretty colours.
|
# ? May 2, 2022 12:35 |
|
New Yorp New Yorp posted:I'm also noticing that your database schema is improperly normalized, It looks fine to me.
|
# ? May 2, 2022 14:07 |
|
keep punching joe posted:Would you mind expanding on this further by what you mean by improperly normalised? I'm completely unfamiliar with DBs so wasn't aware that mine is set up incorrectly. Normalization is making sure that any fact in a database only has one source of truth. Let's say you wanted to have a table to list songs on each album. You wouldn't want to repeat all that album information in the song table as well, so you'd have a column with the album_id linking to the album the song was on instead of repeating the album name, artist, ect. It's a concept that's really important in database structure and design. But, if you're just trying to get/put/updated/delete the data for a simple toy project in an initial job interview, you're fine. Here's an article to get you at least understanding why there's a lot of tables in a normal database.
|
# ? May 2, 2022 14:30 |
|
ExcessBLarg! posted:Oh boy. Here comes the bike shedding. IMO, artist should probably be off in its own table, since artist names are neither unique nor fixed.
|
# ? May 2, 2022 14:36 |
|
Don't forget lack of compound values. Even if the compound value is the only way to determine the info it's not normalized. Eg one of the horrors at my current job is a tree: code:
Children is a comma separated group of id's. I learned after I saw this that we have a DBA! My first thought was "how could we possibly have a DBA?!"
|
# ? May 2, 2022 14:41 |
|
The end stage of normalization is that any distinct piece of information that might be repeated across rows in a single table actually resides in its own table and is only referenced by a foreign key. So, for your example case you'd have a separate "artists", "genres", "subgenres" tables, and if you're especially insane perhaps "release_year" too, which would make your "albums" table consist of an (integer) primary key, (integer) foreign keys, and the album name. So anytime you look at the albums table all you see are useless numbers, not useful information--at least, not without joins. But you're not supposed to look at the table directly, you should create a view that you actually look at that does the joins behind the scenes. Personally I think normalization is a trap. People are eager to do it without considering if it's necessary or important to the scope of a project, but scope and requirements should drive the degree of normalization. Like, separating "artists" from "albums" makes sense if you frequently want to look up albums all by the same artist, but what do you do about Prince? A bunch of his discography was released under his Love Symbol moniker, so if you replace the "albums.artist" column with "artist_id" and there's only one canonical "artists.name", then you're forced to make a wrong decision on how to store his discography due to inflexibility of the schema. An alternative approach would be to leave the "albums.artist" column as is, and also provide "albums.artist_id" linkage to the artists's canonical information. But again, for a toy project a single table is fine. For an interview, a single table is fine unless the point of the interview question is to spec an appropriate schema given the requirements of a project. If you don't get hired because your toy project isn't properly 4NF, you're lucky to avoid the place. ExcessBLarg! fucked around with this message at 14:59 on May 2, 2022 |
# ? May 2, 2022 14:53 |
|
ExcessBLarg! posted:
Yeah, especially for a junior I wouldn't make a huge deal about it -- I'd just want to know "this person is vaguely familiar with normalization and won't immediately start drowning if they see a database with foreign keys and will at least know to ask the right questions if they need to tweak a database schema". Other people have already explained the concept better than I would have.
|
# ? May 2, 2022 15:05 |
|
New Yorp New Yorp posted:I'd just want to know "this person is vaguely familiar with normalization and won't immediately start drowning if they see a database with foreign keys and will at least know to ask the right questions if they need to tweak a database schema". I just think it's rude to call something "improper" without the context of provided requirements: New Yorp New Yorp posted:I'm also noticing that your database schema is improperly normalized, which isn't a huge deal but would definitely concern me in a job interview scenario unless it was accompanied by a note explaining that you didn't normalize it for the sake of time and explaining how you would normalize it if it were a "real" application. ExcessBLarg! fucked around with this message at 16:13 on May 2, 2022 |
# ? May 2, 2022 16:10 |
|
b0lt posted:IMO, artist should probably be off in its own table, since artist names are neither unique nor fixed.
|
# ? May 2, 2022 16:17 |
|
I wouldn't necessarily expect a junior or even a non-specialist to be able to talk about normalization in depth, but "why do we use foreign keys and joins?" is a very good interview question at every level and if you completely barf on it that's going to hurt you. It's also fair to ask why you designed your database tables how you did and how they compare to alternatives the interviewer can come up with.ExcessBLarg! posted:Like, separating "artists" from "albums" makes sense if you frequently want to look up albums all by the same artist, but what do you do about Prince? A bunch of his discography was released under his Love Symbol moniker, so if you replace the "albums.artist" column with "artist_id" and there's only one canonical "artists.name", then you're forced to make a wrong decision on how to store his discography due to inflexibility of the schema. An alternative approach would be to leave the "albums.artist" column as is, and also provide "albums.artist_id" linkage to the artists's canonical information. You can also have an artist ID and then have another table that tracks what name they were using during any given time frame. That might be reasonable depending on how your database/application are going to be used. Again, not something a junior dev needs to be aware of to get their first job, but it's one of those things that you should be aware of and learn more about over time. (The key thing to take away here is that database schema design requires domain knowledge. A one-size-fits-all approach doesn't work.)
|
# ? May 2, 2022 16:21 |
|
Normalization was covered in my old Intro To Databases class. I can’t remember the exact requirement for levels 1-3, but I remember the basics. Is this not standard knowledge for fresh grads anymore?
|
# ? May 3, 2022 03:15 |
|
Which week do you figure they cover schema normalization in full-stack boot camps? Years ago, the undergraduate CS curriculum at the (respected) university I attended had their Databases course as an elective on the same level as Networks and Operating Systems. So you could conceivably graduate with a computer systems focus (as I did) and not learn about normalization through coursework. Of course, like many things, you pick it up eventually during your career. ExcessBLarg! fucked around with this message at 03:52 on May 3, 2022 |
# ? May 3, 2022 03:46 |
|
ExcessBLarg! posted:Which week do you figure they cover schema normalization in full-stack boot camps? Week six.
|
# ? May 3, 2022 03:51 |
|
I’m willing to admit I’m legit out of touch on this issue. When I hire devs the details of SQL databases don’t really come up, I don’t find them that interesting and don’t talk about them much.
|
# ? May 3, 2022 04:12 |
|
lifg posted:I’m willing to admit I’m legit out of touch on this issue. When I hire devs the details of SQL databases don’t really come up, I don’t find them that interesting and don’t talk about them much. This is also how you run into problems like the one I'm dealing with now where what should be a day of work turns into months of justification followed by months of work because the data model is completely fubar.
|
# ? May 4, 2022 10:37 |
While I didn't spend a ton of time on it, when I interviewed devs in the past I always made sure to pepper in a couple small questions about SQL related things to make sure they weren't totally inept. "How would you implement a many to many relationship in the database?" "What is a foreign key and why would you use one?" "That object you described, how would you implement it as a table in the database?" "What is an index and what are the advantages and disadvantages of using one?" A surprising number of supposedly full stack devs would miss on these fairly basic questions.
|
|
# ? May 4, 2022 16:04 |
|
"What is SQL injection? How can you prevent it?" is pretty basic imo but lots of people seem to trip over it
|
# ? May 4, 2022 16:06 |
Security in general is a thing a lot of devs just don't understand.
|
|
# ? May 4, 2022 16:09 |
|
You'd think SQL injection, along with buffer overflows, is something they'd teach everyone in school if there's a remotely good exclude to do so. That said if your only programmatic SQL experience is with ORMs--is injection even really a thing there? We're past the days of PHP string escaping and Perl DBI placeholders or whatever.
|
# ? May 4, 2022 16:15 |
|
A lot of dev jobs also don’t go within a mile of touching a SQL db. If this is useful knowledge for your team then great (i.e. full stack, sure) but if not then it’s just lovely gatekeeping?
|
# ? May 4, 2022 16:16 |
|
If you can't put together a CRUD app on a day or two are you really a dev Not even being factitious
|
# ? May 4, 2022 16:51 |
|
I think it's reasonable for someone who does non-business programming (eg operating systems, embedded, graphics, signal processing) to not know how to do that but everybody else definitely should
|
# ? May 4, 2022 16:54 |
|
Hadlock posted:If you can't put together a CRUD app on a day or two are you really a dev I mean, that’s a pretty normally take-home test for an interview. It’s either that or something with APIs.
|
# ? May 4, 2022 17:06 |
|
Yeah if you're a world class kernel hacker I'll give you a pass on SQL lovely gatekeeping but also we're going to be talking about entirely class of problems and can probably skip gatekeeping questions If you're two years out of college you're getting gatekeeping questions. SQL isn't crazy just devote two hours a day, two days a week for a month and you'll know as much as 80% of developers, maybe more
|
# ? May 4, 2022 17:16 |
|
I'm not sure if I can develop a CRUD app in a short time frame but I'm definitely not going to try. There's a lot more to software development than application development.
|
# ? May 4, 2022 17:18 |
|
If you’re doing application development knowing the concept of SQL injection and cross site scripting is a reasonable expectation I think
|
# ? May 4, 2022 18:07 |
|
Hadlock posted:If you can't put together a CRUD app on a day or two are you really a dev Probably less, but if I walked into an interview today and they asked me virtually anything about SQL I'm outta luck. I remember the concepts but none of the actual syntax. Haven't written a line of SQL in 3 years, the last DB I worked with was a nosql Cassandra DB and tbh "worked on" is a very generous definition. I interacted with it once every two months at most. But in my defense I recently made the decision to bow out of full-stack. I'm able to do it, but anything beyond a Node server these days is gonna require me to look it up, and it's just not worth anyones time for me to do that. I'm significantly faster at front-end work and find it ridiculously easier.
|
# ? May 4, 2022 22:04 |
|
define crud app also how nice do you want it to look
|
# ? May 5, 2022 06:11 |
|
|
# ? Jun 3, 2024 21:06 |
|
like crud
|
# ? May 5, 2022 06:47 |