Newbie Programming Interviews/Get a Job Megathread: Fake it 'til you make it

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Newbie Programming Interviews/Get a Job Megathread: Fake it 'til you make it

«‹›728 »

Armauk: Jun 23, 2021

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

Adbot: ADBOT LOVES YOU

# ? May 31, 2024 23:04

JawnV6: Jul 4, 2004; So hot ...

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

Butter Activities: May 4, 2018

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

prom candy: Dec 16, 2005; Only I may dance

JawnV6 posted:

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?

I didn't realize we were just talking about scripting. I mainly make real big web applications.

# ? Apr 30, 2022 01:44

Vincent Valentine: Feb 28, 2006; Murdertime

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

keep punching joe: Jan 22, 2006; Die Satan!

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:

{
    "id": 501,
    "release_year":2022,
    "album":"amended album name",
    "artist":"amended bandname",
    "genre":"ELECTRONIC",
    "subgenre": "IDM"
}

code:

const express = require("express");
const res = require("express/lib/response");
const router = express.Router();
const pool = require("../helpers/database");
let DB_TABLE = process.env.DB_TABLE;

router.get("/:id", async function (req, res) {
  try {
    const sqlQuery = `SELECT * FROM ${DB_TABLE} WHERE id=?`;
    const rows = await pool.query(sqlQuery, req.params.id);
    res.status(200).json(rows);
  } catch (error) {
    res.status(400).send(error.message);
  }
});

router.post("/add", async function (req, res) {
  try {
    const { release_year, album, artist, genre, subgenre } = req.body;

    const sqlQuery = `INSERT INTO ${DB_TABLE} (release_year, album, artist, genre, subgenre) VALUES (?,?,?,?,?)`;
    const result = await pool.query(sqlQuery, [
      release_year,
      album,
      artist,
      genre,
      subgenre,
    ]);

    res.status(200).send(`Added to DB`);
  } catch (error) {
    res.status(400).send(error.message);
  }
});

router.put("/amend", async function (req, res) {
  try {
    const { id, release_year, album, artist, genre, subgenre } = req.body;

    const updateQuery = `UPDATE ${DB_TABLE} SET release_year=?, album=?, artist=?, genre=?, subgenre=? WHERE id=?`;
    const result = await pool.query(updateQuery, [
      id,
      release_year,
      album,
      artist,
      genre,
      subgenre,
    ]);

    res.status(200).send(`Updated DB`);
    console.log(req.body);
  } catch (error) {
    res.status(400).send(error.message);
  }
});

module.exports = router;

# ? May 1, 2022 18:01

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

keep punching joe posted:

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:

    const updateQuery = `UPDATE ${DB_TABLE} SET release_year=?, album=?, artist=?, genre=?, subgenre=? WHERE id=?`;
    const result = await pool.query(updateQuery, [
      id,
      release_year,
      album,
      artist,
      genre,
      subgenre,
    ]);

Does that array of entries being passed in to query rely on array order to replace the ?? If so, release_year is going to be set to the value of id. I took a quick look at the docs and it appears that my assumption is correct, but if I were you I'd independently verify this by looking at the query before blindly making the change based on some random person's advice.

New Yorp New Yorp fucked around with this message at 18:23 on May 1, 2022

# ? May 1, 2022 18:10

Magnetic North: Dec 15, 2008; Beware the Forest's Mushrooms

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

keep punching joe: Jan 22, 2006; Die Satan!

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:
code:
    const updateQuery = `UPDATE ${DB_TABLE} SET release_year=?, album=?, artist=?, genre=?, subgenre=? WHERE id=?`;
    const result = await pool.query(updateQuery, [
      id,
      release_year,
      album,
      artist,
      genre,
      subgenre,
    ]);
Does that array of entries being passed in to query rely on array order to replace the ?? If so, release_year is going to be set to the value of id. I took a quick look at the docs and it appears that my assumption is correct, but if I were you I'd independently verify this by looking at the query before blindly making the change based on some random person's advice.

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:

const { id, release_year, album, artist, genre, subgenre, id2 } = req.body;

and the input to

code:


{
    "id": 501,
    "release_year":2022,
    "album":"aYYYYmended album name",
    "artist":"amended bandname",
    "genre":"ELECTRONIC",
    "subgenre": "IDM",
    "id2":501
}

I know in my heart that this is a poo poo solution, but it still works in updating the entry so at least I can move on and hopefully get the server side of the app finished tonight.

# ? May 1, 2022 20:23

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

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:

    const result = await pool.query(updateQuery, [
      release_year,
      album,
      artist,
      genre,
      subgenre,
      id
    ]);

