Hi please evaluate my CV website 2

I made an react app using version 18.2 static website and deployed it on github.
It looks great on computer but not that much on phones, use desktop version for better visual.

here is the website link: fygen.github.io
here is the source code: theCVproject

  1. Click on the any project or the experiences to expand that project or experience.

  2. Top right section of controls:
    2.1 TLDR: too long didn’t read Slider for showing only important aspects
    2.2 daymode for white page layout

  3. About section in the middle:
    3.1 On computers the social links jumps after hovering them.
    3.1 Certificates all and the projects all links to the pages where their link is.
    3.2 When hovering certificates grows twice their size

  4. Used React-Markdown in every sections for getting the data for pictures or anything.

  5. An animated SVG for the website LOGO in the top left and in favicon.ico.
    (But it is not working in favicon.ico tried solve it but no luck. I didnt wanted to use JavaScript for it (Not that hard but already using many JS codes website is slow and that probably needs to be usen with inline SVG)

  6. node.js, webpack, SCSS are used.

What else could be added. Or what type of things takes the attention that I am able to do something in the web? What kind of things shine when applying a job. I’m now in the backend&API section of the certification courses. Looking forward to any suggestions. Thanks in advance.

Here is a one picture of it:

edit: source code added.

1 Like

I agree that that text is hard to read.

I think you are trying to be too fancy. You are using this to show off all the CSS tricks you’ve learned. I think the point should be to make it as easy to find information about you as possible. I think the organization is too busy - I don’t know where to focus. I think a top down design would work better. If you really want horizontally laid out cards like this, then I’d do a media query or use some flexbox to stack them vertically when the screen gets narrow - that would help a lot when on mobile.

Remember - clear, readable, quickly informative, and inviting. Don’t try to show off. Use good taste with an emphasis on communication - if it doesn’t help communication, then it is probably a distraction. For example, the dancing social icons - what does that help? What does that communicate. If moving the mouse away, that means that my attention is elsewhere. Why distract me with something I’ve decided to leave? To contrast that, the enlarge on hover is good - it focuses my attention on where I am looking and lets me know that it is clickable.

The backgrounds need high contrast with the text. The fuzzy titles are distracting.

I would just list my certs - don’t show pictures. You can have them click to see the cert if you want, I guess.

I don’t need narrative stories about the army. Especially since I see that before your actual projects should be the star and I have to scroll through a bunch of less important stuff to get to them.

When I look at a portfolio page, I want to see:

  1. Who you are - a few sentences about what kind of job you want, what you do
  2. What techs you know
  3. What projects I can see
  4. What your work history is
  5. What your education is
  6. Maybe a short narrative about your coding journey
  7. Contact information

That’s roughly the order I would expect them in. 3-5 might be switched around, depending on which most strongly supports you as a developer. I would also expect a link to a proper paper pdf CV I could print out.

I find the colors a little stark, but I’m a little old fashioned - maybe it is defensible in a brutalist sort of way. But maybe:

    --whitefornight: #ddd;
    --blackfornight: #222;

would be a little less jarring.

And JavaScript is typically abbreviated as “JS”, not “Js”. Anytime you use a trade name, look it up to make sure you have their branded name right - people notice things like that.

I don’t need a picture of you working an angle grinder. As a hirer, why do I care? They don’t care about your work ion agricultural tools or freezers. Those should be a line in your work history, maybe a little more if they involve coding.

What job are you after? “Jr. FrontEnd”, “Js&React Developer”, “Electrics &Electronics Engineer”? It should just be “Front End Developer, JavaScript and React”. If you want to get jobs dealing with electronics, do a separate page - you want them to think of you as focussed on the job for which they want to hire you.

Remember, the gate keepers for these jobs sometimes look at hundreds of these a day. You have 5 seconds to convince them to keep reading. If it’s a struggle, they’ll just move on to the other 127 they have to read before lunch. Make it easy for them.

Do some google searches for web developer portfolio pages. Read them like a hiring manager. Scan them for 5 seconds and see how much you learn about them. What works, what doesn’t.

Those are just my thoughts.


Looking at the code …

Don’t put all the React code in one file. Break it up into files. Show them that you know how to organize a project. Yeah, you can get away with that on something small, but that won’t scale for an app with 100k lines and hundreds of components. Every React component should its own file, probably in its own folder grouped with its support files.

I get nervous when I see a prop called “state”. Just pass what you need.

     const [state, dispatch] = useReducer(reducer, initialState);
     const whoExpanded = state.whExpanded;

In general, “state” is a horrible variable name, unless you are in an actual reducer, etc. Use destructuring or a selector:

     const [{whExpanded: whoExpanded}, dispatch] = useReducer(reducer, initialState);

And if you call the property on state as “whoExpanded”, it gets simpler - and more readable.

const About = () => {
     const [text, setText] = useState(about);

     return (
               <ReactMarkdown children={text} />

Does this need state? That “about” should be imported in this file, where it is needed. Do you need that div?

     const checkHide = (val) => {
          if (val === whoExpanded) {
               return "";
          } else if (whoExpanded === "all") {
               return "";
          } else {
               return " hidden";

First, “val” is a terrible variable name unless you really have know idea what it will be. And this is simplified and more readable as:

     const checkHide = (category) =>
      [whoExpanded, 'all'].includes(category)
        ? ''
        : 'hidden'

const ExpBank = (props) => {
     const [state, dispatch] = [props.state, props.dispatch];
     return experienceTexts && experienceTexts.map((text, index) => {
          return (
               <ExpFrame state={state} dispatch={dispatch} key={index} text={text} name={expFolders[index]} />

What about:

const ExpBank = ({state, dispatch}) => {
     if (!experienceTexts) {
       return null

     return experienceTexts.map((text, index) => {
          return (
               <ExpFrame state={state} dispatch={dispatch} key={index} text={text} name={expFolders[index]} />

or something like that.


const ExpBank = ({state, dispatch}) =>
  experienceTexts?.map((text, index) => (
    <ExpFrame state={state} dispatch={dispatch} key={index} text={text} name={expFolders[index]} />

might work, too.

function checkExpand(who, state, dispatch) {
     if (state.whExpanded === "all") {
          dispatch({ type: UEXP, payload: who });
     } else {
          dispatch({ type: UEXP, payload: "all" });

might be:

function checkExpand(who, state, dispatch) {
  dispatch({ type: UEXP, payload: state.whExpanded === "all" ? who : "all" });

or if you want to make it a little more readable:

function checkExpand(who, { whExpanded }, dispatch) {
  const payload = whExpanded === "all" ? who : "all";
  dispatch({ type: UEXP, payload);

onClick={() => changeNM()}

in this case would be the same as:

onClick={ changeNM }

Also, call it “changeNightMode” or whatever - we don’t get charged by the letter. Clarity is much, much, much more important - don’t make them guess or assume.

          if (isOn) {
          } else {

should be:

           whiteToBlack(isOn ? "white" : "black");

          function inv(color) {
               if (color === "white") {
                    return "black";
               } else if (color === "black") {
                    return "white";
               } else {
                    return 0xffffff ^ color;

should be:

          function inv(color) {
            if (color === "white") {
              return "black";
            if (color === "black") {
              return "white";
            return 0xffffff ^ color;

avoid nesting and chaining where you can.

          document.documentElement.style.setProperty('--whitefornight', revColor);
          document.documentElement.style.setProperty('--blackfornight', color);

Don’t manipulate the DOM directly in React. Only React messes with the DOM, period. If you find yourself referencing document (other than getting your main wrapper element in your root index.js), then you are probably doing something un-React-y.

     const styles = [
          // ...

Don’t store those in an array. If you must do it this way, store it in an object you can give each of those style objects a meaningful name.

const reducer = (state, action) => {
     const value = action.payload;
     switch (action.type) {
          case UEXP:
               return { ...state, whExpanded: value }
          case UNMD:
               return { ...state, nightMode: value }
               return { ...state }

If you’re returning a value in a case, you don’t need break.


               return { ...state }

Why return a copy of state? Since you are not changing it, just return state.

In general, look at some other React projects to see how they are organized, in terms of file and folder structures. There is more than one way to do it, but there are some basic principles.

Use standard formatting. What you have isn’t bad, but it would be good to install something like eslint and use some standard format - it’s what they are used to seeing. Something like prettier is nice, too.

Sorry if that comes off as harsh - I’m sure my projects at this stage where ripe for the same nitpicking. But those are the things that I notice as an experienced dev. If I were on the hiring committee, those are the question that I would ask.

Keep it up, you’ll get there.


This is a dense and thorough response. I appreciate all the info you shared with OP. This is gold should he choose to receive it well.


From a purely design POV the colors and text size make the content difficult to read.

Simpler is better. This reminds me of a MySpace or Geocities webpage.

1 Like

Thank you, I will be considering to add background and opacity for those text backgrounds. :slight_smile:

You probably know about the story of the Naked King. I don’t want to deceive myself. I am truly grateful for your well explained, also very well guided answers. You don’t just say things, also show me the ways of “how a true coder handles” those. By the way I am going to defend myself a little bit. :smiley:

If I don’t mention about some of them that means you are absolutely right about them and I will be definitely change them in future updates.
And possibly soon, because I have a job offer now which needs to be handled this week. :slight_smile:

  1. About this I really like that 18.2 version have useReducer hook for not using Redux. So why not a “state” it is really a Redux like state.
    I like to see them together bundling each other and all functions handled from a switch case feels nothing different than redux.
    And without using redux connect or so; I in love with this.
    Why not “state”, and what the “state” should be :slight_smile:

  1. This is a golden ring thank you for this.

  1. I have learnt a new operator usage today. Thanks to you :slight_smile: I will be adding a link to that operator so I could see it later. Also this could be a guide to others too :smiley: Optional Chaining

  1. There is story on that if sections why I didn’t used.
    Once I was using them for if else if else situations;
    And in the fcc forum again I have been told to not use them for easier readability :slight_smile:
    But if something is only exists as “if else” operation then I should have used them thats where I missed :smiley:
    probably some sleepy coder over there;
    just waking up in the middle of the night,
    with the code ideas coming from the dreams of coding,
    to complete the project :smiley:
    I see a Frankestein over there just opening his grave :smiley:

  1. This should have to be done, CSS in JS => Looks good to me :smiley:
    To stackoverflow about this, why not?
    and a different
    link to how to Manipulate DOM in React

Thank you for all your answers Kevin,
You only told me what is needed; it was not harsh, this only a friendly fire, those can’t hurt :slight_smile:

I actually hid that from the page because a comment from a experienced coder I know.
You are a detailed coder Kevin :smiley: Probably going to delete from there as well its just a txt file anyway :smiley:

Army taught me that;
I can’t work under some !super_intelligence :smiley:
Thats why; I am, who I am now :slight_smile:
Actualy every people should go there for once for their lifetime to see;
what is not a job to do and to see possibilities what they could be.

The purpose of a variable name is to name the variable. It is to make it clear and obvious what it is. It doesn’t matter if you knew what it was when you wrote it, it matters is someone else, that doesn’t know the code will walk in and know what it is by reading the name. It’s not easy - there’s the old saying that the two hardest things in programing are naming things, cache invalidation, and OBO errors.

I live in Spain now. If I am talking to someone and say “the ambassador to the UN”, we both know who I mean. If I’m in the UN building and I am talking to a random person, and I say “the ambassador to the UN”, they won’t know who I am talking about.

If you are in a state reducer, and you call a variable “state”, it is clear what you mean. If you are outside a state reducer and call your variable “state” it is a source of confusion. State of what? The app? The component? The radio buttons? One of the seven reducers I use here?

“state” is a bad name. For that matter “reducer” is a bad name. I would expect something like:

const [settings, dispatchSettings] = useReducer(settingsReducer, initialSettingsState);

While we’re at it, those are terrible names for action types. “UNMD” is a puzzle, a comprehension speed bump. “UPDATE_NIGHT_MODE” tells us exactly what it is, though I’m more used to seeing “set” than “update”.

And for the record, there is nothing wrong with Redux. It is a very powerful tool. If your project were to scale, it might become extremely useful. But if you want to explore hooks, that’s cool. But the fact that you have to use your state in your main app and then pass it around to different components exposes the other strength of redux - you can just import it in the component you want (this would make more sense if your components weren’t all in one file). Of course, you can use context API to make that easier, but that has its own difficulties. I’ve worked on some huge projects. In my experience, redux scales very nicely, solves a lot of problems, and leads to cleaner code. That’s just my $.02. On a small project like this? Sure, it doesn’t matter much - I wouldn’t use redux on something this small.

Once I was using them [ternary operators] for if else if else situations;

Yes, that can be bad. I hate when I see this:

myFlag ? doSomething1() : doSomething2()

To me, the point of a ternary is evaluation. So, something like:

let val
if (myFlag) {
  val = 'foo'
} else {
  val = 'bar'

should be:

const val = myFlag ? 'foo' : 'bar'

And in the fcc forum again I have been told to not use them for easier readability

Don’t believe everything you read in forums. And a lot of it depends on context. I agree that ternaries should not be used in cases where things become less readable. To me, if each result of the ternary is more than a couple lines long, then it shouldn’t be used. I see them inside JSX where each result has 20-30 lines of JSX in them and I think that is insane.

This should have to be done, CSS in JS => Looks good to me :smiley:

I don’t understand what you are trying to say. The first link confirms - don’t manipulate the DOM directly. The second talks about using React to “manipulate the DOM”. That is a battle of semantics. If I tell the maid to the do the dishes, can I say that I’m doing the dishes? If I tell React to manipulate the DOM, can I say that I’m manipulating the DOM.

The point is that only React manipulates the DOM. Period. Let React do it.

Otherwise you can confuse React. Imagine you have a lot of money, investments, stocks, etc. You hire a money manager. She’s the best in the world. She has one rule - “All transactions go through me, so I know where the money is at all times. Don’t change a stock, don’t make a deposit, etc. Just tell me what you want done and I will do it for you.” Now, if you go in and start changing things around, closing accounts, withdrawing money, etc. behind her back, how can she do her job? She’s going to screw things up.

If you want to manipulate the DOM directly, then don’t use React. I know sometimes it is tough to figure out how to get React to do a few things, but that’s just learning. And 99.99999% of the time, there is a way to do it.

1 Like

I’m not saying there is anything wrong with the army. I’m not saying it should be kept a secret. I’ve worked with a lot of ex-military and I consider it a plus when hiring. I’m just saying it doesn’t need to be that prominent and take up that much space.

I was a professional jazz guitarist. I think it made me a better coder. It takes up one line on my resume, towards the bottom. Why? Because it’s not directly relevant to why they want to hire me.

I think that is relevant to put in an “About Me” section, towards the bottom. What did it teach you that makes you a better coder - that’s good. You can go into it a little in you Cover Letter or in interviews. But the purpose of the CV is “Why you should hire me.” A lot of people were in the army. Almost none of them are programmers.

Of course, there could be a cultural difference here. As an American, a resume tends to be short, often one page. A CV can be more extensive. But again, you want the information that is most relevant as to why they should hire you at the top. Don’t give them a scavenger hunt to find that they really want. And if I were a hiring manager, I would just assume that you are avoiding talking about your projects and experience because you have none and skip your CV. There are 127 other resumes in my pile that respected my time enough to make it really, really easy to find the information I need. Maybe one of them wants the job.

1 Like

I will be searching for it. And about DOM manipulation, I will be searching for the proper methods in React. Thank you.

Hi @fygen You have an interesting CV!

I am by no means an expert on this but I would suggest prevent adding white background or image against white text!


This would make it harder to read. I would prefer lowering the opacity of the background a bit more

Also try using custom fonts as that would add a bit of style to your personality.

You can add custom fonts via

It will tell you how to import it to your website. (All fonts there are free and open)

1 Like

I would remove the serif font, white text on black ground, the text shadows, the massive scale/zoom on the certificates…

It’s also not responsive, these columns need to be full width on mobile

Design doesn’t need to be your skill to be a programmer, but if it’s not, then keep it as simple/elegant as possible.

Most importantly there’s a tonne of irrelevant information here. Employers aren’t going to spend 15 minutes reading through your entire biography. You’ve got a few seconds to get across who you are AS A PROGRAMMER. My attention is first drawn to a photo of you welding (or something?) and then talking about your military service??

1 Like