Do you understand what the line const { id, release_year, album, artist, genre, subgenre, id2 } = req.body; is doing? It's called destructuring. The first value in req.body goes into the id variable, and so on. The order of the variables is irrelevant after that point, such as when building the array of values that you pass into pool.query.

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

prom candy: Dec 16, 2005; Only I may dance

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

keep punching joe: Jan 22, 2006; Die Satan!

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

ExcessBLarg!: Sep 1, 2001

New Yorp New Yorp posted:

I'm also noticing that your database schema is improperly normalized,

Oh boy. Here comes the bike shedding.

It looks fine to me.

# ? May 2, 2022 14:07

Coco13: Jun 6, 2004; My advice to you is to start drinking heavily.

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

b0lt: Apr 29, 2005

ExcessBLarg! posted:

Oh boy. Here comes the bike shedding.

It looks fine to me.

IMO, artist should probably be off in its own table, since artist names are neither unique nor fixed.

# ? May 2, 2022 14:36

leper khan: Dec 28, 2010; Honest to god thinks Half Life 2 is a bad game. But at least he likes Monster Hunter.

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:


id char[64]
children char[1024]

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

ExcessBLarg!: Sep 1, 2001

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

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

ExcessBLarg! posted:

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.

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

ExcessBLarg!: Sep 1, 2001

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".

Then ask a follow-up question to see how they might provide a normalized schema in support of a specific requirement. But even without really understanding normalization at an academic level, many juniors are familiar with FKs and joins and such.

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.

I'm telling you, this is actually a lovely take. If you and I sat in an interview together and you provided this as your feedback without giving the candidate a chance I would (rightfully) call you out on it.

ExcessBLarg! fucked around with this message at 16:13 on May 2, 2022

# ? May 2, 2022 16:10

ExcessBLarg!: Sep 1, 2001

b0lt posted:

IMO, artist should probably be off in its own table, since artist names are neither unique nor fixed.

Depending on the source of data, the "artist name" is simply metadata provided about the album itself. You can have one artist that publishes under two different names (see Prince, many.). You can also have multiple artists that use the same name (see recent "Lady A" debacle). To assume that artist names are unique and may be solely used to link together a discography demonstrates a misunderstanding of practical problems here. Simply saying "each album specifies its artist's name because that's what's provided in the feed" is not only a reasonable take, but the correct one.

# ? May 2, 2022 16:17

ultrafilter: Aug 23, 2007; It's okay if you have any questions.

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

lifg: Dec 4, 2000; <this tag left blank>; Muldoon

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

ExcessBLarg!: Sep 1, 2001

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

Vincent Valentine: Feb 28, 2006; Murdertime

ExcessBLarg! posted:

Which week do you figure they cover schema normalization in full-stack boot camps?

Week six.

# ? May 3, 2022 03:51

lifg: Dec 4, 2000; <this tag left blank>; Muldoon

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

leper khan: Dec 28, 2010; Honest to god thinks Half Life 2 is a bad game. But at least he likes Monster Hunter.

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

wilderthanmild: Jun 21, 2010; Posting shit; Grimey Drawer

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

spiritual bypass: Feb 19, 2008; Grimey Drawer

"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

wilderthanmild: Jun 21, 2010; Posting shit; Grimey Drawer

Security in general is a thing a lot of devs just don't understand.

# ? May 4, 2022 16:09

ExcessBLarg!: Sep 1, 2001

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

fourwood: Sep 9, 2001; Damn I'll bring them to their knees.

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? :shrug:

# ? May 4, 2022 16:16

Hadlock: Nov 9, 2004

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

spiritual bypass: Feb 19, 2008; Grimey Drawer

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

lifg: Dec 4, 2000; <this tag left blank>; Muldoon

Hadlock posted:

If you can't put together a CRUD app on a day or two are you really a dev

Not even being factitious

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

Hadlock: Nov 9, 2004

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

ultrafilter: Aug 23, 2007; It's okay if you have any questions.

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

Butter Activities: May 4, 2018

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

Vincent Valentine: Feb 28, 2006; Murdertime

Hadlock posted:

If you can't put together a CRUD app on a day or two are you really a dev

Not even being factitious

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

redleader: Aug 18, 2005; Engage according to operational parameters

define crud app

also how nice do you want it to look

# ? May 5, 2022 06:11

Adbot: ADBOT LOVES YOU

# ? May 31, 2024 23:04

Hadlock: Nov 9, 2004

like crud

# ? May 5, 2022 06:47

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Newbie Programming Interviews/Get a Job Megathread: Fake it 'til you make it

«‹›728 »